Passkeys fail when MFA fallbacks remain in place

At a glance

What this is: This is an analysis of why passkeys and FIDO2 stop phishing only when weaker MFA fallbacks are removed, and the key finding is that fallback paths are the real control failure.

Why it matters: It matters because IAM teams can deploy phishing-resistant authentication and still leave downgrade paths that undermine both human access and privileged account protection.

By the numbers:

• AI-generated lures have pushed click-through rates to 54%, compared to 12% for traditional phishing.

👉 Read WorkOS's analysis of passkeys, FIDO2, and MFA fallback risk

Context

Passkeys and FIDO2 are designed to bind authentication to the real domain, so a fake site cannot simply relay a code or push approval through a proxy. The security model changes from human judgment to cryptographic verification, which is why phishing-resistant authentication exists as a distinct control class rather than a stronger variant of MFA.

The governance problem is that many organisations keep phishable fallback paths alive after passkey rollout. Once SMS, email reset, push approval, or cross-device QR flows remain available, the weakest path becomes the effective control boundary for both human users and privileged identities.

Key questions

Q: How should security teams eliminate MFA downgrade risk after deploying passkeys?

A: Treat the passkey as the required path, not an optional enhancement. Remove SMS, email reset, push approval, backup codes, and any 'try another way' option that can bypass phishing-resistant authentication. Then test the full login and recovery journey as an attacker would, because a single reachable fallback makes the whole chain phishable again.

Q: Why do passkeys still fail if fallback methods remain enabled?

A: Passkeys fail in practice when organisations keep alternate routes that a human can satisfy and an attacker can exploit. The cryptographic method is resistant to proxy phishing, but the identity system is only as strong as the weakest reachable method. If SMS, email, or recovery flows remain open, attackers target those paths instead.

Q: What do teams get wrong about phishing-resistant MFA?

A: They often measure success by the presence of a strong factor instead of the absence of weaker bypasses. A deployment can include passkeys and still be vulnerable if users can fall back to OTP, push approval, or password reset. Governance should focus on reachable paths, not just enrolled methods.

Q: What should organisations do when passkeys are not enough on their own?

A: Add session and authorization controls that limit damage after login. Bind sessions to devices where possible, shorten token lifetimes for sensitive actions, and monitor consent grants, endpoint compromise, and unusual recovery events. Passkeys protect authentication, but they do not prevent OAuth abuse or post-login session theft.

Technical breakdown

Cryptographic origin binding in FIDO2 and passkeys

FIDO2 and passkeys use a public-private key pair tied to a relying party ID, which is the service domain. During authentication, the device checks that the browser domain matches the registered relying party before signing a server challenge. That means a phishing proxy cannot persuade the authenticator to release a valid assertion for the wrong site. The trust decision moves from the user to the protocol. This is what makes the method phishing-resistant when it is deployed without alternate login routes.

Practical implication: require exact-domain registration and make phishing-resistant authentication the only path for sensitive accounts.

Why MFA downgrade attacks succeed

An MFA downgrade attack does not need to defeat the strongest factor. It only needs an active fallback such as SMS, email codes, push approval, or password reset. Criminal tooling already targets those paths because they preserve a human-mediated relay that a proxy or social engineering call can intercept. The control failure is architectural: the authentication chain remains only as strong as its weakest reachable method. If that method is still enabled, the deployment is not truly phishing-resistant.

Practical implication: inventory every alternate sign-in and recovery path, then remove or harden the ones that bypass passkey enforcement.

Cross-device QR flows and consent boundaries

Cross-device passkey flows add a legitimacy gap between the browser session and the approval action. The user scans a QR code on one device and approves on another, which creates a new place for attackers to spoof prompts and redirect victims into granting a valid FIDO assertion to the wrong session. The issue is not passkeys themselves, but the approval bridge introduced by some implementations. In high-risk environments, that bridge can become a practical bypass path.

Practical implication: disable QR-based cross-device fallback where the threat model cannot tolerate approval confusion.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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 chain property, not a factor property. The article shows that passkeys can stop proxy-based phishing only when SMS, push, email reset, and other weaker paths are removed from the same identity flow. That means the real control boundary is the full authentication chain, not the strongest authenticator a user enrolled. Practitioners should treat any remaining fallback as part of the security design, not as recovery convenience.

Fallback paths create the real MFA downgrade surface. Attackers do not need to break cryptography if they can steer users into a human-relayed alternative. This is the same structural weakness that makes traditional MFA phishable, but now it exists inside supposedly phishing-resistant deployments. The implication is that identity governance has to measure reachable bypasses, not just enrolled factors.

Passkeys solve authentication, not the broader access problem. Consent phishing, endpoint compromise, and session theft remain outside the passkey protection model. That separation matters for NIST CSF and zero trust programmes because login hardening does not remove authorization abuse or post-authentication hijack risk. Practitioners should stop treating passkey rollout as a complete identity control outcome.

