in one lineAn orphaned account is any login that stays active after the person it belongs to has left the organization.
the numbers
- 83%of employees still have access to a previous employer's account (self-reported)Beyond Identity, 2022
- 241 daysdays to identify and contain the average breachIBM Cost of a Data Breach, 2025
- 82%of intrusions are malware-free; attackers simply log inCrowdStrike Global Threat Report, 2026
1what 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.
2why 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.
3what 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 it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- it happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
- it happenedCloudflare, 2023howA key or token set up for old work keeps working after everyone forgets it.what leavesinternal systems and documentswho ends up with itwhoever tries the key first
4what 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.
on the record
your turn
what you can do about it
this week
Find accounts with no sign-in for ninety days in your main systems.
Disable them, and see who complains.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →