Token revocation usually comes first when the incident involves OAuth, refresh tokens, API keys, or other delegated access. Password resets help only if the attacker depended on interactive login. When the compromise path includes connected apps, the priority is to cut off every issued credential and consented integration before restoring user access.
Why Token Revocation Usually Comes Before Password Resets
When compromise is suspected, the first question is not “which account password should be changed?” but “which issued credentials can still be used right now?” Tokens, API keys, refresh tokens, and app consents often survive a password change and can preserve access to mail, SaaS, data platforms, and automation even after the user is locked out. That makes revocation the faster way to cut off active abuse.
For delegated access, the attacker often does not need to keep logging in interactively once a session, refresh token, or connected app has already been granted. That is why teams should treat password resets as one part of containment, not the primary containment control. NHIMG research on NHI exposure shows how often tokens remain active after offboarding, which is a reminder that credential lifetime, not just credential secrecy, drives exposure.
In practice, many security teams discover the gap only after a synced mailbox, SaaS tenant, or API integration has already been used to maintain access.
How the Decision Changes in Real Incidents
The priority depends on how access was obtained. If the suspected compromise involves OAuth grants, refresh tokens, service tokens, API keys, or browser sessions tied to connected apps, revoke those first. If the threat path is mainly interactive login with no durable delegated credential, a password reset becomes more central because it blocks the next sign-in attempt.
- Revoke sessions and tokens that can be invalidated centrally, including refresh tokens and third-party app consents.
- Reset passwords where the account still authenticates directly and where a stolen password could be reused elsewhere.
- Review privilege on linked applications, because a valid token may outlive the password and keep downstream access alive.
- Check whether the compromise is limited to one identity or whether a shared secret, automation account, or SSO integration broadens the blast radius.
In multi-system environments, revocation should be paired with log review to confirm the attacker did not already mint new tokens or create alternate access paths. A password reset without revoking live sessions can leave the original session usable, especially where single sign-on, OAuth consent, or long-lived refresh tokens are involved. One useful rule is to ask whether the compromised credential can still be exchanged for fresh access after the reset; if yes, revocation must lead the response.
Current guidance is evolving, but the consistent operational principle is to remove the attacker’s ability to keep authenticating before restoring normal user access. These controls tend to break down when identity is federated across many SaaS tools because ownership of the token, the session, and the upstream account is split across different administrators.
Common Variations and Edge Cases
Tighter token revocation often increases disruption, so teams need to balance containment speed against user and service availability. The right order is not always the same for every environment, because some systems issue many short-lived tokens while others rely on long-lived credentials with weak central revocation.
When the suspected compromise involves a shared service account, rotating the password may not be enough if the same secret is embedded in pipelines, scripts, or partner integrations. In contrast, if the account is only used for interactive human sign-in and no tokens or connected apps exist, a password reset may be the fastest effective action. The key edge case is session persistence: some platforms preserve access tokens, cached sessions, or delegated grants after the password changes, so teams must verify revocation behavior rather than assume it.
Where possible, organisations should prefer controls that make the access path short-lived and observable. That means treating revocation status, app consent inventory, and session invalidation as part of compromise response, not just account hygiene. If the environment cannot reliably revoke tokens across all connected services, the organisation should assume residual access remains until each integration is checked. Tighter revocation policies also expose weak inventory practices, because teams cannot cut off what they have not identified.
Risk and Threat Considerations
The main risk is residual access: a password reset can create the appearance of containment while stolen tokens, refresh grants, or application consents still allow reuse of the original trust relationship. This is especially material in SaaS and federated environments where one credential can unlock multiple downstream systems.
Failure mechanism: Attackers who obtain a token, session, or API key often bypass future password changes by using the already-issued credential to request new access or continue automated activity. If the organisation resets the password but does not revoke live grants, the attacker may keep operating until token expiry, explicit invalidation, or manual disconnect.
Impact: The compromise can persist across mail, storage, CRM, CI/CD, and automation tools, extending dwell time and increasing the chance of data theft, lateral movement, or re-entry after remediation.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Token and API key revocation is core to machine credential containment. |
| NHI-03 — Lifecycle and Offboarding | Suspected compromise requires rapid invalidation of non-human credentials and grants. | |
| Recommendation — Revoke exposed tokens and reset their trust lifecycle before restoring access. Invalidate compromised NHI access paths and remove lingering grants immediately. | ||
| CIS Controls v8 | 6 — Access Control Management | Access revocation and account reset are direct containment actions for suspected compromise. |
| Recommendation — Remove compromised access rights first, then restore only verified accounts. | ||
| NIST CSF 2.0 | PR.AC-1 — Identities and Credentials Managed | Credential management must prevent compromised access from persisting. |
| Recommendation — Manage credentials so suspected compromise triggers fast invalidation and reissue. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | OAuth and delegated tokens are a common path for persistent access after theft. |
| Recommendation — Hunt for stolen tokens and revoke them to break attacker persistence. | ||
Practitioner Guidance
What to prioritise: Treat the suspected credential type as the decision point. If the account can authenticate through tokens, sessions, or third-party grants, revoke those first; if the account is purely password-based, reset the password immediately and verify no durable sessions remain.
What to verify: Confirm whether the platform actually invalidates refresh tokens, access tokens, and existing sessions on password change. Also verify which connected apps, API clients, and delegated consents remain trusted after the reset, because that determines whether the response is truly contained.
Decision rule: If the attacker could continue access without the password, do not treat password rotation as the containment step. If revocation authority is fragmented across multiple systems, escalate quickly and assume the compromise is still active until each trust path is closed.
Practitioner takeaway: The safest sequence is to stop the current access path first and then change the password, because the attacker’s most useful credential is often the one that no longer depends on the password at all.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on password resets after a phishing compromise?
- When should organisations reset KRBTGT after suspected compromise?
- How should security teams manage token revocation after a platform compromise?
- What should organisations prioritise after a phishing-led compromise, email cleanup or identity containment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
