Deprovisioning is the act of removing a person's access when they leave or no longer need it. Not just switching off their login. Removing the access itself, everywhere it exists, and proving it happened.
The word gets used loosely. Most of the time someone says "we deprovisioned them," what they mean is they disabled the account in Okta or Entra. That stops single sign-on. It does not stop the person logging into an app that kept its own local account, or an API token they generated six months ago, or the reporting tool finance bookmarked that never went through SSO.
What deprovisioning actually covers
A complete deprovisioning event touches five things.
Accounts. Every account the person held, disabled or deleted per policy, including local accounts that live inside the app rather than the directory.
Permissions and group membership. Not just the top-level account. The specific entitlements, channels, repositories, and admin roles they accumulated over time.
Sessions and tokens. Active sessions ended, refresh tokens invalidated, personal access tokens and API keys revoked. An account can be disabled while a token keeps working.
Owned data and resources. Files, calendars, dashboards, and service accounts the person owned, transferred to a successor or archived, so nothing is orphaned or lost.
The record. A timestamped log of every action, mapped to the trigger, exportable for an audit.
If a process handles the first item and skips the rest, it is disabling an account, not deprovisioning.
Why it fails in practice
Two failures show up again and again.
The coverage failure. SSO and SCIM together automate provisioning and deprovisioning for the apps that support the standard. That is a minority of the stack. Everything else, the standard-plan SaaS, the internal tools, the legacy system someone set up years ago, falls back to a checklist that a human runs by hand. The checklist is where accounts get missed.
The timing failure. Even when the checklist is complete, it runs late. HR marks the departure, IT gets to it during the next ticket sweep, and the person keeps access in the meantime. For a routine resignation that gap is a formality. For a contentious exit it is a real risk.
What good deprovisioning looks like
One trigger, usually a status change in the HRIS, starts the whole sequence. Access is removed across every connected system, human and non-human, in the same run. Data ownership transfers happen alongside the revocations. The audit trail writes itself. Nobody works a ticket, and nobody has to remember the app that is easy to forget.
The test is simple. When someone leaves on a Friday, can you show by Monday that every account they held is closed, without anyone having opened an admin panel to check? If the answer depends on a person remembering, deprovisioning is still manual.
Related terms
- Provisioning. The opposite direction: granting access as people join and change roles.
- Orphaned account. What deprovisioning is meant to prevent: an account with no active owner.
- Joiner-mover-leaver (JML). The lifecycle model deprovisioning sits inside, covering the leaver stage.
- Access revocation. A narrower term for removing a specific grant, one component of deprovisioning.