What breaks when MFA still depends on codes that users can type into a fake login page?

Where the login flow actually fails

The break is not at “whether MFA exists,” but at whether the second factor is bound to the real session and origin. If a code can be entered into a lookalike page and then forwarded to the genuine login, the attacker is no longer guessing the factor, they are relaying it. That turns MFA into a transferable secret check instead of a phishing-resistant control.

This failure mode is why codes are weaker than authenticators that verify the browser or device context, or that are not reusable by an intermediary. The user still sees a normal login sequence, but the attacker can harvest the code, submit it immediately, and obtain the authenticated session before the code expires.

In other words, the question is not “did the user complete MFA,” it is “did the factor resist interception and replay.” When the answer is no, the control has not stopped phishing, it has only added one more step for the attacker to proxy.

Why typed codes are still phishable

Typed one-time codes are vulnerable because they are human-readable, transferable, and time-bounded rather than origin-bound. A fake login page can collect username, password, and code in one interaction, then use them against the real service in the same window. That is why the attack is often called adversary-in-the-middle, credential relay, or MFA bypass by relay.

Phishing-resistant controls change the failure condition. Passkeys, hardware-backed authenticators, and similar mechanisms make the signed assertion depend on the legitimate site or bound device, which removes the attacker’s ability to reuse what the user typed. In practice, that is the difference between a factor that proves presence and a factor that can be copied.

For teams evaluating sign-in strength, the key question is whether the second factor can be replayed outside the intended origin. If it can, the attacker only needs a convincing fake page and a fast enough relay to win the race.

What this means for access design and rollback decisions

Once a code is intercepted, the downstream problem is session establishment, not just authentication. The attacker can often pivot straight into mailbox access, SSO sessions, admin consoles, or cloud applications if the sign-in flow does not add a stronger binding step. That makes session protection, step-up controls, and recovery paths part of the same design problem.

Organizations should treat code-based MFA as a transitional control, not the end state for high-value accounts. The more sensitive the role, the more the sign-in method should resist relay, token theft, and help-desk-assisted bypass. Where that is not yet possible, limit exposure with shorter session lifetimes, tighter recovery controls, and explicit monitoring for anomalous sign-in paths.

At scale, the weak point is often consistency rather than technology. A program may have strong MFA for some users, but legacy protocols, fallback methods, or exception accounts can preserve a phishable path that attackers will target first.

Risk and Threat Considerations

Code-based MFA creates a false sense of closure because it appears to satisfy the control requirement while still leaving a relay path open. Attackers exploit that gap by capturing the code in a fake login, replaying it quickly, and converting a user interaction into live account access.

Failure mechanism: The factor is transferable, so the attacker can terminate the authentication at the real service while the victim still believes they are completing a normal login.

Impact: The result is account takeover, session hijacking, and often immediate access to email, SaaS, or admin functions that the attacker can use for lateral movement or fraud.

Practitioner Guidance

What to verify: Check whether your MFA method is phishing-resistant for the accounts that matter most, especially if the current flow accepts typed codes, SMS, or app codes that can be relayed through a proxy page.

Decision rule: If the factor can be entered into a counterfeit page and successfully reused against the real service, treat it as a phishable control and prioritize a move to passkeys or other origin-bound authentication for privileged and high-risk users.

Common mistake: Teams often declare success after “MFA coverage” reaches 100 percent, but coverage is not the same as resistance to interception, replay, or adversary-in-the-middle phishing.

Practitioner takeaway: The security goal is not merely to make users present a second factor, it is to make that factor unusable by anyone except the legitimate relying party and device context.

Related resources from NHI Mgmt Group

• What breaks when users are redirected to a spoofed login page?
• What breaks when MFA still depends on human approval and one-time prompts?
• What breaks when MFA is present but the login can still be relayed in real time?
• What breaks when users complete MFA on a phishing site that proxies Okta login traffic?