An orphaned account is an account that still exists and often still works, but has no valid owner behind it. The employee left. The contractor rolled off. The role changed. The account did not go anywhere.
Orphaned accounts are not an edge case. They are the normal byproduct of deprovisioning that misses systems, and every stack that offboards by checklist accumulates them.
How they accumulate
There is rarely a single dramatic failure. It is a slow drip.
Someone leaves, SSO is disabled, and one app that kept a local login is missed. A contractor finishes a project, but their access was granted ad hoc and never tied to an end date. An engineer spins up a service account for a migration, then leaves the company two years later while the account keeps running. Each of these is one account. Across a few hundred people and a few dozen apps, over a few years, they add up to a population nobody has a full list of.
The apps outside SSO are where they concentrate. If an app honors the directory, disabling the person usually closes the account. If it does not, the account persists until someone remembers it by hand.
Why they matter
Two reasons, security and compliance.
On security, an orphaned account is access with no accountability. No active employee is tied to it, so nothing about its behavior looks out of place. It sits there as an available entry point, and dormant, unwatched accounts are a standard target for credential stuffing and lateral movement. The account that logs in once a year is the one nobody notices being used by someone else.
On compliance, orphaned accounts are a direct finding. SOC 2 CC6 and ISO 27001 access controls expect that access maps to current, authorized people. An auditor who samples accounts and lands on a former employee with a live login has found exactly what the control exists to catch.
Finding and clearing them
The method is reconciliation: take every account in every app and match it against the current list of active identities. Anything that does not match is a candidate for removal. Former employees, unused local accounts, external guests who were added once, service accounts with no owner.
The hard part is coverage. Reconciling the SCIM-connected apps is straightforward because those accounts are visible to the identity provider. The orphaned accounts that matter most live in the apps the identity provider cannot see: standard-plan SaaS, internal admin panels, legacy systems. Finding those requires connecting to each app directly and pulling its actual account list, not just trusting the directory.
Once found, each account is either reassigned to a valid owner, archived, or removed, with the decision recorded. The recurring version of this is an access review, which catches the accounts that slip through between offboarding events.
Related terms
- Zombie account. A dormant account, whether or not it still has an owner.
- Deprovisioning. The process meant to prevent orphaned accounts.
- User access review. The recurring check that catches accounts missed during offboarding.
- Non-human identity. Service accounts and tokens, which become orphaned when their creator leaves.