What breaks when organisations rely on account deactivation alone to stop access?

Why This Matters for Security Teams

Account deactivation is often treated like a clean shutdown, but for modern applications it usually changes only the identity record, not the access artefacts already in circulation. Cookies, refresh tokens, API sessions, and cached authorisation state can keep working until the application explicitly revokes them. That is why offboarding, incident response, and access removal are not the same control. The risk is especially acute for NHIs, where long-lived credentials and service automation can outlive the account state that was meant to contain them.

NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often remediation stops at the account layer instead of the token layer. The broader pattern is documented in the Ultimate Guide to NHIs and reinforced by the OWASP Non-Human Identity Top 10, both of which stress that standing credentials and live sessions require separate control points.

In practice, many security teams discover this gap only after a terminated user, decommissioned service account, or abused agent token is still able to call production systems days later.

How It Works in Practice

Effective removal of access needs two different actions. First, the account or identity object is disabled so it can no longer authenticate normally. Second, the systems that issued or accepted live sessions must revoke those sessions directly. That includes web session cookies, refresh tokens, OAuth grants, API tokens, and any NHI secrets that were minted before deactivation. Without that second step, the account may be “inactive” in the directory while the attacker or workload still has a valid bearer credential.

This is why current guidance suggests treating deactivation as a workflow, not an event. The control path should include token introspection, session revocation, secret rotation, and immediate invalidation of privileged integrations. Where possible, use short-lived credentials and explicit TTLs so the blast radius is narrower if revocation is delayed. NIST control language around session management and access enforcement, along with the NIST SP 800-53 Rev 5 Security and Privacy Controls, supports this layered approach.

• Disable the account in the source of truth.
• Revoke active sessions and refresh tokens at the application or IdP.
• Rotate or invalidate any secrets tied to the identity.
• Check downstream systems that cache authentication state.
• Confirm the revocation actually took effect, not just that the account status changed.

For NHI-heavy environments, this matters even more because service accounts and automation often hold reusable tokens, and the Ultimate Guide to NHIs — Key Challenges and Risks shows how often those secrets remain valid long after they should have been removed. These controls tend to break down when applications do not support centralized revocation, because the directory can mark an identity disabled while the token issuer and relying services continue to trust existing credentials.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance fast access removal against application complexity and service availability. That tradeoff becomes visible in legacy systems, distributed SaaS integrations, and agentic workflows where one identity may fan out into many tool calls. There is no universal standard for this yet, but best practice is evolving toward explicit session control, short token lifetimes, and continuous revalidation rather than relying on account state alone.

Edge cases usually appear when the identity is not human. A deactivated service account may still authenticate through a stored API key, a refresh token, or a workload credential embedded in automation. In agentic environments, the problem is worse because an autonomous agent can chain tools and persist in memory or queues even after its parent identity is disabled. The 52 NHI Breaches Analysis is a useful reminder that remediation failures often happen after initial compromise, not at the moment of deactivation.

For incident response, the practical question is not “Was the account disabled?” but “What still trusts credentials issued before the disable action?” If that answer is unclear, account deactivation alone has not actually stopped access.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on access management alone?
• What breaks when organisations rely on MFA and VPNs alone for contractor access?
• What breaks when teams rely on periodic access certification alone?
• What breaks when organisations rely on passwords and OTPs for high-risk access?