Reuse of an authentication factor or its output after the legitimate user has already satisfied the challenge. It is a common real-time phishing outcome and a reason that some MFA methods are weaker than phishing-resistant authentication methods.
Factor Replay in Authentication
Factor replay happens when an attacker captures an authentication factor, or the successful output of that factor, and reuses it after the legitimate user has already completed the challenge. The danger is not the factor itself, but the fact that the replay can ride on top of a real, successful login event.
It is closely associated with real-time phishing, where the attacker acts as a relay between the victim and the target service. The user may believe they are completing a normal login, while the attacker is quietly harvesting something that can be replayed immediately.
Why Factor Replay Weakens Some MFA Methods
Factor replay exposes the difference between possession-based authentication and phishing-resistant authentication. If the factor or its output can be forwarded, copied, or replayed without binding it to the originating session, device, or challenge, then the method may still authenticate the attacker after the victim authenticates the user.
That is why some MFA implementations are materially weaker than methods designed to resist relay and replay. NIST SP 800-63 Digital Identity Guidelines distinguishes stronger authenticators and phishing-resistant approaches from weaker factor combinations that can be intercepted in transit.
How Replay Works in Practice
Replay usually depends on timing and trust assumptions. A victim enters a one-time code, approves a push, or completes another second factor, and the attacker captures the resulting approval, assertion, or token before it expires or before the session context changes.
In a live phishing relay, the attacker may never need to know the underlying secret. They only need to forward the challenge and use the authenticated output quickly enough to establish their own session. Sender-constrained token designs such as RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) help reduce this class of abuse by binding a token to the client presenting it.
Security Implications and Defensive Meaning
Factor replay is important because it turns a user-presence event into attacker access. Once the replay succeeds, the downstream impact can look like a legitimate login, which makes the abuse harder to distinguish from normal activity.
Controls that improve resistance include phishing-resistant authenticators, session binding, device binding, short-lived assertions, and careful token handling. Broader control catalogs also reflect the same principle of protecting authentication workflows and limiting replay exposure; NIST SP 800-53 Rev 5 Security and Privacy Controls includes identification, authentication, and access control safeguards that support those objectives.
Risk and Threat Considerations
Factor replay is a practical attacker path because it lets a stolen or intercepted authentication outcome be reused before it loses value. The risk is highest when the authentication method is not tightly bound to the session, device, or origin of the challenge, especially in real-time phishing scenarios.
Failure mechanism: The attacker relays or captures the factor output and reuses it fast enough to satisfy the service’s authentication check, even though the legitimate user was the one who completed the challenge.
Impact: Unauthorized access can be obtained without learning the user’s password or secret, which can defeat weaker MFA deployments and create account takeover risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 phishing-resistant authentication and authenticator assurance concepts relevant to replayable factors. |
| Recommendation — Adopt phishing-resistant authenticators and verify the full login flow resists relay and replay. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers enterprise authentication controls that must withstand replay and impersonation. |
| IA-5 — Authenticator Management | Addresses authenticator handling, lifecycle, and protections that affect replay exposure. | |
| AC-2 — Account Management | Account governance matters because replay often leads to account takeover and unauthorized access. | |
| Recommendation — Strengthen organizational authentication to block replayable login outcomes. Manage authenticators to limit capture, reuse, and replay risk. Monitor and constrain accounts so replay-induced access is detected and contained. | ||
Practitioner Guidance
Why practitioners should care: Treat factor replay as a signal that the authentication method may be proving only that a challenge was satisfied, not that the right party is still present at the point of use. That distinction matters whenever the attacker can insert themselves between the user and the relying service.
Common misunderstanding: A second factor does not automatically mean phishing resistance. If the factor can be forwarded, proxied, or replayed, the login may still be vulnerable even though MFA is technically enabled.
Practitioner takeaway: Prefer authentication methods and token designs that are explicitly resistant to relay and replay, and validate that the protection applies to the full login flow rather than only to the factor in isolation.
Related resources from NHI Mgmt Group
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 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org