The control breaks at the point where the factor can be intercepted, copied, and replayed by an attacker. That means the login flow still trusts a transferable secret, so the user can be phished even though MFA is technically present. In practice, the issue is not missing MFA, but MFA that remains usable by the attacker.
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.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Typed code MFA and phishing-resistant authentication are central to this sign-in failure mode. |
| Recommendation — Prefer phishing-resistant authenticators for high-risk sign-in flows and reject replayable code-based MFA where possible. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns user authentication strength and whether MFA actually verifies the user. |
| IA-5 — Authenticator Management | The issue is the lifecycle and usability of reusable codes as authenticators. | |
| Recommendation — Require stronger authentication for workforce access and remove fallback paths that permit replayable code entry. Manage authenticators so replayable secrets are replaced with stronger factors and rotated or retired safely. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Phishing-resistant login flows and bearer-token exposure are part of modern authentication assurance. |
| V6 — Authentication | The core problem is weak authentication that remains usable after phishing interception. | |
| Recommendation — Verify that authentication flows resist interception and token replay, not just successful login completion. Test authentication for resistance to phishing, relay, and replay before considering it acceptable. | ||
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | The attack path relies on the attacker obtaining and replaying the MFA step during phishing. |
| Recommendation — Map observed phishing and relay activity to MFA-abuse techniques and tune detections for rapid replay. | ||
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?