Revoke refresh tokens, force reauthentication, and review any privileged changes made during the token’s remaining validity window. Then check whether admin roles, security configurations, or mail flow rules were altered before the session was terminated.
What to do in the first response window after token theft
The first job is containment, not forensic perfection. If the stolen token can still be used, assume the attacker may already be replaying it, escalating privileges, or changing settings that survive the token’s expiry. Work from the highest-value access path outward: invalidate the token family, cut off dependent sessions, and preserve enough evidence to understand what the token could do.
Where token theft is the entry point, token and session security controls matter because bearer-style credentials are only safe for as long as they remain both secret and bounded.
Because token theft often travels through OAuth, SSO, or adjacent session material, it is also worth aligning the response to the OAuth 2.0 security best current practice, especially where refresh tokens or sender-constraining were not in place.
What must be checked before the session is fully treated as closed
Do not stop at revocation. The important question is what the token allowed during its remaining validity window. Review privilege changes, new grants, mailbox forwarding, mail flow rules, API app consents, and any configuration changes that would let the attacker keep access after the original credential is dead. If the token was tied to automation, also inspect downstream actions that may have run under delegated authority.
In practice, the review window should cover the period from first probable theft to revocation, plus any subsequent token exchange or reissuance path that might have extended access. For OAuth systems, token exchange and audience scoping can change what an attacker can pivot into, so the investigation should follow the delegated path, not just the original bearer token.
For organisations with identity-heavy SaaS estates, a useful comparison point is the Internet Archive breach, where unrotated tokens allowed later re-entry after the initial compromise had already been noticed.
How to reduce repeat abuse after the incident is contained
Immediate response should feed into durable hardening. That means shortening token lifetime where possible, revoking refresh-token families rather than single access tokens, and binding high-value tokens so a stolen string is not enough on its own. Where the environment supports it, constrain tokens to the intended resource or client so one stolen credential cannot be reused broadly.
DPoP and mutual-TLS client authentication with certificate-bound access tokens are relevant here because they reduce replay value after theft. For governance and operations, a token incident should also trigger review of the surrounding lifecycle, including consent grants, service account scopes, and any long-lived secret that made the theft useful in the first place.
When token compromise is part of a broader identity pattern, NHIMG’s Secret Sprawl Challenge and guide to NHI rotation challenges are useful reference points for the operational side of rotation, exposure cleanup, and dependency mapping.
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Token theft is secret leakage that enables unauthorized reuse. |
| NHI-01 — Improper Offboarding | Stolen tokens can remain valid after expected access should end. | |
| NHI-07 — Long-Lived Secrets | The incident response hinges on reducing replay time and secret lifetime. | |
| Recommendation — Revoke exposed tokens immediately and rotate any dependent secrets. Invalidate the full token family and remove residual access paths. Shorten token lifetime and replace long-lived credentials with bounded ones. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Immediate response requires revocation and rotation of compromised authenticators. |
| AC-2 — Account Management | Reviewing privilege changes and preserving account integrity is central after token theft. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-theft investigation depends on reviewing actions taken during token validity. | |
| Recommendation — Revoke the compromised authenticator and rotate related credentials. Review and remove unauthorized account changes and entitlements. Review logs for actions performed while the token was valid. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token theft exploits weaknesses in token-based authentication and replay. |
| Recommendation — Harden token authentication and prevent replay of stolen tokens. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | The scenario is a stolen token used to access services or data. |
| Recommendation — Map token theft paths and hunt for follow-on access using the stolen token. | ||
Practitioner Guidance
What to prioritise: Revoke the token family first, then hunt for persistence mechanisms that outlast revocation, especially mailbox rules, app consents, and privilege changes. If the token had administrative reach, treat the incident as an access-control event, not just a session incident.
What to verify: Confirm whether refresh tokens, derived sessions, or delegated grants remain active anywhere else in the stack. A clean token purge is incomplete if the attacker can still authenticate through a parallel path.
Common mistake: Teams often close the incident once the stolen token stops working. The more important question is whether the attacker used the valid window to alter configuration, create durable access, or exfiltrate data that cannot be recovered by revocation alone.
Practitioner takeaway: After token theft, the right objective is to collapse both current access and future reuse, then prove that no durable privilege or configuration change survived the compromise.
Related resources from NHI Mgmt Group
- What should teams do immediately after a package-based secret theft incident?
- What should organisations do immediately after a supply chain secret theft event?
- What should teams do immediately after an OAuth token incident in a SaaS environment?
- Should organisations revoke refresh tokens immediately after a suspected consent phishing incident?