Here's a number that should make you uncomfortable: in most enterprises, machine identities — service accounts, API keys, workload identities, automation credentials — outnumber human identities by something like fifty to one. Fifty to one.
Now here's the follow-up question: can you name all of yours?
Most organizations can't. They know their employees — HR onboards them, IT offboards them, there's a ticket for everything. But the service account created three years ago for a migration that never got decommissioned? The API key baked into a container image that's been copied across four environments? The automation credential with admin rights that nobody remembers issuing? Those live in the dark, and there are thousands of them.
This is the identity crisis nobody budgeted for. We spent two decades building mature processes for human identity — joiners, movers, leavers; SSO; MFA; quarterly access reviews. And the entire time, the machine population was quietly multiplying in the background, with none of that discipline attached.
The consequences are exactly what you'd expect. Stale credentials with excessive privilege. Keys that never rotate because rotating them might break something and nobody knows what. Service accounts owned by people who left the company two reorgs ago. Every one of these is a standing invitation, and attackers have figured that out — compromising a forgotten service account is quieter than phishing an executive and often more powerful.
I work in key management, so I have opinions about the fix, and the fix is aggressively unglamorous.
First: inventory. You cannot secure what you cannot see. Every non-human identity needs to be discoverable — who created it, what it can access, who owns it now. This is tedious work. Nobody wants to do it. Do it anyway.
Second: least privilege, for real this time. The service account that needs to read from one bucket does not need write access to the whole project. The CI pipeline does not need production admin. We say "least privilege" about human accounts and then hand machines the keys to the kingdom because it's convenient. Stop that.
Third: rotation with an owner and a schedule. A credential that never rotates is a credential waiting to leak. And rotation only works if someone owns the credential — an actual human, with a name, who gets paged when the rotation breaks something. "Owned by the platform team" is not ownership. "Owned by Priya" is ownership.
Fourth: deprovisioning. Machines need offboarding too. When the migration finishes, when the project sunsets, when the vendor contract ends — the identities go with them. Build the offboarding into the project plan, not as an afterthought six months later when someone finally asks "what is this account for?"
Notice what's not on this list: a shiny new product. The industry would love to sell you an NHI security platform, and some of those tools are genuinely useful for the inventory problem. But no product fixes the underlying disease, which is that organizations treat machine identity as plumbing instead of as identity. The discipline is the product.
There's a deeper point here about how security thinking lags reality. Our mental model of "identity" is still a person with a username, because that's what the last twenty years trained us on. But the population inverted while we weren't looking. The machines are the majority now, and they're the ones with the broad access and the thin oversight.
The good news: this is a solvable problem. It's not a cryptography breakthrough or an AI moonshot. It's inventory, least privilege, rotation, and offboarding — the same boring fundamentals that work everywhere else in security, applied to the population we forgot to count.
Boring is underrated. Boring is what keeps the lights on.