OTP-based MFA can still be relayed because the code is reusable for the brief window it is valid, so a proxy attacker can pass it through to the legitimate service. Phishing resistant authentication binds the proof to the real origin and the device or key, which prevents simple replay through a fake login page.
Why Phishing-Resistant Authentication Holds Up Better in an AitM Flow
In an adversary-in-the-middle attack, the difference is not just “stronger MFA versus weaker MFA.” The real dividing line is whether the verifier can bind the login proof to the legitimate origin and the authenticating device or key. That binding breaks the attacker’s ability to forward a live login event through a fake site, which is why phishing-resistant methods change the attack economics.
OTP-based MFA is still useful, but it assumes the code itself is enough proof. In a relay attack, the attacker can capture the OTP and present it immediately to the real service before it expires. Phishing-resistant methods remove that simple replay path by tying the ceremony to the genuine site and a bound authenticator.
That distinction is why passkeys and FIDO-style sign-ins are treated differently from app-based or SMS codes in security guidance. NIST SP 800-63 Digital Identity Guidelines distinguishes phishing-resistant authentication from reusable one-time codes because origin binding and verifier binding matter in relay scenarios.
Where OTP-Based MFA Still Fits, and Where It Fails
OTP-based MFA is still better than password-only authentication, but it does not stop an attacker who can proxy the session in real time. The attacker’s goal is to become a pass-through, not to crack the OTP itself. That means the compromise can succeed even when the user “does everything right” from their own device.
In practice, OTPs fail most obviously when the phishing page is live, the victim is in a rush, and the adversary can submit the code immediately to the legitimate login. This is why OTPs remain vulnerable to modern phishing kits, help-desk social engineering, and some token-harvesting workflows. The control protects against guesswork and reused passwords, but not against live relaying.
For a practical comparison of migration choices, NHIMG’s MFA Guide is useful when you are deciding which factors make a method resilient against relay, fatigue, and token theft.
What Actually Breaks the Relay Attack
Phishing-resistant authentication works because the proof is cryptographically tied to the real origin and to the authenticator that the user controls. A fake page cannot simply reuse that proof against the legitimate service. The attacker may still trick the user into starting the flow, but the login proof cannot be cleanly replayed through the proxy in the same way an OTP can.
That is the key operational difference: OTP proves possession of a short-lived secret, while phishing-resistant methods prove the login ceremony against the right destination. The service can distinguish a real, bound authentication event from a relayed one, which closes the simplest adversary-in-the-middle path.
For teams rolling out this shift, NHIMG’s Passwordless and Passkeys Guide explains why WebAuthn and FIDO2-style authenticators are built to resist relay rather than merely shorten the lifetime of the secret.
Risk and Threat Considerations
The main risk is that organisations can treat any second factor as “phishing resistant” when it is only OTP-based. That creates a false sense of protection, especially for privileged users, remote access portals, and identity-provider sign-ins that are attractive to adversaries running live phishing infrastructure.
Failure mechanism: The attacker relays the user’s OTP through a fake page to the legitimate service while the code is still valid, then uses the authenticated session to access the target account or downstream applications.
Impact: The result can be account takeover even though MFA was enabled, which means the control failed at the exact point the attacker needed it to hold. If that account has elevated privileges, the compromise can quickly expand into session theft, data access, or lateral movement.
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, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 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 levels for this exact comparison. |
| Recommendation — Use phishing-resistant authenticators for sessions that must resist adversary-in-the-middle relay. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OTP relay risk depends on how authenticators are issued, stored, rotated, and accepted. |
| IA-2 — Identification and Authentication (Organizational Users) | The question is about user authentication strength and MFA resistance to takeover. | |
| Recommendation — Limit acceptance of reusable OTP authenticators for high-risk access paths. Require stronger authentication for organizational users accessing sensitive systems. | ||
| OWASP ASVS | V6 — Authentication | Authentication verification must distinguish reusable OTPs from phishing-resistant methods. |
| V7 — Session Management | AitM attacks often succeed by turning a login into a valid session after relay. | |
| Recommendation — Test that authentication flows resist phishing and replay, not just password reuse. Validate that sessions are bound, protected, and not easily reused after login. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Stronger access control is needed where OTP-based MFA can still be relayed. |
| Recommendation — Prefer phishing-resistant access controls for privileged and remote access paths. | ||
Practitioner Guidance
What to prioritise: Treat any sign-in flow that can be completed through a relay as insufficient for high-value accounts. Prioritise phishing-resistant methods for administrators, remote access, and identity-provider access before you focus on broad user convenience features.
What to verify: Confirm that the method actually binds the authentication ceremony to the origin and authenticator, not just to a one-time code. If your “MFA” still works when a proxy site forwards the login in real time, it is not the protection you think it is.
Practitioner takeaway: The security difference is not the number of factors, it is whether the factor can be replayed through an attacker-controlled page. If the proof can be relayed, the attack remains viable.
Related resources from NHI Mgmt Group
- Adversary-in-the-Middle (AiTM)
- Why do OTP based MFA flows still fail against modern phishing and adversary in the middle attacks?
- What is the difference between push-based MFA and phishing-resistant authentication?
- What is the difference between phishing-resistant MFA and traditional password-based authentication in government identity programs?
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 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org