Orphaned accounts

what it is

Orphaned accounts are user accounts that remain active in your systems after the person they belong to is no longer employed or engaged. The term covers full-time employees who left, contractors whose projects ended, and freelancers whose work wrapped up.

The account exists, can authenticate, and in many cases retains the permissions it held at the time of departure. The directory entry may show as disabled. The SaaS apps, cloud storage, code repositories, and third-party integrations often don't know that.

The gap between "directory says disabled" and "every system has been updated" is where orphaned accounts live.

why it accumulates

Offboarding depends on a complete list of everywhere someone has access. That list doesn't exist in most environments without a dedicated tool.

IT knows the main directory. HR knows the employment record. But the project management tool someone added themselves, the analytics platform they connected directly, the shared login someone set up during an urgent project: all of those live outside the primary offboarding checklist.

Every employee adds informal access over time. By the day they leave, the number of systems they touch is typically larger than the number in any documented list. Manual checklists can only close what they can see.

There's also a timing problem. Access revocation often depends on HR telling IT, IT running the process, and each application responding. Each handoff is a potential delay or a step that simply doesn't happen.

what it costs you

The main risk is straightforward: a former employee or contractor can log in after they've left. What they do with that access depends on intent, but the possibility exists whether or not anything bad happens.

According to IBM's Cost of a Data Breach report (2025), it takes an average of 241 days to identify and contain a breach. Orphaned accounts can sit open across that entire window, with no alert, no review, and no mechanism to notice.

Beyond the security exposure, there's an audit implication. SOC 2, ISO 27001, NIS2, and DORA each require evidence that access is controlled. An auditor asking "who has access to this system" and receiving an answer that includes former employees is a non-conformity that requires remediation and documentation.

There's also a practical operational cost. Licenses for applications assigned to accounts that no longer serve a purpose continue to accrue.

what works

The fastest detector is a comparison between two lists that already exist: the active user list from the directory or IdP, and the HR system's record of terminated employees. Accounts active in the directory but terminated in HR form the immediate review queue. The same comparison then runs at the application layer, because the directory only covers what's connected to it: each SaaS application's active user list against the active employee directory, with anyone present in the app but absent from the directory either orphaned or on a login that bypasses the IdP.

Direct logins deserve a deliberate look of their own. Accounts created with personal email addresses or standalone credentials never appear in an IdP export, so the tell is users inside an application whose addresses match no expected domain pattern. Service accounts hide a quieter version of the same problem: the owner or creator field often names someone who left years ago, leaving a running credential with no current owner and no review history.

What experienced operators do with a found orphan is disable rather than delete. Deletion permanently removes configuration, history, and ownership records in many systems; disabling terminates the access just as completely while preserving the record. Deletion can follow later, once it's clear nothing depended on the account and nothing in its history is still needed.