Disabling a user in the IdP blocks access governed by the central directory, but it does not guarantee that every external application session or credential is gone. Revoking all access means removing the user’s remaining rights at the application layer too. That distinction matters because offboarding is only complete when both control planes are addressed.
Why Offboarding Must End at the Application Layer
Disabling a user in the identity provider is only the first control plane in offboarding. It stops central authentication, but it does not automatically remove delegated app sessions, cached tokens, local app accounts, or entitlements that were created outside the directory. For SaaS-heavy environments, the practical question is not whether the user is “disabled” somewhere, but whether any external system still recognises them as active.
That distinction matters because application access often persists through separate session logic, API tokens, SCIM delays, or manually provisioned roles. If those paths are not revoked, the former user can remain active long after the directory record is marked inactive. NHI Management Group’s research on lifecycle management and the Ultimate Guide to NHIs shows why offboarding is a lifecycle problem, not a single toggle.
In practice, many security teams discover the gap only after a terminated account still has usable access in one or more applications.
How the Two Control Planes Work in Practice
The IdP and the target application solve different problems. The IdP is the central source of truth for authentication and often for coarse access policy. Disabling the account there usually prevents future sign-ins through SSO, MFA, or federation. But many applications keep their own state: active sessions, refresh tokens, API keys, app-local permissions, shared mailboxes, project memberships, or device trust records. Those must be removed at the application layer if the goal is complete offboarding.
A reliable offboarding process usually follows this sequence: disable the IdP account, invalidate active sessions where possible, remove app-level roles and group memberships, and confirm that any issued tokens or credentials have expired or been revoked. Where automation exists, provisioning and deprovisioning should be driven through lifecycle tooling rather than manual tickets, because manual cleanup is where residual access lingers. The OWASP Non-Human Identity Top 10 is useful here because the same pattern appears with service identities: central disablement does not guarantee downstream revocation.
NHI Lifecycle Management Guide reinforces the operational point: lifecycle control has to follow the identity into every place it was granted access, not just the directory where it was first created. When applications support SCIM, session revocation APIs, or time-bound tokens, those capabilities should be used as part of the offboarding workflow. Where they do not, teams need an explicit verification step to confirm that the former user cannot still authenticate, act, or retrieve data.
These controls tend to break down in federated SaaS environments because authentication is centralised while authorisation and token persistence remain distributed.
Where Teams Get This Wrong
Tighter offboarding often increases operational effort, because each connected application may expose a different revocation method, audit trail, or delay window. The tradeoff is between fast central disablement and complete access removal, and the latter is what actually reduces exposure.
Best practice is evolving, but one consistent mistake is treating “disabled in the IdP” as equivalent to “no longer has access.” That shortcut is especially risky when users have shared collaboration tools, developer platforms, or applications that issue long-lived refresh tokens. Another common gap is forgetting that access may be inherited from groups, service-linked accounts, or delegated app consent rather than a direct user grant.
What to verify: confirm that the IdP disable event is followed by application-side revocation, session invalidation, and removal of all non-IdP entitlements. If an app cannot prove revocation, treat it as a residual-access risk until manual validation is complete.
Practitioner takeaway: The right test is not whether the directory account is disabled, but whether any downstream system can still authenticate or authorise that person after offboarding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Residual app access persists when identities are not fully tracked across systems. |
| NHI-06 — Lifecycle and Offboarding | The question is about completing identity removal across the lifecycle. | |
| NHI-08 — Secrets and Token Hygiene | App sessions and tokens can survive IdP disablement and keep access alive. | |
| Recommendation — Inventory every downstream app entitlement and revoke ownership before closing offboarding. Enforce end-to-end offboarding that disables, revokes, and verifies all access paths. Rotate or revoke tokens and secrets that could outlive directory disablement. | ||
| CIS Controls v8 | 6 — Access Control Management | Offboarding requires removing account and application access rights promptly. |
| 5 — Account Management | The distinction between disabling and revoking is an account lifecycle issue. | |
| Recommendation — Remove stale access rights across applications as part of account deprovisioning. Manage account disablement and deprovisioning as separate verified actions. | ||
| NIST CSF 2.0 | PR.AA-5 — Protective Technology Identity Management | Identity states must be updated across systems to prevent residual access. |
| PR.AA-6 — Identity Proofing, Authentication, and Binding | Persistent app sessions show that authentication state may outlive central disablement. | |
| DE.CM-4 — Detection Processes | Teams need monitoring to detect accounts that still work after disablement. | |
| Recommendation — Synchronize identity deactivation with downstream access removal and verification. Invalidate lingering authentication artifacts when an identity is removed. Monitor for post-disablement access attempts and successful downstream use. | ||
Related resources from NHI Mgmt Group
- What is the difference between disabling a suspected Snowflake user and revoking a suspected secret?
- What is the difference between rotating a secret and revoking access?
- What is the difference between disabling a user in the IdP and fully offboarding access?
- What is the difference between disabling a user account and fully off-boarding access?
