An authentication method or secret that can be captured and used again by an attacker. SMS codes, OTPs, and some push approvals can fall into this category because they do not always bind the request to a trusted device or a non-transferable proof of possession.
Expanded Definition
A replayable factor is any authentication factor that can be captured and reused by an attacker, often without needing to re-create the original user action or device state. In practice, this matters when the proof of possession is transferable, short-lived only by convention, or not bound to the specific request being approved.
Definitions vary across vendors, especially when products describe SMS, OTP, or push approval as “multi-factor” without clarifying whether the factor is resistant to replay. For NHI Management Group, the operational question is whether the factor survives interception, relaying, or delayed reuse. This is why replay resistance is a core design concern in frameworks such as the NIST Cybersecurity Framework 2.0 when identity assurance and access protection are implemented together. A replayable factor is especially problematic in agentic and machine-to-machine environments because the attacker does not need to break the system, only to reuse what the system already accepted once.
The most common misapplication is treating any one-time code or push approval as non-replayable, which occurs when the factor is not cryptographically bound to the session, device, or transaction.
Examples and Use Cases
Implementing replay-resistant authentication rigorously often introduces user friction and integration complexity, requiring organisations to weigh stronger assurance against support burden and deployment cost.
- SMS one-time codes are intercepted through SIM swap, phishing proxies, or message forwarding, then replayed before the validity window closes.
- OTP apps that generate codes without request binding can be relayed in real time through adversary-in-the-middle phishing.
- Push approvals may be replayable when users approve prompts without transaction details, device binding, or number matching.
- API-based service authentication can become replayable when bearer tokens, session cookies, or cached assertions are copied from logs or memory.
- Machine identities that rely on reusable secrets rather than scoped, time-bound attestations create the same replay condition in automated workflows, as covered in the Ultimate Guide to NHIs and in identity guidance from NIST Cybersecurity Framework 2.0.
In NHI programs, replayable factors are often exposed during secret reuse, weak approval flows, or poorly designed federation between services. The distinction matters because a captured credential does not need to be guessed if it can simply be replayed.
Why It Matters in NHI Security
Replayable factors are a direct pathway from initial interception to repeated unauthorized access, especially where service accounts, API keys, and automation tokens are involved. NHI Mgmt Group reports that Ultimate Guide to NHIs shows 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. That pattern aligns with replay risk: once a secret or approval artifact is captured, the attacker may reuse it until it is rotated, revoked, or bound more tightly to context.
For NHI governance, the consequence is not just account takeover but persistence across pipelines, cloud services, and delegated automation. The same weakness that affects a human login can become more dangerous in machine identity systems because the blast radius is often larger and the detection window is longer. The NIST Cybersecurity Framework 2.0 helps organisations translate this into control objectives around access protection, anomaly detection, and response.
Organisations typically encounter replayable-factor risk only after a phished approval, reused token, or intercepted OTP is used successfully in production, at which point replay resistance 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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Replayable secrets and tokens are a direct secret-management risk in NHI systems. |
| NIST SP 800-63 | AAL2 | Assurance guidance distinguishes stronger authenticators from reusable or phishable factors. |
| NIST CSF 2.0 | PR.AC-7 | Authentication strength and access enforcement are central to replay resistance. |
Replace reusable credentials with bound, short-lived authentication artifacts and rotate anything exposed.
