Users may keep working after the identity provider marks them inactive, which means the control exists on paper but not in practice. Deprovisioning stops new authentication, but it does not automatically invalidate sessions, refresh tokens, or API keys. If those artifacts remain valid, the user can continue accessing systems until they expire or are explicitly revoked. That gap is what security reviewers are trying to expose.
Why leaving active sessions alive breaks deprovisioning
deprovisioning only works if it removes every path the person or process can still use. If active sessions remain valid, the user is no longer supposed to be trusted, but the environment still treats the old session as authenticated. That creates a control gap between account status and real access, and it is especially visible when the old session can still call APIs, access SaaS consoles, or ride a federated login.
The practical failure is that “inactive” becomes a directory state, not an access state. A clean leaver event should end the current trust relationship, not just block the next password check. In a joined system, that means thinking about session cookies, refresh tokens, access tokens, SSH sessions, API keys, and any delegated credentials that can outlive the primary login.
NHIMG’s Joiner-Mover-Leaver (JML) Guide and SCIM and Automated Provisioning Guide both reinforce the same operational point: deprovisioning has to reach the downstream entitlements and credentials, not only the source identity record.
A second way to frame the issue is control durability. If the only action is “disable future logins,” then the control is delayed, not immediate. That may be acceptable for low-risk user flows, but it is not acceptable when the session can still reach sensitive business functions, cloud consoles, admin portals, or machine-facing interfaces.
Which artifacts keep access alive after offboarding
Active access usually persists through one of three mechanisms: a still-valid session, a still-valid bearer token, or a still-valid secret or key. Sessions are the most visible because they often expire naturally, but refresh tokens and API keys can extend access far beyond the intended offboarding window. In practice, the weakest link is often not the account itself but the artifact that was issued before deprovisioning.
That is why lifecycle controls must distinguish between authentication cessation and credential invalidation. Stopping new authentication is only the first step. To actually terminate access, teams need a way to revoke or invalidate the session context, and they need to know which systems rely on cached tokens, long-lived secrets, or federated assertions that may continue to work until their own expiry.
NHIMG’s NHI Lifecycle Management Guide, Workforce Identity Security Guide, and Top 10 NHI Issues all point to the same lifecycle gap: offboarding, rotation, and session invalidation must be treated as one control chain.
In modern environments, this is often where federated SSO creates false confidence. The identity provider may block the next login, but the application may still trust the existing session until it times out, and some back-end services may trust previously issued tokens independently of the user’s directory status. The result is a split between identity state and access state.
What good deprovisioning looks like in practice
Good deprovisioning ends current authority, not only future authentication. The most reliable pattern is to revoke active sessions, invalidate refresh tokens, rotate or revoke any exposed keys, and then confirm that downstream applications and gateways no longer accept the old trust material. For higher-risk roles, the order matters: terminate active access first, then confirm entitlement removal, then check for residual credentials or delegated access.
NIST SP 800-207 Zero Trust Architecture and NIST SP 800-63 Digital Identity Guidelines both support the underlying judgment here: authentication state must be current, and trust should not persist longer than necessary. In practice, that means session revocation and reauthentication policy need to be part of the offboarding workflow, not a separate cleanup task.
For organizations that manage service accounts, the same principle applies to non-human credentials. If a token, key, or certificate can still authenticate after the person or workload is supposed to be removed, then the access path still exists. Workforce Identity Security Guide and IAM and IGA Basics are useful reference points for aligning entitlement review with credential and session control.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sessions, refresh tokens, and keys are credentials that must be revoked or rotated on offboarding. |
| IA-2 — Identification and Authentication (Organizational Users) | The issue is that authentication stops for future logins but existing authenticated access remains. | |
| AC-2 — Account Management | Deprovisioning is an account lifecycle control that must remove active access, not only disable login. | |
| Recommendation — Revoke or rotate authenticator material when access is removed. Require reauthentication and session invalidation for terminated users. Disable accounts and confirm downstream access removal. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity state and access state diverge when offboarding does not fully remove access. |
| A.5.18 — Access rights | Residual sessions and tokens mean access rights persist after deprovisioning. | |
| Recommendation — Maintain identity lifecycle controls that remove access at offboarding. Revoke access rights and verify residual access is gone. | ||
Practitioner Guidance
What to verify: Confirm that your offboarding process invalidates live sessions, not just directory status. A practical test is to terminate a user and then attempt access with any still-open browser session, refresh token, service token, or API key that existed before deprovisioning.
Decision rule: If a credential or session can reach production data or privileged functions, treat it as an active access path until it is explicitly revoked or naturally expires under a risk-accepted window.
What changes at scale: The gap becomes harder to spot when deprovisioning is automated across many SaaS apps and cloud services. At scale, the main failure mode is inconsistent revocation coverage, where the directory is clean but downstream systems keep accepting old sessions or bearer artifacts.
Common mistake: Teams often test only whether a disabled account can log in again. That proves future authentication was blocked, but it does not prove that current access was removed.
Practitioner takeaway: Treat deprovisioning as a termination of authority, not a status update, and verify it against the longest-lived artifact that can still act on behalf of the user or workload.
