The logins that were never a person

· · Security

Count the people who can log into your systems. Now count the things that can: the account your accounting software uses to read the bank feed, the key your website uses to send email, the integration between your CRM and your calendar, the AI assistant somebody connected to the shared drive last month.

In most businesses the second number is larger, growing faster, and has never been reviewed by anyone.

What the research found

SpyCloud surveyed 750 security leaders across the UK, Europe, and North America. Its finding, reported by Infosecurity Magazine, is that compromised machine accounts were the primary way into an organisation in 31% of intrusions, against 17% for social engineering. Close to twice as likely as phishing.

Treat those percentages as directional. This is vendor research from a company that sells protection against the problem it is measuring, and the respondents were at organisations of 500 staff or more, not the size of business we usually write for. The number is a prompt, not a fact about your company.

The finding underneath it is the one that survives the caveat, and it is a gap rather than a percentage: 95% of those organisations believed they had adequate visibility of these accounts. 36% actually monitored them.

Trevor Hilligoss of SpyCloud put the mechanism plainly:

"Every one of these identities is a standing invitation that renews itself until someone notices."

Why these accounts are the soft target

A machine login is different from a person's in every way that matters to an attacker, and each difference works in their favour.

Nobody owns it. A person's account has an obvious owner: them. A service account was created by whoever set up an integration, possibly a contractor, possibly three years ago. When they left, nobody inherited it, because nobody knew to.

It usually has more privilege than it needs. Setting up an integration is fiddly. Giving it broad access makes it work first time, and narrowing it afterwards is a job with no deadline. So the key that only needs to read your calendar can often write to it, and the one that sends your newsletters can frequently read your whole customer list.

It has no second step. Two-step verification protects people, because people can be prompted. A service account authenticates with a key or a token and nothing else. Whoever holds that string is the account, which is why a key left in a public file or in your website's own code is such a direct route in.

Nothing looks odd when it is used. A person logging in at 3am from another country is an anomaly. A service account calling an API at 3am is Tuesday. The behaviour that would trigger an alert for a human is the normal operating pattern for a machine.

It never leaves. We wrote last week about the account nobody was told to switch off when someone resigned. At least a departure is an event: HR knows, payroll knows, something happens on a date. An integration with a supplier you stopped using in 2023 generates no event at all. It simply carries on holding its access until somebody goes looking.

AI has made this sharper, because agents and assistants are machine identities that people create casually, often without asking IT, and often with access to a shared drive or a mailbox. Every one is another standing credential.

What to do this quarter

The goal is a list and an owner for each line on it. That is genuinely most of the work.

  • Write down every integration you can find. Start with the obvious sources: the "connected apps" or "integrations" page of your email, file storage, accounting, and CRM systems, plus your card statement for anything paying for a service you forgot about. This list is the thing you do not currently have.
  • Give each one a named human owner. Not a department. A person who would notice if it broke and can answer what it is for. Anything you cannot assign an owner to is your first candidate for switching off.
  • Ask what each one can actually reach. Most platforms show the permissions granted to an integration. The question is not whether it works, it is whether it can do more than its job requires. Read access where write was granted is the common and fixable case.
  • Turn off what nothing uses. Many platforms show a last-used date for a key or connection. A credential unused for six months is doing nothing except waiting to be found. Revoke it. If something breaks, you have learned what it was for, which is more than you knew before.
  • Rotate the keys you keep, on a date you choose. Changing a key is the one action that reliably ends the risk from a leaked one, and doing it deliberately once a year is far easier than doing it in a panic. Note which ones you rotated and when.
  • Add integrations to your leaver checklist. When someone goes, ask what they set up, not just what they had. That question surfaces the accounts nobody else knew existed.

None of this needs a product. It needs an afternoon, a spreadsheet, and the willingness to switch something off and see whether anyone shouts.

How Steelwise can help

Building the list of what is connected to your systems, what each connection can reach, and which ones nobody owns is a short and unglamorous review that usually finds something. Get in touch if you would like a second pair of eyes on yours.

Further reading

← All filings