What breaks when organisations disable the user but leave credentials and tokens active?

Offboarding fails because the real access path is not the directory account alone. Local passwords, OAuth grants, refresh tokens, API tokens, and sessions can keep working after the user is removed, which means the organisation has only partially revoked access. The control failure is incomplete lifecycle closure, not weak authentication.

Why This Matters for Security Teams

Disabling a user account without revoking the credentials behind it creates a false sense of containment. The directory entry is only one access path. If local passwords, OAuth grants, refresh tokens, API keys, certificates, or live sessions remain valid, the former user can still act inside cloud apps, SaaS platforms, and automation pipelines. That is why offboarding is a lifecycle control, not an HR checkbox.

This failure mode is especially dangerous when the user had access to shared integrations, admin consoles, or delegated applications. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls expects revocation to be part of access termination, not an optional follow-up. In NHIMG research on token abuse, the Salesloft OAuth token breach illustrates how stolen or lingering tokens can outlive the user account that originally authorized them.

Security teams often discover this only after an investigation shows the “disabled” account was still indirectly active through an app grant, cached session, or long-lived secret that nobody thought to rotate.

How It Works in Practice

Effective offboarding treats identity revocation as a sequence of actions across every authentication and authorization layer. First, disable the directory account. Then revoke active sessions, invalidate refresh tokens, remove OAuth consent grants, rotate or retire API keys, and replace any shared secrets that the user could have accessed. In many environments, the highest-risk items are not human passwords but the machine-facing credentials buried in scripts, CI/CD jobs, browser stores, and SaaS integrations.

That is why the right mental model comes from the NHI side as well. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why static credentials create durable blast radius, while dynamic, short-lived secrets reduce the chance that access survives the original trust decision. The OWASP Non-Human Identity Top 10 similarly emphasises secret lifecycle control and least privilege for non-human access paths.

• Revoke the account and every session, not just the primary login.
• Audit OAuth consents, delegated tokens, and service-to-service grants.
• Rotate shared secrets, especially where a user could copy them out of band.
• Check automation, scripts, and agents for embedded credentials tied to that person.
• Confirm downstream systems accepted the revocation and did not cache trust.

Where organisations are moving toward stronger posture, they also use short TTLs, just-in-time access, and policy enforcement that can invalidate access at runtime rather than waiting for periodic reviews. These controls tend to break down when tokens are minted by third-party apps with weak revocation support because the directory can be disabled while the authorization grant remains valid elsewhere.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance faster containment against integration complexity. That tradeoff is real because some SaaS tools, older VPNs, and legacy systems do not support immediate token invalidation or consistent session management. Current guidance suggests treating those systems as exceptions that require compensating controls, not as proof that revocation is impossible.

One common edge case is shared automation. If a person leaves but their service account, CI secret, or delegated admin token remains active, the “disabled user” change has almost no practical effect. Another is federated access: a directory account may be closed, yet an IdP-issued refresh token or a cloud console session may continue until expiry. NHIMG’s Guide to the Secret Sprawl Challenge shows why these exposures often persist in places teams are not monitoring, including collaboration tools and build systems.

For identity assurance, the relevant principle in NIST SP 800-63 Digital Identity Guidelines is that authentication events and credentials must remain trustworthy for the full life of access. In practice, organisations should assume that any still-valid token, key, or session is a live control failure until proven otherwise.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?