Phishing-resistant web authentication and why MFA is not enough

At a glance

What this is: This is an analysis of phishing-resistant web authentication and the key finding that many common MFA methods can still be relayed by attackers.

Why it matters: It matters because IAM teams must separate true phishing resistance from brand-name MFA, especially when protecting SSO, step-up access, and session integrity across human and workforce identity programmes.

👉 Read Scramble ID's guide to phishing-resistant web authentication and session binding

Context

Phishing-resistant web authentication is the point where the login ceremony itself becomes hard to proxy. The issue is not whether a user entered a code or approved a prompt, but whether the proof is cryptographically tied to the real site or the exact browser session.

That distinction matters for IAM because many programmes still treat MFA as a single control category. In practice, phishing resistance changes how teams evaluate WebAuthn, passkeys, QR-based login, fallback paths, and session binding for human users across high-risk applications.

Key questions

Q: How should security teams implement phishing-resistant authentication for workforce apps?

A: Start by making the primary login path origin-bound with WebAuthn or passkeys, then apply the same standard to step-up authentication for sensitive actions. Next, remove relayable fallbacks such as SMS OTP, email links, and blind push approvals from privileged journeys. The goal is a ceremony an attacker cannot proxy from a fake site.

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 breaks when QR login is not session bound?

A: Without session binding, a QR becomes a transferable proof that can be scanned, forwarded, or replayed outside the initiating login context. That turns a convenience flow into a phishable one. A secure implementation must tie approval to the exact browser session and expire quickly.

Q: Which authentication paths should keep the strongest phishing resistance requirements?

A: Keep the strongest requirements on admin access, financial approvals, sensitive customer data, and any workflow where token theft would create broad downstream impact. Those paths should use authenticators and ceremonies that resist relay, not just methods that are easy for users to approve.

Technical breakdown

Origin binding in WebAuthn and passkeys

WebAuthn and passkeys are phishing-resistant because the authenticator checks the relying party identity, usually the RP ID and origin context, before it signs a fresh challenge. That means a fake login page cannot reliably elicit a reusable proof for another site. The security property is not just cryptography, but cryptography anchored to the correct web origin. In enterprise use, user verification strengthens the ceremony for high-risk actions because the proof is not merely possession of a device, but a deliberate authentication event tied to the legitimate application.

Practical implication: require origin-bound authenticators for primary workforce authentication and step-up paths where relay resistance matters.

Session binding in QR(DID) login flows

QR(DID) can be phishing-resistant only when the QR is signed, short-lived, and bound to the initiating browser session. The session binding matters because the approval must return to the exact login context that created the request, not any browser or tab that happens to scan it. A typed confirmation code adds explicit intent and blocks blind approval. Without those controls, a QR flow becomes just another transferable token, which is exactly what attackers need for relay or screenshot-based abuse.

Practical implication: treat QR login as a session-bound ceremony, not as a convenience feature that can safely accept forwarded or replayed approvals.

Why OTP and push approvals still fail under AiTM

OTP and push-based approvals are not phishing-resistant because they can be relayed in real time through adversary-in-the-middle infrastructure. The attacker proxies the legitimate login page, captures the proof, and reuses the resulting session cookies or tokens. That attack pattern does not require breaking cryptography, only moving the ceremony into the wrong trust boundary. For IAM teams, the key problem is that these methods validate user participation, but not the true origin of the request or the session that receives the response.

Practical implication: remove relayable fallback methods from sensitive flows instead of treating them as interchangeable with phishing-resistant authentication.

Threat narrative

Attacker objective: The attacker wants a valid authenticated session that bypasses the victim’s intended login protections without needing to steal a reusable password.

1. Entry occurs when the victim reaches a fake login page that proxies the real site in an adversary-in-the-middle flow.
2. Credential access happens when the user completes OTP, push approval, or another relayable ceremony and the attacker captures the proof in real time.
3. Impact follows when the attacker replays the session cookie or token against the legitimate service and gains access as the victim.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing resistance is a ceremony property, not an MFA label. Many programmes still classify OTP, push, and password plus second factor as equivalent controls, but they are not equivalent under relay attack. The critical question is whether the proof is origin-bound or session-bound, because that is what stops adversary-in-the-middle abuse. Practitioners should stop treating MFA as a binary and start evaluating the authentication ceremony itself.

