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

Why OTP MFA breaks under phishing and real-time relay

OTP-based MFA is only as strong as the assumption that the person entering the code is the right person. Modern phishing kits and adversary in the middle setups break that assumption by capturing the one-time code and forwarding it to the real login flow before the code expires. The result is a control that still looks like MFA, but no longer meaningfully proves user presence.

What attackers actually exploit in the OTP flow

The weakness is not the code format itself, but the fact that many OTP deployments are still transaction-blind and origin-blind. A victim can be tricked into entering a code into a fake sign-in page, or into a relay page that proxies the session to the legitimate site in real time. Because the code is valid only for a short window, attackers do not need to crack it, only move fast enough to reuse it before expiry.

This is why OTP is often defeated by phishing rather than by brute force. The attacker is not trying to guess the code, they are trying to sit between the user and the service long enough to capture and forward the result. If the workflow does not bind the code to the originating device, domain, or transaction, the OTP can still complete a login for the attacker.

Why OTP still appears effective in some environments

OTP remains better than password-only authentication, so it is easy to treat it as “good enough” when the organisation has not yet moved to phishing-resistant methods. It can still stop many low-effort attacks, especially where the adversary is not relaying a live session. But once an attacker controls the interaction path, the assurance provided by the second factor drops sharply.

That gap matters most when OTP is the final gate to email, VPN, SSO, admin portals, or recovery flows. In those cases, a successfully relayed code can give the attacker the same session access the legitimate user would have received, including downstream access to password resets, tokens, or privileged applications. For identity-layer risk and hardening patterns, see the MFA Guide and the Identity Provider and SSO Security Guide.

Risk and Threat Considerations

OTP failure is a trust failure, not just an implementation weakness. When the code is accepted without binding it to the user’s device, browser, or authentication context, a phishing relay can turn “something the user has” into “something the attacker can temporarily borrow.”

Failure mechanism: The attacker captures the OTP in a fake or proxied sign-in flow, forwards it to the live service, and completes authentication before the code expires. If the service also issues a reusable session cookie or token, the attacker can persist beyond the OTP itself.

Impact: The organisation may believe MFA is in place while still being vulnerable to account takeover, email compromise, SSO abuse, and lateral movement through trusted sessions. In practical terms, OTP can reduce unsophisticated risk while leaving targeted phishing and real-time relay largely intact.

Practitioner Guidance

What to prioritise: Move the highest-risk populations, especially admins, finance users, help desk staff, and high-value SSO users, off OTP and onto phishing-resistant authentication first. The control gap is most damaging where a single session unlocks many downstream systems.

What to verify: Check whether your MFA method is origin-bound or merely code-based, and whether the login flow accepts codes after being relayed through a different domain or browser context. Also verify whether session tokens survive long enough to matter after OTP completion, because the real prize is often the session, not the code.

Decision rule: If an authentication method can be completed on a lookalike site and reused immediately against the real service, treat it as vulnerable to phishing relay even if it still meets policy language for MFA. The policy label is less important than whether the method resists real-time interception.

Practitioner takeaway: OTP is a stepping stone, not a phishing-resistant endpoint. The more valuable the account, the more important it is to replace code-entry assumptions with authentication that is bound to the real origin and harder to relay.

Related resources from NHI Mgmt Group

• Why do passwords and OTP-based MFA still fail against modern identity attacks in regulated environments?
• Why do vaults and MFA still fail against adversary-in-the-middle phishing?
• 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?