Treat stolen tokens as active credentials, not artefacts. Revoke and reissue them, check for process-memory exposure, look for workflow reuse, and assume any long-lived token may already have been copied into automation or exfiltration infrastructure. If the token can still be replayed, the incident is not contained.
Why stolen tokens should be treated as live access, not evidence
A stolen token is usually still a valid bearer credential until it is explicitly revoked or expires. That means the immediate question is not whether the token file was found, but whether replay is still possible, where it can reach, and what other systems may trust it. Token and Session Security Guide
Because tokens often move through browsers, agents, pipelines, SaaS integrations, and cached process state, containment has to assume the token may have crossed its original boundary. If you only remove the visible copy, you may leave behind a still-authorised session, refresh path, or downstream exchange chain.
Security teams should also distinguish between short-lived and long-lived tokens. Short lifetimes reduce the replay window, but a long-lived token can remain dangerous even after the original incident looks closed, especially when it has been reused across workflows or mirrored into automation. RFC 9700: Best Current Practice for OAuth 2.0 Security
What to revoke, reissue, and verify after token theft
Start by revoking the token at the source system, then invalidate any dependent refresh tokens, app grants, sessions, or delegated credentials that can mint a fresh bearer token from the same trust path. Where the platform supports it, force a global sign-out or session termination so a stolen token cannot simply be replayed from a new location. OAuth Token Theft Incident Playbook
After revocation, reissue only the credentials that are actually needed for recovery, and do it from a clean administrative path. Reuse of the old secret material, or a partial reset that leaves the original grant intact, is a common reason incidents reappear after the first containment step.
Then verify whether the token was bound to a specific client, device, or channel. If it was not sender-constrained, assume replay from another host or region is possible until you have evidence that access paths have been cut off. For sender-constrained deployments, binding reduces but does not remove the need to revoke the original credential path. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Where the token was part of SaaS-to-SaaS or app-consent integration, review the connected application itself, not just the single token value. The issue may be persistent consent, excessive scopes, or a surviving refresh capability rather than one exposed access token. SaaS API Token Security Guide
How to look for reuse, secondary theft, and hidden exposure
Stolen tokens are often useful because they unlock more than one path. Attackers may reuse them in CI/CD workflows, clone repositories, access cloud consoles, or exchange them for other tokens and secrets, so the incident review has to trace where the token was valid, not only where it was found. GitHub OAuth token breach 2022
Check logs for successful use from unfamiliar IPs, unusual user agents, new automation jobs, or access at times that do not fit the normal workflow. Also inspect process memory, runtime state, and job metadata, because tokens can leak into command arguments, environment variables, caches, and crash artifacts long before they are copied out of the system.
Workflow reuse matters because the same token may have been embedded in multiple tools or scripts. If one integration was compromised, assume other jobs, forks, mirrors, or build steps may now be able to replay the same credential unless you have explicitly broken the dependency chain.
For stronger evidence of blast radius, compare the token's observed use with the expected trust boundary. If the original credential was accepted by a third-party app or automation platform, you need to assess that platform's grants and downstream actions as part of the incident, not as a separate cleanup task. Shared Signals Framework Guide
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 addresses 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 | Stolen tokens are leaked NHI secrets that still enable access. |
| NHI-07 — Long-Lived Secrets | Long-lived tokens extend replay risk after an incident. | |
| NHI-01 — Improper Offboarding | Incident response must fully remove surviving access paths and grants. | |
| Recommendation — Revoke leaked tokens and rotate any dependent secret material immediately. Replace long-lived tokens with shorter-lived, revocable credentials. Invalidate old grants, sessions, and app connections during offboarding. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token theft response depends on revocation, replacement, and lifecycle control. |
| IA-9 — Service Identification and Authentication | Many stolen tokens authenticate services, apps, and automation, not just users. | |
| AC-2 — Account Management | Surviving grants and sessions are an account-management issue after token theft. | |
| Recommendation — Revoke compromised authenticators and reissue them through controlled lifecycle steps. Treat service and workload tokens as authenticators that require immediate invalidation. Review and remove any account, app, or session grants that outlive the incident. | ||
Practitioner Guidance
What to prioritise: Revoke the credential path first, then determine whether any surviving refresh, session, or delegated grant can still mint access. If you delay that sequence, every later investigation step risks being performed while the attacker still has a working token.
What to verify: Confirm that the old token cannot be replayed, that dependent sessions are invalidated, and that the reissued credential is scoped no wider than the original business need. If the same grant still authorises production systems, treat the incident as active compromise rather than closed theft.
Common mistake: Teams often delete the visible secret but leave the platform grant, cached session, or automation copy in place. That leaves a clean-looking environment with a still-valid access path.
Practitioner takeaway: The containment decision is not whether the token was stolen, but whether any trust path can still accept it; if replay remains possible anywhere, the incident is not contained.
Related resources from NHI Mgmt Group
- How do attackers operationalise stolen OAuth tokens at scale?
- How should security teams handle stolen OAuth tokens when MFA is already in place?
- Who is accountable when stolen tokens are used after a device code phishing incident?
- How should security teams handle support cases and troubleshooting artifacts so session tokens and cookies are not exposed after an account compromise?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org