Request replay is the repeated use of a previously captured request to obtain an unauthorized result. In identity and access systems, attackers replay valid tokens, signed messages, or API calls to impersonate a user, service, or agent. Strong nonce, timestamp, and session validation reduce replay risk.
How Request Replay Works
Request replay is not a new authentication method, it is an abuse of a legitimate one. An attacker captures a valid request and sends it again, hoping the system will treat it as fresh and produce the same authorised action or a new unauthorised result.
The technique matters because many security systems trust the contents of a request more than the context around it. If the request contains a bearer token, signed message, session cookie, API call, or agent action and the server does not bind it tightly to a single use, replay can turn a one-time grant into repeated access.
Why Replay Becomes Dangerous
Replay is especially dangerous when the captured request confers identity, privilege, or business action. A replayed login assertion can impersonate a user; a replayed service call can impersonate an application; a replayed tool invocation can impersonate an agent action. The risk is not just duplicate execution, but unauthorised reuse of trust.
Strong anti-replay design usually combines nonces, timestamps, expiration, session state, and binding to the intended recipient or channel. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is a useful reference because it shows how sender-constrained tokens reduce the value of stolen requests by making simple replay fail.
Where Organisations Check Exposure
Exposure review starts with understanding which systems accept reusable requests and which ones rely on bearer-style trust. High-risk areas include APIs, single sign-on flows, automation channels, session-based portals, webhook receivers, and any service path that accepts signed requests without freshness checks.
Teams usually verify whether requests can be replayed across different sessions, different users, different devices, or long enough time windows to matter. Controls for this problem intersect with broader identity and access hygiene, including request validation, session handling, authentication strength, and logging. NIST SP 800-63 Digital Identity Guidelines is relevant here because it frames authenticators, phishing-resistant mechanisms, and binding properties that influence replay resistance.
Remediation, Detection, and Post-Compromise Review
If replay protection is weak, the first fix is to make each request verifiably fresh and context-bound. That often means one-time nonces, short-lived tokens, strict timestamp checks, server-side replay caches, and cryptographic binding that prevents a captured request from being accepted outside its original context.
Detection should look for repeated request IDs, duplicate signatures, unusual repetition of the same action, impossible travel between request origins, or identical API calls appearing outside their expected time window. If exploitation is suspected, review whether credentials, sessions, signing keys, or API tokens used by the replayed request should be rotated or revoked, because replay often exposes the underlying secret material as well as the action itself.
For API-heavy environments, OWASP API Security Top 10 helps frame replay-adjacent failures as part of broader API trust, authentication, and authorisation weaknesses.
Risk and Threat Considerations
Request replay creates a straightforward abuse path when an attacker can observe or steal a valid request and the target system does not require freshness or proof of possession. The impact ranges from duplicate transactions to full impersonation of a user, service, or agent, especially where the request itself carries privilege or authority.
Failure mechanism: A system accepts a previously valid request because it cannot distinguish an original submission from a captured copy, or because the request is not bound to one session, one channel, or one execution.
Impact: Attackers can repeat privileged actions, bypass intended one-time controls, and extend a short-lived capture into durable unauthorised access or unauthorised business activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authentication strength and binding properties that affect replay resistance. |
| Recommendation — Use phishing-resistant authenticators and binding properties that make captured requests unusable when replayed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Replay is a common consequence of weak API authentication and token handling. |
| Recommendation — Harden API authentication so captured requests cannot be reused to impersonate a caller. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Replay risk rises when tokens and authenticators are not managed with short lifetimes and rotation. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Service and API requests often rely on non-organisational identities exposed to replay. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Duplicate request patterns and repeated actions are best confirmed through log review and analysis. | |
| Recommendation — Manage authenticators with expiry, rotation, and revocation rules that limit replay value. Authenticate external services with controls that include freshness and replay safeguards. Review audit records for repeated request identifiers, duplicate actions, and abnormal reuse patterns. | ||
Practitioner Guidance
What to watch for: Treat replay resistance as a design property, not a patch after the fact. Any flow that relies on bearer tokens, signed assertions, or reusable API requests should be reviewed for freshness, expiry, and context binding, especially where the request can trigger money movement, identity changes, or automation.
Governance implication: Ownership should sit with the team that designs or consumes the request path, because replay risk often crosses application, identity, and API boundaries. Where one team controls the token and another controls the endpoint, both sides need a clear rule for nonce handling, expiry, logging, and revocation response.
Related resources from NHI Mgmt Group
- What breaks when AI traces are not captured with enough context to replay a request?
- What are the signs that request replay protection is not catching abuse?
- What happens when security teams can replay API calls with modified request parameters during testing?
- What is the difference between network trust and request-level identity trust?
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 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org