Phishing-resistant web authentication and why MFA is not enough

At a glance

What this is: This is a technical analysis of phishing-resistant web authentication, showing that WebAuthn and session-bound QR flows resist relay attacks while OTP and push approvals do not.

Why it matters: It matters because identity teams need to distinguish true phishing resistance from MFA that can still be proxied, especially in high-risk web login and step-up flows.

Context

Phishing-resistant web authentication is a control problem, not a branding problem. If a login ceremony can be relayed through a fake page, then the attacker does not need to defeat the factor itself, only the way the factor is presented and approved.

The article separates origin-bound authentication, such as WebAuthn, from session-bound confirmation patterns, such as signed QR flows. That distinction matters for NHI, agentic, and human identity programmes because the trust boundary sits in the ceremony, the browser session, and the relying party context, not in the label MFA.

The practical question for identity teams is whether their current login and step-up paths still allow adversary-in-the-middle relay, fallback abuse, or blind approval. If they do, the programme has MFA coverage without phishing resistance.

Key questions

Q: How should organisations implement phishing resistant authentication for user access in web applications?

A: Use WebAuthn with hardware backed authenticators and avoid relying on passwords as the primary control. Combine strong enrollment, device binding, and step up checks for risky actions. The goal is to remove reusable secrets from the login flow so stolen credentials cannot be replayed across services. That materially reduces phishing success and credential stuffing exposure.

Q: Why do OTP and push approvals fail against adversary-in-the-middle attacks?

A: They fail because they prove user participation, not site authenticity. An attacker can proxy the real login page, capture the code or approval in real time, and forward it to the legitimate service. Once the session is established, the attacker can reuse the resulting token or cookie.

Q: What are the signs that a phishing-resistant login design is failing?

A: If users can still complete high-risk login through email links, one-time codes, or an approval that lacks clear origin or session context, the design is not truly phishing-resistant. Another warning sign is a strong primary method paired with a weaker fallback that attackers can target instead.

Q: What is the difference between origin binding and session binding in web authentication?

A: Origin binding ties the proof to the legitimate website or relying party, so a fake domain cannot replay it. Session binding ties the approval to the exact browser session that initiated the request, which is useful when the login or approval happens on a different device and still must not be relayable.

Technical breakdown

Why MFA can still be relayed through adversary-in-the-middle phishing

Multi-factor authentication only proves that a factor was presented, not that the user authenticated to the correct site or session. In an adversary-in-the-middle attack, the attacker proxies the real login page, captures the interactive proof in real time, and forwards it to the legitimate service. OTPs and push approvals are especially exposed because they are reusable within the session window and are not cryptographically tied to the original relying party.

Practical implication: Treat MFA as insufficient unless the ceremony is bound to the legitimate origin or the initiating session.

How WebAuthn and passkeys stop origin spoofing

WebAuthn is phishing-resistant because the authenticator validates the relying party identifier and signs a fresh challenge for that origin. The proof is not a reusable secret, so a fake site cannot harvest something it can later replay elsewhere. For higher-risk actions, user verification strengthens the assurance by requiring local proof on the device before the signature is released.

Practical implication: Use WebAuthn where you need origin-bound proof that cannot be forwarded to a different site.

Why QR-based login only works when the proof is session-bound

QR-based login is only phishing-resistant when the QR is signed, short-lived, single-use, and bound to the initiating browser session. That prevents screenshot relay and approval drift, where the user scans a forwarded code or confirms the wrong browser instance. The security property comes from the binding between the mobile approval and the exact browser session, not from the QR code itself.

Practical implication: Require session binding and explicit user confirmation for QR login, and reject any flow that can succeed in a different browser session.

Threat narrative

Attacker objective: The attacker wants a reusable authenticated session or token that can be replayed against the real service without the user’s device or presence.

1. Entry occurs when an attacker proxies the legitimate login page through adversary-in-the-middle phishing and captures the user’s interaction in real time.
2. Credential access follows when the attacker relays OTP or push approval to the real service and obtains a valid session or token.
3. Impact occurs when the attacker reuses the authenticated session to enter applications as the user, bypassing the intended protection of MFA.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA is not the control boundary when the ceremony itself can be proxied. The relevant question is whether authentication proof is bound to the origin or merely relayed through a site that looks legitimate to the user. When the proof is transferable, phishing resistance does not exist, even if the login flow contains multiple factors. The practitioner conclusion is that ceremony design, not factor count, defines resistance.

Origin binding and session binding solve different parts of the same trust problem. WebAuthn answers the question of whether the browser is talking to the right relying party, while session-bound QR flows answer whether the approval belongs to the initiating browser session. Both avoid blind approval patterns, but they do so through different trust anchors. Teams should treat these as control patterns, not UI variants.

Fallback authentication often becomes the real attack surface. If OTP, email links, or push approvals remain available for sensitive apps, attackers will target the weakest fallback rather than the strongest primary method. That makes policy design part of phishing resistance, because the inherited weakest path determines the effective assurance level. The practitioner conclusion is to govern the fallback chain as strictly as the primary login method.

Phishing-resistant web authentication creates a stronger identity assurance model only when session theft is also addressed. Login resistance reduces initial compromise, but session tokens, device context, and post-login monitoring still govern what happens after authentication succeeds. The implication is that identity teams need to align login assurance, session security, and step-up policy as one control surface.

Cryptographic ceremony binding is the named concept that changes the category. It means the authentication proof is tied to the real relying party or the exact session, so a hostile intermediary cannot lift and replay it elsewhere. That is the real differentiator between authentication that merely factors identity and authentication that resists phishing. The practitioner conclusion is to evaluate controls by binding strength, not by factor count.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Ceremony binding is the control concept that practitioners need to operationalise. The security question is no longer whether MFA exists, but whether the authentication proof is bound tightly enough to survive a proxy attack. For identity programmes, that shifts evaluation from factor presence to ceremony integrity, which is the boundary that attackers actually exploit.

Teams should expect relay attacks to move toward whatever fallback remains easiest to abuse. When a secure primary method exists but weaker alternate paths still work, the programme inherits the weakest path as its real assurance level, so governance needs to cover login policy, fallback policy, and session policy together.

For practitioners

• Enforce origin-bound login for high-risk applications Require WebAuthn or another cryptographically bound method where the authenticator validates the relying party before releasing a proof, especially for privileged or sensitive web apps.
• Bind cross-device approvals to one browser session For QR-based authentication, require a signed, short-lived code that can only complete the login in the initiating browser session and expires after a single use.
• Remove weak fallback paths from step-up flows Disable OTP, email links, and other relayable fallbacks for applications where phishing resistance is a requirement, rather than leaving them as convenient escapes.
• Instrument authentication outcomes and mismatch events Track presented, confirmed, timeout, and mismatch events so you can see when users are being pushed toward relay-prone flows or silent fallback paths.
• Treat session security as part of phishing resistance Set short session lifetimes where appropriate, monitor for session anomalies after login, and make sure successful authentication does not become the only security checkpoint.

Key takeaways

• Phishing-resistant authentication is defined by cryptographic binding to the right origin or session, not by the mere presence of multi-factor checks.
• Relayable OTP and push methods can still be abused through adversary-in-the-middle attacks, so they do not provide phishing resistance on their own.
• Identity teams should prioritise origin-bound or session-bound ceremonies, then close weak fallback paths that undermine the stronger control.

Key terms

• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Origin binding: A cryptographic property that ties an authentication response to the legitimate site or service being accessed. It reduces the value of fake login pages because a credential response generated for one origin cannot be reused on another without failing verification.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.