Why do OTP based MFA flows still fail against modern phishing and adversary in the middle attacks?

Why OTP MFA Still Breaks Under Real-Time Phishing

One-time passwords reduce replay risk, but they do not prove that the person entering the code is the right user. Modern phishing kits and adversary-in-the-middle proxies can capture the code, forward it instantly, and complete the login before the OTP expires. That makes OTP a weak assurance layer when the attacker can sit between the user and the real service.

For security teams, the important shift is to stop treating OTP as resistance to phishing and start treating it as a compensating control with a narrow trust model. It works best against stolen password reuse and some low-effort account abuse, not against active interception of the authentication ceremony. The weakness is not the code itself, but the fact that the service still accepts a valid code without knowing whether it reached the user through a genuine channel or a relayed one. A practical example of how quickly credentials get abused is the average 17-minute window observed when AWS credentials are exposed publicly, which shows how little time defenders often have once a secret or code is intercepted. In practice, many teams discover this limitation only after a live relay has already completed a session, not during design review.

Relevant context: The State of Secrets in AppSec

How the Attack Succeeds in Practice

OTP failure in phishing is usually a timing and trust problem, not a cryptographic one. The attacker lures the user to a convincing login page, captures the primary credentials, and then immediately relays the OTP to the legitimate site. In adversary-in-the-middle attacks, the proxy can maintain two live sessions at once, preserving the user experience while the attacker harvests the authenticated session behind the scenes.

This works because many OTP flows do not bind the code to the device, the browser session, the origin, or the transaction being approved. If the code is valid within the time window, the verifier often accepts it as sufficient proof. That means the attacker does not need to defeat the one-time property; they only need to use the code before it expires. Where session tokens are issued after MFA, the attacker may not need to see the OTP again once the session is established.

• Phishing proxies can relay credentials and OTPs in near real time.
• SMS, TOTP apps, and email OTPs all remain vulnerable if the code is reusable within the authentication window.
• Session hijack becomes the real prize once the MFA step succeeds for the attacker.
• App and browser bindings matter because they reduce the value of a relayed code.

Current guidance increasingly favours phishing-resistant methods such as passkeys or cryptographic authenticator binding, because they validate the authenticator and the origin rather than only the code. For background on identity assurance models, see NIST SP 800-63 Digital Identity Guidelines. For an NHI-specific view of how secrets and credentials are abused at scale, The 52 NHI Breaches Report is useful because it shows how quickly trusted credentials become an attacker foothold.

These controls tend to break down when the login journey is fully proxied, because the attacker can preserve timing, state, and user interaction closely enough for the verifier to accept the relayed authentication.

Common Variations and Edge Cases

Tighter authentication usually improves resistance, but it also increases friction, device dependence, and rollout complexity, so organisations have to balance usability against phishing resistance.

Not all OTP implementations fail in exactly the same way. Push-based approvals can be vulnerable to MFA fatigue and session binding weaknesses, while SMS OTP adds telecom interception and number-reuse risk. TOTP is often better than SMS, but it still shares the core problem that a live proxy can forward the code in time. Email OTP inherits mailbox compromise and forwarding-rule abuse, which can make the second factor little more than a second password.

There is no universal standard for user intent validation in OTP flows yet. Some environments are adding transaction binding, device attestation, or conditional access rules that step up verification when the login context changes. Others are moving straight to phishing-resistant authenticators because the operational overhead of hardening OTP often exceeds the benefit. The key trade-off is that stronger controls reduce successful relay attacks, but they also raise deployment and recovery requirements for users with lost devices, shared endpoints, or limited authenticator support.

Where this matters most is in high-value accounts, administrative access, and any workflow that grants durable session tokens after login. Those are the places where a relayed OTP can turn a temporary phishing event into a persistent compromise.

Risk and Threat Considerations

The material risk is not just failed authentication but compromised session establishment. Once an attacker can relay OTPs in real time, they can cross the trust boundary that the MFA step was supposed to enforce and obtain authenticated access with the victim’s privileges.

Failure mechanism: The attacker uses a phishing page or adversary-in-the-middle proxy to capture the password and OTP, then forwards the OTP to the legitimate service before expiry. Because the verifier checks code validity rather than authenticating channel integrity or user presence, the attack succeeds without breaking the OTP algorithm.

Impact: The attacker can establish a valid session, access protected applications, and in some environments pivot to sensitive data, administrative actions, or persistent account takeover through token reuse and consent abuse.

Practitioner Guidance

What to prioritise: Treat any OTP flow that protects privileged, financial, or high-impact access as a candidate for phishing-resistant replacement. If the account can mint durable sessions or approve sensitive actions, OTP should not be the final control.

What to verify: Confirm whether the second factor is bound to the originating device, browser, or transaction, and whether a relayed code can still produce a full session token. If the answer is yes, assume the control can be bypassed by a live proxy.

Decision rule: If a phishing kit can complete the login in real time, prioritise migration to passkeys or other origin-bound authenticators before investing further in OTP hardening. If OTP must remain, pair it with conditional access, step-up checks, and tight session limits.

Practitioner takeaway: OTP is still useful as a basic hurdle, but it is not a reliable defence against an attacker who can participate in the login live; the real objective is to remove the attacker’s ability to reuse the user’s authentication ceremony as if it were their own.

Related resources from NHI Mgmt Group

• Why do passwords and OTP-based MFA still fail against modern identity attacks in regulated environments?
• Why do phishing-resistant methods still fail against man-in-the-middle attacks?
• Why do OTP and push approvals fail against adversary-in-the-middle attacks?
• Why do legacy MFA methods fail against adversary-in-the-middle attacks?