Reuse of a captured token by an attacker to make authorised-looking API calls. The token may still be structurally valid, which is why replay prevention depends on path integrity, short lifetimes, and context-aware enforcement rather than token format alone.
Expanded Definition
bearer token replay refers to using a stolen or intercepted bearer token to impersonate a legitimate caller without re-authenticating. In practice, the token’s format can remain valid while the original security context has been lost, which is why replay resistance depends on transport integrity, short lifetimes, audience restriction, and proof-of-possession style controls rather than token appearance alone. In NHI and API security, this term sits between authentication and authorization: the token may prove that a workload or agent was once trusted, but replay shows that trust can be copied if the token is portable. Guidance varies across vendors on how much context must be bound to the token, so defenders should treat replay as an operational control problem, not a pure cryptography problem. Standards such as the NIST Cybersecurity Framework 2.0 frame the need for resilient access control, but they do not prescribe one universal replay-proof token design. The most common misapplication is assuming short-lived tokens are replay-safe, which occurs when the token is still usable within its lifetime after capture.
Examples and Use Cases
Implementing replay resistance rigorously often introduces integration friction, requiring organisations to weigh stronger request binding against simpler service interoperability.
- An agent obtains a bearer token from a workflow runtime, and an attacker reuses it from another host to call the same API until the token expires.
- A token captured from a reverse proxy log is replayed against a downstream service because the service accepts the token without validating client context or sender binding.
- A stolen OAuth access token from a compromised SaaS integration is reused to access customer records, similar to patterns discussed in the Salesloft OAuth token breach.
- A CI/CD runner leaks an API token into build logs, and the token is replayed from an external IP before rotation completes, echoing the exposure patterns in the JetBrains GitHub plugin token exposure.
- A service account token copied into a ticketing system is later used from a different network path, which is why the Guide to the Secret Sprawl Challenge is useful for understanding how secrets spread into places where replay becomes realistic.
In adjacent standards work, sender-constrained approaches and token binding concepts are often discussed, but adoption is uneven and implementation details vary by platform. For identity governance teams, replay testing should be part of the same validation process used for API authentication, workload identity, and secret handling.
Why It Matters in NHI Security
Bearer token replay turns a single exposure into a repeatable compromise, which is why it is especially dangerous for NHIs, agents, and service accounts that operate without human intervention. Once an attacker can reuse a token, the event is no longer just a credential leak; it becomes an access-path failure that can bypass RBAC, masking, and many passive monitoring controls. NHIMG research shows that valid secrets leaked in 2022 are still valid and exploitable today, underscoring that detection alone does not end the risk. The same research also found that 44% of NHI tokens are exposed in the wild, often through collaboration tools and code commits, which makes replay prevention a core governance concern rather than a niche hardening task. For operational teams, the control question is not whether a token was “real,” but whether it can be replayed from somewhere else after capture. Organisations typically encounter this consequence only after an incident review shows the same token being used from multiple locations, at which point bearer token replay 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 | Replay risk grows when NHI secrets and tokens are exposed or reused across paths. |
| NIST CSF 2.0 | PR.AC | Access control must prevent reused credentials from granting unauthorised sessions. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires each request to be re-evaluated, limiting replay value. |
Apply least privilege, session validation, and continuous access monitoring to token use.
