Because both can remain phishable or relayable under a real-time MitM attack. An attacker who captures or socially engineers those factors can still impersonate the user, so the control problem is not just second factor count but whether the factor can be reused by someone else.
Why OTPs and push approvals still leave you exposed to MitM
OTP and push approval flows authenticate the user, but they do not always authenticate the session context or the destination the user is approving. A real-time man-in-the-middle can relay the code, replay the push interaction, or steer the user into approving a transaction the attacker controls. The weakness is therefore not the second factor itself, but whether it can be phished, relayed, or re-used in the attacker’s session.
When that happens, the attacker is not “breaking” the factor in a cryptographic sense, they are borrowing it. That is why MFA Guide matters here: it distinguishes phishing-resistant methods from factors that still depend on user judgment during the authentication step.
Why the attack works against real users
OTPs and push prompts often arrive in a workflow where the user has already been conditioned to expect a login or approval. A MitM can exploit that expectation by placing the legitimate site and the attacker in the middle, then forwarding the challenge in real time. If the user enters an OTP or taps “Approve” without verifying the origin, the attacker receives a valid response for the current session.
Push fatigue, number matching abuse, and relay tooling all target the same failure mode: the factor is still useful to the attacker if it can be induced from the user under pressure. NIST SP 800-63 Digital Identity Guidelines is a useful reference point because it treats phishing-resistant authenticators as materially stronger than reusable one-time secrets or approval prompts.
The practical distinction is that OTPs and basic push approvals prove only that someone possessed or interacted with the factor at that moment. They do not, by themselves, prove that the approval was bound to the right origin, the right transaction, or a user who was not being proxied by an attacker.
What actually closes the gap
The control improvement is to move from factor reuse to origin binding and transaction binding. Phishing-resistant authenticators, especially WebAuthn or FIDO2 security keys, are designed to respond to the legitimate relying party rather than a relayed prompt. That reduces the usefulness of real-time relay because the attacker cannot simply forward the interaction and inherit the same proof.
Policy also matters. If an environment still allows OTP fallback, legacy push enrollment, or approval prompts without clear transaction details, the weaker path becomes the path of least resistance. NIST Cybersecurity Framework 2.0 is useful for placing this in the broader protection and identity-governance lifecycle, while NIST AI Risk Management Framework is not the right lens here; the issue is not AI behavior, it is session trust and authenticator strength.
For operational hardening, the strongest pattern is to prefer authenticator choices that are resistant to relay, require explicit origin verification, and avoid granting access solely on a reusable code or an ambiguous one-tap approval. When practical, pair that with step-up checks for sensitive actions so that “login succeeded” is not treated as equivalent to “transaction is safe.”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-63 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authenticators and relay resistance directly answer the MitM risk question |
| Recommendation — Prefer phishing-resistant authenticators that cannot be relayed into an attacker-controlled session. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | The issue is authenticator strength and lifecycle in access protection |
| PR.AA-01 — Identity Management, Authentication, and Access Control | The question concerns how authentication proves access without confirming session origin | |
| Recommendation — Enforce stronger authenticators for sensitive access and phase out relayable fallback methods. Bind authentication decisions to verified identities and access context rather than a simple factor count. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | MitM risk persists when identity proofing and authenticator use are weakly governed |
| Recommendation — Govern authenticator use so access depends on trustworthy identity and approved authentication paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Relayable OTP and push flows are insecure authentication patterns for non-human or human actors alike |
| Recommendation — Replace relayable approval patterns with authenticator designs resistant to phishing and relay. | ||
Practitioner Guidance
What to verify: Check whether your approval flow binds the authentication event to the actual relying party and transaction details, not just to the user account. If a code or push can be satisfied from a proxied browser session, treat it as relayable until proven otherwise.
Decision rule: If a factor can be used while the attacker remains in the middle, do not count it as phishing-resistant protection for high-value access. Reserve it for lower-risk use cases or pair it with stronger origin-bound authentication for privileged actions.
Common mistake: Treating “MFA enabled” as a finished control. The security question is whether the factor can be replayed, relayed, or socially engineered into approving the attacker’s session.
Practitioner takeaway: The right test is not whether the user had a second factor, but whether the factor can still be captured and reused inside an attacker-controlled path.