Cryptographic domain binding should be the new baseline for privileged human access. FIDO2 changes the economics of phishing because the attacker cannot replay a code or proxy a signed challenge for the wrong domain. For privileged users, the control question is no longer whether MFA exists, but whether the organisation has eliminated all phishable escape hatches. The implication is that governance must move from factor count to path integrity.

Passkey adoption exposes the hidden problem of recovery design. Account recovery is where many deployments quietly reintroduce the very phishing risk passkeys were meant to remove. If recovery can be completed through email or SMS, the organisation has reintroduced a human-verifiable bypass into a cryptographic model. Practitioners should view recovery as part of the authentication system, not as a separate service.

From our research:

• AI-generated lures have pushed click-through rates to 54%, compared to 12% for traditional phishing, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Attackers can reach exposed AWS credentials in an average of 17 minutes, and as quickly as 9 minutes in some cases, according to Entro Security.
• For a broader governance lens on machine identity risk, see The 52 NHI breaches Report, which maps common credential and lifecycle failure patterns.

What this signals

Passkey rollout is becoming a governance test, not a feature rollout: the moment SMS, push, email reset, or QR fallback remains reachable, phishing resistance becomes conditional instead of absolute. IAM teams should expect auditors and internal risk owners to ask which fallback paths still exist, because those paths define the real control perimeter. For a control framework lens, align the rollout with the NIST SP 800-63 Digital Identity Guidelines.

Fallback exposure is the new MFA debt: organisations often count enrolled passkeys while ignoring the number of remaining bypasses. That metric is misleading, because attackers exploit reachable alternatives rather than strong methods. The practical signal is whether privileged users can complete login or recovery without touching a phishing-resistant authenticator.

Passkey programmes should be treated as part of the broader zero trust stack: authentication hardening does not remove consent abuse, endpoint compromise, or session hijack risk. Teams that only focus on sign-in controls will miss where identity assurance breaks later in the session. If you are mapping the programme to standards, the relevant control family is MITRE ATLAS adversarial AI threat matrix for attacker behaviour and NIST SP 800-63 Digital Identity Guidelines for assurance mechanics.

For practitioners

• Audit every active fallback path Inventory password reset, SMS, email codes, push approvals, backup codes, and any 'try another way' option across identity providers and applications. Remove or harden every path that allows authentication without a phishing-resistant method, including for privileged users.
• Require passkeys for privileged identities Make FIDO2 or passkeys mandatory for admins, finance, and production-access accounts. Do not allow these accounts to authenticate through weaker methods once a phishing-resistant credential is enrolled.
• Redesign recovery as a governed process Use multiple enrolled passkeys, recovery codes issued at enrollment, or in-person identity verification for break-glass recovery. Do not use email or SMS as a backdoor into high-assurance accounts.
• Disable QR cross-device fallback where needed Turn off QR-based cross-device authentication for high-security use cases if your threat model cannot tolerate approval confusion or spoofed prompt abuse. Require device-local registration instead.
• Monitor for MFA downgrade attempts Alert when a user with an enrolled passkey authenticates through a weaker method. That signal often indicates misconfiguration, recovery abuse, or an active phishing campaign.

Key takeaways

• Passkeys and FIDO2 stop proxy phishing only when organisations remove weaker fallback methods from the identity chain.
• The scale of the problem is already visible in AI-assisted phishing, which is driving much higher click-through rates than traditional lures.
• The decisive control move is to eliminate downgrade paths, redesign recovery, and treat authentication path integrity as a governance requirement.

Key terms

• Passkey: A passkey is a phishing-resistant credential that uses public-key cryptography instead of shared secrets. The private key stays on the user’s device and the server stores only the public key. In practice, it binds authentication to the real domain and removes the replayable secret that attackers normally steal.
• FIDO2: FIDO2 is the standards family behind hardware security keys and passkeys. It uses cryptographic challenge-response and relying party binding so the authenticator only signs for the intended service domain. For identity teams, the key distinction is that phishing resistance comes from protocol design, not user judgment.
• MFA downgrade attack: An MFA downgrade attack is a method of steering a user away from a strong authentication factor to a weaker reachable fallback. The attacker does not need to defeat the best control if SMS, email reset, push approval, or another path is still available. The real weakness is the remaining alternative route.
• Cryptographic origin binding: Cryptographic origin binding ties an authentication assertion to the exact service domain that registered it. If a user is on a fake or proxied site, the authenticator refuses to sign for the wrong relying party. This is the mechanism that makes passkeys resistant to adversary-in-the-middle phishing.

Deepen your knowledge

Passkey and phishing-resistant authentication governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a resilient identity programme and need to remove downgrade paths, it is worth exploring.

This post draws on content published by WorkOS: Passkeys stop phishing. Your MFA fallbacks undo it. Read the original.