Because cached sessions and local device state can preserve access briefly after central account disablement. If the identity provider is shut down first, the user may still have a usable session until the endpoint is locked. Coordinating the two steps reduces the window in which a departing user can continue working after termination.
Why the order matters in deprovisioning
Device lock needs to happen before identity deactivation because endpoint state can outlive central account state. A locally cached session, saved token, or already-open application can keep working briefly after the directory or identity provider is disabled. The security issue is not that deactivation fails, but that the device may still have enough state to continue operating until the endpoint is cut off.
That short gap is why termination workflows should treat the device as part of the access path, not just the directory account. If the identity is removed first, the organisation can create a window where a departing user still has usable local access, especially on managed laptops, mobile devices, and SSO-backed applications with active sessions.
What actually keeps access alive after deactivation?
Three things usually matter: cached credentials, persistent sessions, and local application state. In practice, the user may not need to re-authenticate immediately, because the device can already hold a valid browser session, refresh token, or app session cookie. That means central disablement reduces future authentication, but it does not always revoke what is already present on the endpoint.
This is why session lifetime, token revocation, device management, and endpoint lock are related but not identical controls. A strong offboarding process assumes that some access paths are stateful and may continue until they are explicitly interrupted on the device itself. The goal is to collapse both the central trust relationship and the local execution path as close together as possible.
How to think about the handoff between device and identity controls
The practical sequence depends on whether the priority is immediate containment or low-friction workflow. For a routine departure, teams often prefer a controlled sequence that locks the device, revokes sessions, then disables the account. For a suspicious departure or confirmed compromise, the sequence should be tightened so the endpoint is isolated first and all active sessions are cut as quickly as possible.
That ordering also explains why offboarding needs coordination across identity, endpoint, and help desk processes. Identity disablement alone answers “can this account authenticate again?” Device lock answers “can the current endpoint keep using what it already has?” Those are different questions, and both matter during termination.
Risk and Threat Considerations
The main risk is a residual-access window after termination, where a user can continue working from a live endpoint even though the central account has been removed. That window becomes more important when the device is unattended, the session is long-lived, or the user has access to sensitive systems through already-established browser or application state.
Failure mechanism: Central deactivation removes future logons, but it does not instantly invalidate every active session or locally cached trust decision. If the endpoint remains unlocked, the user can exploit that surviving state until the device is locked or the session is forcibly expired.
Impact: The organisation can lose control over data exposure, internal access, and post-termination activity, especially when departure is contested, delayed, or part of an incident response case. In the worst case, the lingering session becomes a short-lived but meaningful opportunity for unauthorized access, data removal, or privileged action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account disablement and offboarding sequence directly depend on account lifecycle control. |
| IA-5 — Authenticator Management | Cached sessions and tokens are authenticator material that can preserve access after deactivation. | |
| AC-12 — Session Termination | The question centers on ending active sessions that survive central account disablement. | |
| Recommendation — Coordinate account disablement with endpoint lock and session revocation in offboarding. Revoke or expire authenticators and sessions when ending user access. Ensure active sessions terminate when the user is offboarded or the endpoint is locked. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | This is an access lifecycle and termination-order issue affecting ongoing access. |
| RC.RP-01 — Recovery Plan Execution | Offboarding and containment need an ordered response procedure when access must end quickly. | |
| Recommendation — Align identity deactivation with endpoint lock and session invalidation. Define and rehearse the sequence for disabling access and locking devices. | ||
Practitioner Guidance
What to verify: Confirm whether your offboarding flow actually terminates active sessions, not just directory access. If the identity provider or directory action does not invalidate browser sessions, application tokens, or device trust state, then device lock must be treated as a separate control step, not a courtesy task.
Decision rule: If the user may still be signed in on a managed endpoint, lock the device before or at the same time as disabling the identity. If there is any suspicion of misconduct or compromise, prioritise endpoint containment and session interruption first, then complete account deactivation and evidence preservation.
What good looks like: The endpoint cannot continue to use an existing session after the central account is removed, and the offboarding record shows a clear sequence for device lock, session revocation, and identity disablement. That is the state you want to be able to prove after the fact.
Practitioner takeaway: Treat device lock and identity deactivation as coordinated containment actions, because the security objective is not just to remove the account, but to eliminate every practical path the user could still use from the endpoint.
Related resources from NHI Mgmt Group
- What should organisations measure before consolidating identity and device administration?
- What should organisations do before consolidating identity and device management?
- Why do device retirement and identity offboarding need to happen together?
- How should identity teams stop device-farm fraud before biometric checks run?