Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
Expanded Definition
Token replay occurs when an attacker reuses a valid access token, refresh token, or bearer token outside the intended client context. The token may still pass cryptographic validation, so the real signal is not signature failure but abnormal session behaviour, such as a new device, a different network, or overlapping use from two locations.
In NHI operations, token replay is often discussed alongside session hijacking, but the distinction matters. Hijacking usually implies taking over an active session, while replay focuses on reusing a token artifact that remains trusted by the target system. Definitions vary across vendors, especially when refresh token rotation, proof-of-possession, and device binding are in play, so no single standard governs every implementation. The practical control goal is to make the token useless outside its original context, as reflected in the NIST Cybersecurity Framework 2.0 emphasis on authentication, monitoring, and response.
For NHI teams, the issue is not only whether a token can be stolen, but whether that token can be replayed before detection or revocation. The most common misapplication is treating any valid token as safe, which occurs when context binding, revocation logic, and anomaly detection are not enforced together.
Examples and Use Cases
Implementing replay resistance rigorously often introduces friction for legitimate automation, requiring organisations to weigh stronger session assurance against simpler service-to-service integration.
- A compromised OAuth access token is copied from a browser cache and reused from another host to call the same API, bypassing password checks and MFA because the token is still valid.
- A stolen refresh token is replayed to mint new access tokens after the original user session has ended, extending attacker access unless rotation and revocation are enforced, as seen in incidents like the Salesloft OAuth token breach.
- An AI agent token is reused by a different workload identity after secrets sprawl in chat or ticketing systems; the Guide to the Secret Sprawl Challenge shows how these exposures become operational debt.
- A mobile app token is extracted from a rooted device and replayed from a simulator, which is why context checks and device binding matter in guidance such as the IOS app secrets leakage report.
- A machine-to-machine token is reused across multiple pipelines or runners, a pattern that aligns with the identity overuse and duplication problems documented by The State of Secrets Sprawl 2026.
In standards terms, replay resistance is commonly paired with token binding, short lifetimes, and sender-constrained credentials under the broader direction of NIST Cybersecurity Framework 2.0, even when the exact mechanism differs by platform.
Why It Matters in NHI Security
Token replay is one of the clearest ways a valid NHI can be turned into a false sense of safety. If a token is leaked in a ticket, chat thread, log file, build artifact, or endpoint cache, the attacker does not need to break cryptography. They only need to arrive before expiration or before revocation takes effect. That is why replay risk sits at the intersection of secrets management, lifecycle control, and monitoring.
The scale is not theoretical. GitGuardian reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means exposed tokens often remain replayable long after the original incident. Entro Security also reports that 44% of NHI tokens are exposed in the wild, frequently across Teams, Jira, Confluence, and code commits. Those conditions explain why replay is common in real environments, especially where service accounts, automation, and agents share credentials.
Replay prevention is therefore not just an authentication feature. It is a governance requirement tied to revocation speed, provenance, and least privilege, consistent with the direction of the NIST Cybersecurity Framework 2.0 and the incident patterns discussed in the Guide to the Secret Sprawl Challenge. Organisations typically encounter token replay only after suspicious API activity or data access is traced back to a leaked token, at which point the condition becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret handling that enables token theft and replay. |
| NIST CSF 2.0 | PR.AC-7 | Focuses on authenticated access and context-aware validation of sessions. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust requires strong session and token protection against reuse. |
Enforce context checks and session controls so replayed tokens are not accepted blindly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
