Should organisations prioritise token revocation or account disablement first?

Why the sequence matters: containment first, closure second

The practical answer is to disable the account first if you need to stop the person or automation from continuing to sign in, then revoke the remaining grants, tokens, and sessions that may still work after the account is disabled. This is not redundant work. Different applications cache trust differently, and some credentials survive long enough to keep access alive unless you actively remove them.

That sequencing preserves two goals at once: it cuts off interactive use immediately and it reduces the residual access window created by connected apps, refresh tokens, browser sessions, and delegated grants. A disabled account is a control on the primary login path; revocation is the control that removes the alternate paths.

What still works after an account is disabled?

Account disablement usually blocks fresh interactive authentication through the directory or identity provider, but it does not automatically invalidate every token or session issued before the disablement. OAuth grants, refresh tokens, API tokens, long-lived bearer tokens, and application sessions can remain usable until the application, token issuer, or session store processes revocation or expiry.

This is why “disable” and “revoke” solve different problems. Disablement answers “can the account sign in now?”, while revocation answers “can any existing credential continue to act for that account elsewhere?”. In incident response, the second question is often the one that determines whether exposure continues.

• Use disablement to stop ongoing interactive use and prevent new password-based or SSO-based logins.
• Use revocation to invalidate grants and tokens that may still be accepted by SaaS apps, APIs, and downstream services.
• Verify both outcomes, because a control that succeeds in the directory can still fail in an integrated application.

Where the residual risk usually hides

The hardest failures are the ones outside the primary directory boundary. A revoked user may still have an active OAuth consent, a refresh token that can mint new access tokens, or an application session that continues until timeout. API clients may also keep working if they authenticate with separate keys or service credentials that were never tied to the user account.

That is why token revocation should be treated as an application and integration hygiene problem, not just an identity-admin task. In practice, the control surface extends into connected SaaS apps, API gateways, mobile sessions, browser cookies, and any system that can keep accepting an old credential after the account itself is disabled.

For a deeper treatment of token and session behaviour, see the Token and Session Security Guide. When the access path is OAuth-heavy, the revocation problem often sits inside grants and consent rather than the account object itself, which is why the SaaS-to-SaaS and OAuth App Governance Guide is also useful reading.

Risk and Threat Considerations

The main risk is assuming that one control closes every path. If you disable the account but do not revoke tokens, an attacker or unauthorized user may keep using existing access until those credentials expire or are explicitly invalidated. If you revoke tokens but leave the account live, the user can simply authenticate again and recreate access.

Failure mechanism: Trust is split across multiple systems, directory status, consent records, token issuers, and application session stores, so a partial response leaves at least one usable path intact. Long-lived or refreshable credentials make that gap especially dangerous.

Impact: Exposure can persist after the apparent fix, creating continued data access, continued API activity, or repeated re-entry even after the first containment action. In practice, the safest posture is to disable first for containment, then verify revocation everywhere the credential could still be honored.

Practitioner Guidance

What to verify: Confirm that the disablement actually blocks interactive sign-in and that revocation reached every relevant trust point, including OAuth grants, refresh tokens, browser sessions, and any application-specific token store. If you cannot verify a path, assume it may still work.

Decision rule: If the concern is active misuse, disable the account first to stop the user, then revoke credentials and sessions to close residual access. If the account is already non-interactive and the main issue is token exposure, immediate revocation becomes the urgent step, but you should still confirm account status.

Practitioner takeaway: Treat account disablement as containment and token revocation as closure. The response is not complete until both the directory and every downstream application have stopped honoring the identity’s access.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise token revocation or endpoint hardening first?
• Should organisations prioritise token rotation or app inventory first?
• Should organisations prioritise token rotation or behavioural detection first?