An orphaned account is an active credential that belongs to someone who no longer needs it: typically a former employee, departed contractor, or decommissioned service. The account is live. The password works (or the API key works, or the OAuth grant is active). Nobody at the company is monitoring it or knows it exists.
Every company that has run an honest cross-system access audit has found these. Not as a rare exception, but as a systematic finding.
Why orphaned accounts accumulate
Orphaned accounts accumulate through two predictable mechanisms.
The first is incomplete offboarding. SSO gets disabled. The apps that were provisioned through SSO get deprovisioned. The other 60 to 70 percent of the stack (apps provisioned independently, apps the employee added themselves, apps adopted after the standard checklist was written) doesn't get touched. The departed employee's accounts in those apps stay active.
The second is non-SSO app sprawl. The apps that generate the most orphaned accounts are the ones outside the SSO perimeter: older SaaS tools that predate the IDP deployment, industry-specific software with proprietary auth, internal tools with local accounts, vendor portals, apps on free plans that don't support SSO. These are invisible to standard lifecycle management and get cleaned up only if someone builds and maintains an explicit manual workflow, which usually doesn't happen.
The security and compliance risk
Not all orphaned accounts have the same risk. An orphaned account in a marketing analytics tool is less concerning than an orphaned account in your cloud IAM console, your production database, or your customer data platform.
The security risk is straightforward: valid credentials that nobody is monitoring can be used without triggering any alerts. The account doesn't show up as anomalous because it looks like any other inactive account. If those credentials were phished, leaked, or reused across other services the former employee used, the attacker has access that could persist undetected for months.
The compliance risk is equally real. SOC2, ISO 27001, and most other frameworks require that access be revoked when it's no longer needed. An orphaned account is documented evidence that this requirement failed. Finding one during an audit is a finding. Finding a pattern of them is a significant finding.
What an orphaned account audit actually finds
At a 150-person company that ran a cross-system access audit, the methodology was straightforward: pull all active accounts from every app in the inventory, cross-reference against the current employee list from the HRIS, flag every account that doesn't match a current employee or a known service account.
The result: 43 orphaned accounts across 31 applications. The company had experienced 28 departures in the previous 18 months. The accounts ranged from 2 months old (a recent miss) to 26 months old (a gap that had been sitting since before their current IT manager joined).
This is representative. If you haven't run this audit recently, you almost certainly have orphaned accounts. The only question is how many and in which systems.
The fix for the specific accounts is straightforward: revoke them. The fix for the pattern is automated lifecycle management that closes the coverage gap between SSO-managed apps and everything else.