Origin
Pranay has watched a dozen prospects run their first honest cross-system access audit in the past six months. The methodology is always the same: pull every active account from every app in the inventory, cross-reference against the current employee list from the HRIS, flag the gaps. The finding is always the same: more than expected, older than they thought, in apps they had forgotten existed.
An orphaned account is an active credential belonging to someone who no longer needs it. A former employee. A departed contractor. A vendor whose engagement ended a year ago. The account is live. The password works. The OAuth grant is still valid. Nobody at the company is monitoring it or knows it exists.
These are not edge cases. They are the systematic finding of every honest audit.
The audit shape repeats across company size
The numbers vary by stack complexity. The shape doesn't.
A 150-person company we sat with last quarter: 43 orphaned accounts across 31 applications. The 28 departures over the prior 18 months had each left behind at least one. The oldest account had been sitting active for 26 months, since before the current IT manager joined.
A 400-person company that ran the same audit: 118 accounts across 47 apps. The cluster was around vendor portals and finance tools that nobody on IT thought to check.
A 90-person company: 19 accounts across 14 apps. Smaller absolute numbers, same proportion of departures with leftover access.
The variance is in magnitude. The constant is that every company finds them. The only outlier is the company that hasn't looked.
Where the orphans hide
The orphans cluster in four predictable places.
The apps outside SSO. SSO covers the apps that support SCIM or SAML. The rest get provisioned manually and get deprovisioned (or not) manually. At most companies, SSO governs 20 to 30 percent of the actual app inventory. Everything else is a manual workflow.
The apps the employee added themselves. The free-plan signup, the credit-card-without-procurement signup, the trial that quietly became permanent. These never made it onto the offboarding checklist because IT never knew they existed.
The legacy apps with local accounts. The on-prem tool, the industry-specific software, the vendor portal that doesn't support modern auth. Local credentials, local password resets, no connection to anything else.
The shared accounts. The "marketing@" inbox, the salesops Salesforce login that three people use, the AWS root credentials in a password manager. Shared accounts don't appear in any individual's offboarding profile, so they don't get reviewed when individuals leave.
Why it's the design, not an exception
Standard offboarding handles the SSO-managed apps. Those get deprovisioned automatically when SSO is disabled. The other 70 percent of the stack relies on someone remembering to log into each system and remove the account.
That remembering happens under time pressure, without a centralized list, while the rest of the IT queue is still moving. It fails reliably. A process that fails reliably isn't an exception to the design. It is the design.
What changes when you close the gap
The fix for the specific accounts is straightforward: revoke them. The fix for the pattern is harder. Every app in the environment needs a way to deprovision an account programmatically (SCIM where supported, automation where not). Lifecycle automation has to run across every app, not just the SSO-managed subset.
Teams that close this gap stop describing offboarding as a process. They describe it as a state: when someone leaves, every account they had is closed within minutes. Not because someone worked the checklist faster. Because the checklist doesn't exist anymore.