Treat that as a session-governance gap, not a directory problem. The response is to confirm which applications support session termination or token revocation, then make those steps part of the offboarding path for the systems where lingering access matters most.
What teams should change in offboarding when a session keeps running
Account closure only removes the account record if the session is still accepted elsewhere. Teams need to treat the surviving session as an independent access path, then decide whether the application can terminate sessions, revoke tokens, or force reauthentication. That distinction matters because closure, token lifetime, and session lifetime are often controlled in different places.
Where the application supports it, offboarding should include session invalidation for active browsers, mobile clients, API clients, and any refresh tokens that can silently mint new access. Where it does not, the team needs compensating controls such as shorter session duration, stronger token binding, or a manual escalation path for high-risk accounts.
The key operational question is not whether the directory says the user is disabled, but whether the application still trusts a previously issued session artifact. If the answer is yes, the offboarding workflow is incomplete and the residual access window must be closed explicitly.
Why account closure and session termination are different controls
Directory deprovisioning and session governance solve different problems. Directory closure prevents future interactive logins through that identity, while session termination ends existing authenticated state and token-based access that may already be cached by the application or an identity provider. A system can be correctly disabled in the directory and still remain reachable through a valid session cookie, bearer token, or refresh token.
That split is why practitioners should map the user journey system by system. Some applications will honor upstream deactivation immediately; others will not check account status until token expiry; others only end access when the session store or token revocation endpoint is called. The real control objective is to remove both the identity and the live authorization artifact.
For teams building a repeatable offboarding pattern, the most useful design rule is to tie each application to a specific termination method and a maximum tolerated residual session lifetime. If the application cannot force logout, the control gap should be documented and tracked as a known exposure rather than assumed away.
Where the gap usually lives in the application stack
Session persistence often lives outside the directory layer. Web apps may cache session state locally, mobile apps may hold refresh tokens long after the account is disabled, and API integrations may continue to work until a token is expired or explicitly revoked. That is why the response must include application inventory, not just user status changes.
In practice, the important question is whether the system supports one of three actions: terminate active sessions, revoke refresh or access tokens, or deny continued token introspection. If none of those are available, the application is depending on passive expiry, which is usually too slow for privileged users, high-sensitivity systems, or users with access to regulated data.
Teams should also watch for systems that allow a user to remain signed in across multiple devices after the account is closed. Those are the places where offboarding needs device-level session invalidation, not just a directory update. OWASP ASVS is useful here because it treats session management and authorization as separate verification concerns.
How to make offboarding actually end access
Offboarding works best when session termination is a named step, not an implied side effect. Teams should identify the systems where lingering access is unacceptable, verify the logout or revocation mechanism for each one, and encode that into the offboarding runbook or automation. High-value systems deserve the shortest possible residual session window and the clearest evidence that the session really ended.
For systems that issue tokens, the practical control is often token revocation or sender-constrained tokens rather than account closure alone. For systems that rely on long-lived browser sessions, the control may be forced reauthentication plus immediate invalidation of existing sessions. In either case, the owner of the application should be accountable for proving that the session path is closed, not just that the user record is disabled.
Human vs Non-Human Identity is a useful reminder that the same governance issue appears whenever a session or credential can outlive its owner, and Internet Archive breach 2024 shows how unrotated tokens can let access persist after the original account event should have ended it.
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 surface, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V7 — Session Management | Session persistence and logout behavior are central to the question. |
| Recommendation — Verify that offboarding invalidates active sessions and refresh tokens. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue hinges on revoking authenticators and limiting token lifetime after closure. |
| AC-2 — Account Management | The question is about account closure not fully ending access, which is an account lifecycle gap. | |
| Recommendation — Revoke authenticators and expired session material during offboarding. Link account disablement to explicit session termination steps. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity lifecycle governance must include how access ends after closure. |
| Recommendation — Define identity offboarding so closure also removes live access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Persistent access after closure is the core offboarding failure mode. |
| Recommendation — Ensure offboarding revokes every still-valid access path. | ||
Practitioner Guidance
What to verify: Before trusting offboarding, confirm whether each application can invalidate active sessions, revoke refresh tokens, or otherwise prevent silent reaccess after directory closure. If the answer depends on token expiry only, treat that as a control weakness for anything beyond low-risk access.
Decision rule: If the user can reach sensitive data, administrative functions, or production systems through an existing session, prioritize session termination and token revocation before broader cleanup tasks. If the app cannot do that, shorten session duration and elevate the gap for remediation.
What good looks like: The offboarding record should show the closure action, the session-ending action, and the timestamp when access actually stopped. That evidence is what lets teams distinguish a deprovisioned account from a still-active session.
Practitioner takeaway: Treat session persistence as a separate access-control problem, because a closed account that still has a live session is still an active security exposure.
Related resources from NHI Mgmt Group
- How should security teams respond when a call centre user account or browser session is suspected to be compromised?
- What do security teams get wrong about logout and account closure?
- How should security teams choose user account management software for IAM governance?
- How should security teams respond when a user account appears in multiple breach databases?