What Deprovisioning Actually Means
Deprovisioning is the act of disabling or removing access when the relationship that justified it ends. An employee is terminated. A contractor's engagement expires. A vendor's contract closes. A person changes roles and no longer needs the access tied to the old one. In each case the correct outcome is the same: every credential, session, and permission tied to that access stops working, on schedule, everywhere it exists.
That last part, everywhere it exists, is where most programs quietly fail. Deprovisioning gets treated as a subsection of a broader identity governance framework, a checkbox inside a bigger policy document. Treated that way, it inherits governance's cadence: periodic reviews, quarterly certifications, annual audits. Access revocation doesn't work on a quarterly cadence. It has to happen within hours of the trigger event, across every system the person touched, or the gap between "should no longer have access" and "no longer has access" becomes the exposure window.
Why SSO Doesn't Cover Everything
Single sign-on makes deprovisioning look solved. Disable the account in Okta, Entra ID, or Google Workspace, and it looks like every downstream app goes dark with it. In practice, disabling the identity provider account stops new authentications. It does not retroactively invalidate everything that authentication already produced.
An OAuth refresh token issued to a connected third-party app can keep minting new access tokens until it's explicitly revoked at the app itself, not at the identity provider. API keys and personal access tokens generated inside a connected service, GitHub, AWS, a CI/CD platform, a cloud provider's service account, are typically independent credentials that never check back with the IdP at all. Some admin consoles cache authorization state and only re-validate at session expiry, which can be hours or days out. The IdP account going dark is necessary. It is not sufficient.
SaaS Sprawl Outside SSO Scope
The bigger problem sits upstream of tokens: a meaningful share of the SaaS a person actually used was never federated to the identity provider in the first place. Deprovisioning through the IdP only reaches what the IdP knows about.
- Tools purchased on a team card, outside procurement, and never connected to SSO.
- Free-tier or trial signups made with a work email but never wired into the identity provider.
- Vendor-side accounts created directly in a client's or partner's own portal, with no federation on either end.
- Per-seat subscriptions a manager added ad hoc to unblock a project.
Each of these is a login the offboarding process never touches, because the app never checked with the identity provider to authenticate the user in the first place. The account isn't missed because someone forgot it. It's missed because nothing in the deprovisioning workflow knew it existed.
The Manual Checklist Problem
Where deprovisioning isn't automated, it runs on a checklist: an HR ticket that fans out into manual steps across IT, security, and individual app owners. Checklists fail in two distinct ways. The first is execution: under time pressure, on a fast termination or a same-day exit, steps get skipped or done out of order, and nobody circles back to confirm they finished. The second is coverage: the checklist only lists systems someone remembered to add to it, which routinely excludes contractor and vendor access that was never provisioned through a formal HR onboarding event and therefore has no natural offboarding trigger either.
A contractor's access usually ends on a date written into a contract, not an event that fires in an HR system. Unless something is explicitly watching that date, it passes quietly, and the access outlives the engagement.
Time-to-Revoke: The Metric That Matters
Most offboarding programs measure whether the identity provider account was disabled inside a target window, often same-day or within 24 hours. That's a measurement of one system, not of the person's actual access footprint. The metric that reflects reality is time-to-revoke: the interval between the moment access should have ended and the moment every credential tied to that access, the IdP account, OAuth tokens, API keys, admin panel logins, vendor portal seats, is actually revoked. A same-day IdP disable next to a six-week-old API key isn't a fast deprovisioning process. It's a fast first step in a slow one.
NIST SP 800-53's AC-2 control family, Account Management, includes AC-2(3), Disable Accounts, which calls for disabling accounts within an organization-defined period once they are no longer associated with an individual or are otherwise no longer needed. That control targets the account, not the full footprint behind it, which is exactly the gap this piece is about. Delayed deprovisioning of a departed employee or vendor account is a recurring root cause named in real post-incident reports, not a hypothetical risk.
Closing the Gap
Three things move time-to-revoke in the right direction. First, trigger deprovisioning off the event that actually ends the relationship, an HRIS termination record or a contract end date, instead of waiting on a manually filed ticket. Second, inventory the SaaS that sits outside SSO scope before it becomes an offboarding gap. An application that isn't federated needs its own explicit revocation step, because no amount of IdP automation will reach it. Third, stop treating account-level revocation and entitlement-level revocation as the same job. Disabling a login is one action. Finding and revoking every group membership, API key, and delegated permission that account accumulated is another, and it's usually the one that gets skipped.
Deprovisioning is the leaver half of the joiner-mover-leaver lifecycle covered in Identity Governance and Administration, and disabling an account is a different operation from revoking everything it was entitled to, which is where entitlement management picks up.