Disabling an Okta Account Is Not Offboarding
41% of employees keep access to company systems after leaving. Most of that access sits in SaaS tools your IdP never touched. Here is what complete access revocation actually requires.
The offboarding gap
When an employee leaves, IT gets a ticket. They disable the Okta account, maybe revoke a VPN certificate, and mark it done. It takes 30 minutes on a good day.
The problem is that the Okta account is only one layer of access. The average knowledge worker accumulates dozens of independent credentials over their time at a company: apps they signed up for with Google, tools IT provisioned directly, API keys they generated, integrations they configured. None of those go away when Okta goes dark.
What survives after SSO is disabled
SSO and SCIM solve the problem they were designed to solve: federated identity for apps that support it. That covers your core stack well. It does not cover everything, and the gap is wider than most IT teams realize.
The OAuth apps are the biggest blind spot. An employee who signed into Notion with their Google account while still employed will retain access to that Notion workspace indefinitely after their Google account is disabled, if the Google account was disabled but the Notion session or token was not explicitly revoked.
More importantly: IT often does not know which apps fall into which category. The discovery step is missing from most offboarding checklists.
The exposure window
Even when IT has the right processes, timing matters. There is always a gap between when someone's last day is and when all access is confirmed removed. In practice, this gap is often measured in days or weeks, not hours.
The risks that live in that window are not theoretical. Departing employees with lingering access to CRM data, source code, or financial systems represent a real exposure. Most security incidents attributed to former employees do not involve sophisticated attacks. They involve someone using credentials that were never revoked.
The exposure window has three drivers:
- Manual ticket chains. Offboarding triggers a series of tasks assigned to different teams. Each handoff is an opportunity for delay or omission.
- Incomplete asset inventory. You can only revoke access to tools you know the employee used. Shadow IT means the inventory is always incomplete.
- No verification step. Most offboarding processes have no mechanism to confirm that all access has been removed, only that the ticket was closed.
What complete employee offboarding covers
A complete offboarding covers more ground than most IT checklists include. In rough order of priority:
The AI agent complication
Most offboarding checklists were written before AI agents became a standard part of how people work. They have not been updated.
When an employee sets up an AI agent, they typically provision it under their own credentials: their API key, their OAuth token, their service account. The agent acts on their behalf. When the employee leaves, the agent does not automatically stop. Unless someone knows the agent exists and explicitly deprovisions it, it keeps running with access that was supposed to expire.
This is not a hypothetical. Sales teams run agents against CRM data. Engineers set up agents with repository access. Finance teams build agents connected to billing systems. Each of those agents represents a persistent access path that the standard offboarding ticket will not catch.
The fix requires agents to be first-class entities in your access model: registered identities with owners, not anonymous API keys. When the owner is offboarded, the agent should be suspended automatically or reassigned to a new owner with an explicit review step.
From manual to systematic
The reason offboarding security fails is that it depends on humans executing a checklist correctly under time pressure, with incomplete information, for every departure. That model does not scale and does not produce consistent results.
Systematic offboarding ties access removal directly to the HR event. When a departure is recorded in the HR system, the access removal workflow starts automatically. It does not wait for a ticket. It does not require someone to remember the checklist. It fires for every departure, including the ones that happen at 5pm on a Friday.
The inventory problem, the discovery step that most checklists skip, is the hardest part to automate. You cannot remove access to tools you do not know exist. That requires continuous SaaS discovery running ahead of the offboarding event, not a manual audit triggered by it.