Every identity and access management program eventually runs into the same uncomfortable category: service accounts nobody owns. These are the non-human identities, API keys, cron job credentials, and integration tokens that were created to get something done, and then outlived the person or project that justified them. Nobody deletes a service account during an incident. Nobody deletes it during a product launch either. It just sits there, provisioned and forgotten, until someone finally asks who owns it and the honest answer is no one.
Why they accumulate
Our positioning thesis is that building software and controlling access to it are the same discipline, and orphaned service accounts are a clean illustration of why. A human employee has a lifecycle that organizations are at least reasonably practiced at managing: onboarding, role changes, offboarding, deprovisioning. A service account often has none of that. It gets created by whoever is standing up a new integration, it gets a broad set of permissions because narrowing them takes more time than anyone has that week, and then the project ships, the engineer moves teams, and the credential keeps working because nothing forces it to stop. The access-control problem doesn't care whether the user touching the system is a person, a service account, or increasingly an AI agent acting on someone's behalf — but our processes for revisiting access tend to only trigger on human events like an employee leaving. A service account never leaves.
Picture a hypothetical team that wired up a reporting tool to pull data from a production database three years ago. The engineer who set it up left the company eighteen months later. The reporting tool itself was deprecated a year after that. The database credential it used, however, was never rotated, never reviewed, and still has read access to tables well beyond what reporting ever needed. Nobody did anything wrong at any single step — each decision was locally reasonable — but the cumulative result is a standing credential with no owner, no expiry, and no one who would notice if it were used for something other than its original purpose. That's the common failure mode: orphaned access isn't usually the product of a single bad decision, it's the slow accumulation of reasonable decisions that nobody revisited.
Finding these accounts is mostly a discovery and attribution problem before it's a technical one. The question isn't just 'does this credential exist,' it's 'who is accountable for it, what does it actually touch, and what breaks if we revoke it.' That last question is often the one organizations are most afraid to answer, which is exactly why the inventory never gets done. A reasonable starting discipline is to require every service account to carry metadata at creation time — an owning team, a stated purpose, an expiry or review date — and to treat any account missing that metadata as a candidate for review rather than a permanent fixture. Credentials with no documented purpose and no recent legitimate use are the highest-value targets, precisely because they combine maximum risk with minimum business disruption if retired.
Retiring an orphaned account safely usually means a staged approach rather than an abrupt revocation: flag it, notify any team that might plausibly still depend on it, monitor for a window to see if anything breaks, and only then revoke. This is also where the broader discipline of least privilege matters, independent of whether an account is orphaned or not — a service account that was scoped tightly to begin with does far less damage if it's forgotten than one that was granted broad standing access because that was easier at the time. Scoping access narrowly at creation is cheaper than trying to reconstruct what a credential should have been allowed to do years later, after the people who'd know have moved on.
None of this is exotic. It's the same discipline IAM already applies to human users, applied honestly to the identities that don't show up in an HR system and therefore never trigger the usual review processes. An access-control program that only audits the humans is auditing a shrinking fraction of what actually has standing access to production — the orphaned service account is just where that gap becomes visible.