Origin
Every customer who runs their first discovery scan with us finds the same thing. A handful of former employees, still active in apps the offboarding checklist never touched. This post is what the pattern looks like from inside one of those departures.
The departure was clean. Two weeks notice. A good exit interview, professional and measured, the kind where both sides say the right things and mean most of them. On the last day, the manager bought coffee for the team. HR processed the paperwork. IT got the ticket.
IT closed the Okta account. Ticket closed.
That's where most offboarding ends. Not because anyone decided the rest didn't matter, but because the rest of the stack isn't inside Okta. Okta governs the apps connected to it. At a typical company, that's around 23 applications. The other 84 aren't connected. They don't receive a signal when Okta closes. They don't know anyone left.
So when the Okta account closes, those 84 apps don't move. Accounts active, permissions intact, access open, until someone manually works through each one. Which means: until someone thinks to work through each one, has the admin credentials to do it, knows the person had access in the first place, and finds the time before the next ticket lands.
Most of the time, that doesn't happen in any organized way. Sometimes it doesn't happen at all.
The customer support admin tool the team built in-house, three years ago, when no SaaS option fit. Their role record is still in the permissions table. The tool checks against that table on every login. They can still log in. They can still see the support queue for accounts they used to own.
Their Active Directory account is disabled. Their permission on the on-prem file share where legal keeps unredacted contracts is not. Disabling AD closes Windows login. The share had its own ACL set the day it was created. That ACL still names them. They no longer have a path through SSO, but the share doesn't ask SSO.
The production database account they used for ad-hoc exports last quarter is still active. The credentials are in a password manager somewhere. The DBA who provisioned them isn't sure who, on the current team, still has them.
The CRM where their accounts and renewal forecasts live shows them as an active editor. The CRM connects to SSO for login. Membership lives in a separate roster the SSO doesn't write to. Login is closed. Membership is not.
Their GitHub personal access token is still valid. Personal access tokens don't expire when the SSO account closes. The token is tied to a GitHub account, which is tied to an email address, which still exists. The repositories that token could reach are still reachable.
The AWS IAM role they assumed for staging deployments: still assumable. The Stripe restricted key they generated for a one-off reconciliation script: still valid. The Twilio number they bought for a pilot last summer: still billing. The dashboard their team built in the BI tool, six months ago, on top of the data warehouse: still loads when they log in, because the BI tool reads its user list from a sync that runs every Sunday.
None of this required a decision. It required nothing. It just stayed open, because the system that closed one account had no view into the others.
This is not a hypothetical. It's a structural feature of how offboarding works at most companies, not because IT teams are careless, but because the offboarding process runs to the edge of the identity system and stops there. The identity system covers what it covers. Everything else is a checklist, usually written by whoever had time, usually a few versions out of date, usually missing the apps that were adopted after it was written.
The checklist says: revoke access to core systems. Core systems, in practice, means the ones IT provisioned directly and remembers to include. Not the tool the marketing team has been using for two years on a shared company card. Not the analytics platform someone integrated directly with Google OAuth. Not the tool that predates the current IT stack and got carried over in the migration because everyone was busy.
Fifty-two days. That's the average time an orphaned account sits open after a departure before it's found (if it's found). In most cases, it's not found during an offboarding process. It's found during an audit. Or a discovery scan. Or not found at all.
The person who left last month was professional. The exit was clean. You have no particular reason to worry about them.
But the access is still there, and it will be there after the next departure too. And the one after that.
Most companies' offboarding stops at the SSO boundary. The boundary ends 23 apps in. The stack has 107.
That's not the rest of the story. That is the story.