Because a user can lose one access path and still retain another. If device locking, account disablement, and application removal do not happen from the same controlled workflow, residual access can remain on the endpoint or in downstream apps after the identity has supposedly been removed.
Why separating device revocation from app revocation breaks offboarding
Offboarding fails when revocation is treated as two disconnected actions instead of one controlled state change. A user may be locked out of the corporate account but still keep a trusted device session, cached token, or local app session long enough to continue working. If the endpoint, identity record, and application entitlements are not revoked together, the offboarding state is incomplete.
The practical problem is that each control removes a different access path. Device actions limit what can be used on the endpoint, while app actions limit what the identity can do inside the service. When those events are not synchronized, the “removed” user can still authenticate through a surviving session or a secondary app path, especially where session lifetime, token validity, or offline access are involved.
That gap is why a workflow can look successful in one system and still leave effective access in another. The safer design is a single orchestration point that drives device lock, account disablement, token revocation, and app removal as one recorded offboarding event, with clear dependency order and confirmation that downstream systems actually received the revocation signal.
What actually remains accessible after partial revocation
Partial offboarding usually leaves behind one of three things: a surviving endpoint trust relationship, an active application authorization, or a valid credential artifact such as a session token. The user no longer appears active in the directory, but the app or device may still trust an earlier state until its own checks catch up.
This is most visible when organizations separate IT device actions from application administration. A laptop can be wiped or locked while the SaaS app still accepts an existing session, or the app can be disabled while the device still holds offline files, local caches, or authenticated browser state. The residual path is often narrow, but narrow is enough when the offboarding goal is complete removal of access.
Good offboarding therefore depends on joining identity lifecycle, endpoint control, and application entitlement management into one workflow. The lifecycle event should be the source of truth, not a collection of independent tickets that may close at different times or fail in different queues.
Why offboarding must be treated as a lifecycle control, not a cleanup task
Offboarding is a lifecycle control because the security outcome is measured by what remains reachable after the user leaves, not by whether one ticket was completed. That is why joiner-mover-leaver processes matter: they define the point at which access ends, how revocation is propagated, and what evidence proves the change happened everywhere it needed to.
When offboarding is split across teams, ownership becomes ambiguous. Device management may assume the app owner will remove access, while the app owner assumes the endpoint team has already cut off device trust. The result is a handoff gap, and handoff gaps are where stale access tends to survive. A useful internal reference for this control plane is the Joiner-Mover-Leaver (JML) Guide, which centers revocation as a lifecycle process rather than a single technical step.
The same lifecycle logic applies to identity governance and entitlement review. If a user is removed in one system but not the others, the organization has not actually completed deprovisioning. The most reliable offboarding workflow is the one that can prove the identity, device, and app states all converged to “no access.”
Risk and Threat Considerations
Separated revocation creates a residual-access window that attackers and insiders can exploit before the last trust path disappears. That window can be short, but it is enough for data access, message retrieval, file sync, or token reuse if endpoint and app state are not revoked together.
Failure mechanism: one control removes the visible account while another system still trusts the device, cached session, or app authorization, so the user retains an alternate way in.
Impact: sensitive data can remain reachable after termination, and a supposedly completed offboarding can become a privilege-retention event instead of an access removal event.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding gaps leave residual non-human or user access after removal. |
| NHI-07 — Long-Lived Secrets | Residual sessions and tokens can outlast account removal and preserve access. | |
| Recommendation — Synchronize device, session, and app revocation before closing the offboarding event. Shorten token and credential lifetime so offboarding actually ends access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Revocation depends on invalidating credentials, tokens, and authenticators cleanly. |
| AC-2 — Account Management | Account disablement must be coordinated with other access paths during offboarding. | |
| AC-6 — Least Privilege | Residual access after offboarding is a privilege-retention failure. | |
| Recommendation — Revoke or expire authenticators as part of the same deprovisioning workflow. Disable accounts only after connected systems have been updated to remove access. Remove all entitlements and secondary access paths when a user leaves. | ||
Practitioner Guidance
What to verify: verify that the offboarding workflow invalidates sessions, revokes app access, and removes device trust from the same source event, then confirm each downstream system acknowledged the change. If any step depends on a separate team to “follow up later,” treat it as incomplete.
Decision rule: if the user can still authenticate from any trusted endpoint, cached token, or integrated app after offboarding, prioritize revocation convergence before closure. Separate closure in ITSM does not equal effective deprovisioning.
Practitioner takeaway: offboarding is only finished when every surviving access path is gone, because attackers and ex-users do not need all paths, they only need one.
Related resources from NHI Mgmt Group
- Who is accountable when offboarding workflows fail to remove device access and application access in time?
- Why do vendor access workflows often fail at offboarding?
- Why do business verification workflows fail when UBO checks are separate from KYB?
- What breaks when device offboarding is not tied to identity revocation?