The assumption that a second factor creates durable proof of identity breaks down when the attacker can capture and reuse the code during the same session. In practice, OTP-based MFA may still stop bulk fraud, but it does not stop a live relay attack that completes the login before the user notices anything unusual.
Why a live relay attack breaks the trust model behind OTP MFA
The failure is not that MFA becomes useless, but that the code no longer proves the user is present and separate from the attacker. A real-time relay lets the phisher act as the middleman, forward the one-time code immediately, and complete the login inside the same authentication window. That turns a second factor into a transient relay artifact instead of durable identity proof.
Once the attacker can reuse the code before it expires, the control still blocks many low-effort attempts such as password stuffing and bulk credential reuse. The weakness is specific to phishing kits that can proxy the live session, which is why OTP-based MFA is weaker against adversary-in-the-middle workflows than phishing-resistant methods such as passkeys or hardware-bound authenticators.
What changes in the authentication flow when the code is relayed
A normal OTP flow assumes three things: the user sees the prompt directly, the code is bound to that user session, and the attacker cannot insert themselves fast enough to reuse it. Real-time relay breaks all three assumptions at once. The victim still enters a valid code, the verifier still sees a valid code, and the attacker still gains access because the trust problem is about timing and channel integrity, not code correctness.
That is why the event should be treated as authentication compromise, not just phishing success. The attacker has not guessed the factor, they have intercepted it in motion. In Twilio 0ktapus breach 2022, SMS phishing and live OTP theft showed how one-time codes can be captured and used immediately, while the MFA Guide explains why relay, fatigue and token theft all exploit the same trust gap.
Which controls actually withstand relay attacks
Controls that bind the authenticator to the origin, device, or cryptographic challenge survive this attack much better than shared-secret or code-entry methods. Phishing-resistant MFA, passkeys, FIDO2 security keys, and well-implemented device-bound authenticators reduce the value of a proxied login because the attacker cannot simply forward a code from one browser to another and get the same assurance.
That is also why guidance from Passwordless and Passkeys Guide matters here: the point is not just stronger MFA, but an authentication ceremony that resists interception. For broader identity hardening, the Workforce Identity Security Guide ties phishing-resistant MFA to account recovery, session theft, and help-desk exposure, which are often the next steps after a relay succeeds.
Risk and Threat Considerations
Real-time relay creates a high-confidence initial access path because the attacker does not need to break the factor, only to reuse it fast enough to finish the login. The bigger risk is downstream session abuse: once authenticated, the attacker can operate as the user until the session is revoked, which makes the event much more serious than a failed phishing attempt.
Failure mechanism: The phishing panel captures the code or challenge in transit, forwards it immediately to the real service, and converts a short-lived authentication token into a live session before the user notices.
Impact: The organisation loses the assumption that OTP MFA is proof of interactive user presence, so account takeover, mailbox access, internal tool access, and later-stage fraud can follow even when the original password was not known.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while 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 | Phishing-resistant authenticators and AAL guidance directly address relayed MFA weaknesses. |
| Recommendation — Adopt phishing-resistant authenticators and raise assurance where OTP relay is a realistic threat. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns user authentication failure under live phishing relay. |
| IA-5 — Authenticator Management | OTP relay highlights weaknesses in authenticator handling and lifecycle controls. | |
| Recommendation — Require stronger user authentication methods that resist replay and interception. Manage authenticators so codes and secrets are not usable through live relay or reuse. | ||
| OWASP ASVS | V6 — Authentication | The issue is an authentication ceremony that can be proxied in real time. |
| V10 — OAuth and OIDC | Phishing-resistant sign-in and token handling are central to preventing relayed logins. | |
| Recommendation — Verify that authentication mechanisms resist interception and relay, not just code entry. Use stronger federation and token protections when sign-in flows can be proxied. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Live MFA relay leads directly to unauthorized access and session takeover. |
| Recommendation — Limit and revoke account access paths that remain usable after a relay-based compromise. | ||
| MITRE ATT&CK | T1586 — Compromise Accounts | Live relay is an account-compromise path that enables downstream adversary activity. |
| Recommendation — Map relay-enabled takeovers to account-compromise detections and response playbooks. | ||
Practitioner Guidance
What to verify: Check whether your MFA method is actually phishing-resistant or only OTP-based. If the control depends on a code the user can type into a browser, assume it can be relayed; if it uses origin binding, device binding, or cryptographic attestation, the risk profile changes materially.
Decision rule: If the attack path involves active phishing against employee or contractor accounts, prioritise migration to passkeys or security keys before you tune detection logic. Detection still matters, but it is compensating control, not the primary fix, once live relay is in play.
Practitioner takeaway: A relayed OTP proves only that a code was entered on time, not that the legitimate user authenticated in a trustworthy channel; design for phishing resistance, not just second-factor presence.
Related resources from NHI Mgmt Group
- How should online banking teams defend against man-in-the-middle phishing that intercepts MFA codes and session tokens in real time?
- How should organisations reduce MFA compromise from real-time phishing?
- How should security teams defend against live phishing panels that intercept MFA codes?
- What breaks when MFA does not evaluate user risk in real time?
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 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org