Session binding is the missing control concept for cross-device login. WebAuthn solves same-device origin binding well, but shared terminals and cross-device journeys need a different trust anchor. When QR-based login is not explicitly bound to the initiating session, the ceremony becomes portable and therefore phishable. The field needs a clearer distinction between a login convenience and a verifiable session proof, because those are not the same control.

Fallback authentication is where phishing resistance is usually lost. Teams may deploy passkeys for the primary path and then reintroduce email links, OTP, or push approvals for recovery, exceptions, or legacy apps. That creates a weaker secondary path that attackers will target first. The implication is that phishing resistance has to be designed as an end-to-end access model, not as an isolated feature on the strongest login screen.

Origin binding and session binding together define the new assurance baseline for human identity. Human IAM programmes now need to assess whether each access path resists relay, not just whether it supports modern authentication. That shifts policy, application integration, and recovery design toward verifiable ceremonies that cannot be proxied through a fake site. Practitioners should measure assurance by replay resistance, not by authentication branding.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation lag often outlives exposure windows.
• For adjacent guidance on lifecycle controls, see Ultimate Guide to NHIs , Key Challenges and Risks for how exposure, rotation, and offboarding gaps compound identity risk.

What this signals

Phishing resistance is becoming a programme design issue, not a login feature issue. IAM teams should expect auditors and security architects to ask whether authentication methods are actually relay-proof, especially where SSO and privileged workflows depend on the same session trust model. The useful standard here is not whether MFA exists, but whether the proof can be proxied through a fake site.

Replay resistance is now part of human identity governance. If your recovery flows still rely on email links or OTP, your strongest control is being diluted at the edge of the programme. A practical next step is to align authentication policy with NIST SP 800-63 Digital Identity Guidelines and use phishing resistance as the benchmark for sensitive access.

Passkey adoption alone will not close the gap. The control failure often appears in exception handling, legacy app integration, and fallback recovery, where weaker methods persist. Teams that want durable assurance should treat the weakest authentication path as the real programme boundary and redesign around that constraint.

For practitioners

• Classify each login path by relay resistance Map primary authentication, step-up, recovery, and shared-device flows separately. Mark any path that can be proxied through a fake site as non-phishing-resistant, even if it uses MFA.
• Require origin-bound authentication for high-risk access Use WebAuthn or passkeys for workforce access to sensitive applications, and enforce user verification where the action risk justifies it. Keep the relying party identity and challenge freshness in scope for security review.
• Bind cross-device login to the initiating session If you use QR-based login, make the QR signed, short-lived, single-use, and tied to the browser session that initiated it. Add typed confirmation so the approval cannot be blind.
• Eliminate relayable fallback paths from privileged apps Remove OTP, email links, and unauthenticated push approvals from administrative and other high-risk journeys. Replace them with step-up methods that preserve the same origin or session binding as the primary path.

Key takeaways

• Phishing-resistant authentication depends on cryptographic binding to the real origin or session, not on user approval alone.
• OTP, push prompts, and weak fallback paths remain viable attacker relay channels even when an organisation claims MFA coverage.
• IAM teams should evaluate the entire authentication journey, including recovery and exception paths, as part of phishing resistance.

Key terms

• Phishing-resistant authentication: An authentication method that cannot be completed by an attacker who is proxying a fake login page. The proof is bound to the real origin or the exact session, so stolen OTPs, approvals, or relayed prompts do not create a usable login for the attacker.
• Origin binding: A property of an authentication ceremony where the credential or proof is cryptographically tied to the legitimate website or relying party. This prevents a fake site from reusing the proof elsewhere and is the core reason WebAuthn and passkeys resist relay attacks.
• Session binding: A control pattern where an approval or proof is tied to one specific browser or application session. It matters for QR-based and cross-device flows because a transferred approval should fail outside the initiating session, even if the QR code itself is visible or copied.
• Adversary-in-the-middle: A phishing pattern where an attacker proxies the victim’s login flow between the fake site and the real service. The attacker does not need to defeat the authenticator directly, only to capture and relay the ceremony in real time before the session is established.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: Phishing-Resistant Web Authentication. Read the original.