Desk study with incident coding27 minutes

Identity as Blast Radius: Human and Non-Human

A desk study with incident coding. It examines how far identity compromise propagates in the public record, with attention to service accounts, machine credentials and third-party OAuth grants.

When an attacker steals one login, how far can they actually get? And does it matter whether that login belongs to a person or to software, like an app, a service account or a key?

I read primary reports on 15 public incidents, five providers' documentation and the main annual breach reports, retrieved 25 September 2026. Software logins repeatedly carried attackers from one organisation into others, crossing an organisational boundary in 8 of the 15. The clearest cases follow the same shape: a company connected to its customers' systems gets breached, and its stored tokens open those customers' data. Several kinds of software login don't expire unless somebody acts, including Salesforce app tokens, Google Cloud service account keys and GitHub OAuth app tokens.

What surprised me is that in most cases the spread stopped early. One company's hardware security keys and device rules kept out an attacker holding a valid administrator login; another's access controls, firewall rules and hardware keys confined an attacker with valid software logins to a small part of its systems. Less encouragingly, it was often a customer, a platform provider or a third party who spotted the intrusion first rather than the victim. The big breach datasets don't record whether stolen credentials belonged to people or to software, so there's no way to say which gets compromised more often, and published counts of software logins per person range from about 5 to 144, all from vendors with thin methods.

So the path through software logins is real and well evidenced, but the idea that it usually goes far isn't. I'd list what third parties hold on your behalf, shorten token lifetimes, rotate everything after an incident including logins you believe are unused, and keep strong login protection for people rather than moving all the attention to machines.

The full paper

The full paper is about a 27-minute read. It has the claims I checked, what I used, what I rejected and why, and dated copies of every source with hashes, so there is a record of exactly what I was working from.

Ask if you want to read it.