Passkeys fail when MFA fallbacks remain in place

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Passkeys and FIDO2 defeat proxy-based phishing, but weak MFA fallbacks undo that protection.

Why it matters: IAM and identity security teams need to treat phishing resistance as a chain property, because one surviving fallback can reopen account takeover paths even after passkey adoption.

Context

Phishing-resistant authentication only works when every alternate path is removed from the login and recovery flow. If SMS, push approval, email one-time codes, password reset, or QR-based cross-device approval remain active, an attacker can still steer users into a phishable route even when passkeys are enrolled.

For identity programmes, the security gap is not passkey support itself but partial deployment. The control fails when teams add a stronger method without retiring weaker methods, because the authentication architecture still allows downgrade, recovery abuse, or session theft through the remaining fallback surface.

Key questions

Q: What breaks when passkeys are used alongside weak fallback authentication?

A: The programme becomes only as strong as the fallback path. If password resets, backup codes, or help desk overrides are easier to abuse than the passkey flow, attackers will target those routes instead. Passwordless adoption fails when exception handling is less governed than primary authentication.

Q: Why do passkeys still leave organisations exposed to phishing attacks?

A: Passkeys reduce phishing risk only when they are the sole usable method. If passwords, backup codes, OTP, or other legacy methods remain active, attackers can downgrade the session to one of those paths. The exposure is created by the account’s remaining authentication surface, not by the passkey itself.

Q: How should security teams decide whether QR-based passkey flows are acceptable?

A: They should decide based on the threat model, not convenience. QR-based cross-device flows are useful for usability, but they add an approval path that can be abused if users are steered from a malicious site. If high assurance is required, teams should prefer device-bound registration and avoid hybrid fallback.

Q: What is the difference between passkey security and MFA strength?

A: Passkey security is protocol-enforced phishing resistance through cryptographic domain binding. MFA strength is broader and can still include phishable methods such as SMS, push, or email reset. A system can use a strong factor and still be weak overall if it leaves alternate paths that attackers can exploit.

Technical breakdown

Why passkeys stop proxy phishing

Passkeys and FIDO2 use WebAuthn with cryptographic origin binding. During registration, the device creates a public-private key pair, keeps the private key on the authenticator, and sends only the public key to the server. During sign-in, the authenticator verifies the relying party domain before signing the challenge, so a fake domain cannot elicit a valid assertion. That makes adversary-in-the-middle proxying ineffective because the attacker never gets a reusable secret or a relayable code. The control shifts trust from human recognition to protocol-enforced domain matching.

Practical implication: Treat passkeys as the phishing-resistant baseline for accounts where login interception is the primary threat.

How MFA downgrade paths reopen access

A downgrade path exists when a stronger method sits beside weaker recovery or alternate login options. In practice, this includes SMS codes, authenticator app codes, push approvals, backup codes, email resets, and any "try another way" path that bypasses the phishing-resistant method. The attacker does not need to break passkeys. They only need to coerce the system into offering a method that still depends on human-transmitted values or recovery logic outside the cryptographic check. The security boundary becomes the entire authentication chain, not the passkey itself.

Practical implication: Inventory every alternate authentication and recovery path as part of the control, not as an exception.

Why QR-based passkey flows need separate risk decisions

Cross-device passkey flows, often initiated through a QR code, introduce an extra approval step between the browser challenge and the authenticator response. That is useful for usability, but it also creates a place where users can be prompted on a legitimate device after scanning a spoofed code from a malicious site. The issue is not passkeys as a class, but where the domain check, user approval, and device response are separated enough for attacker steering. High-assurance environments may therefore need device-bound registration only, not hybrid fallback.

Practical implication: Decide explicitly whether cross-device authentication belongs in your threat model before enabling it.

Threat narrative

Attacker objective: The attacker wants a valid authenticated session or account recovery path that bypasses the passkey and grants control over the user account.

1. Entry begins when the victim is redirected into a phishing flow that imitates a legitimate login or recovery process.
2. Credential access occurs when the attacker pushes the user toward an active fallback such as SMS, push approval, email reset, or QR-based cross-device authentication.
3. Escalation follows when the attacker captures a valid session cookie or completed authentication result from the weaker path.
4. Impact is account takeover that bypasses the phishing-resistant method without ever defeating the passkey itself.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

NHI Mgmt Group analysis

Phishing resistance is a property of the entire authentication chain, not the strongest factor in it. Passkeys stop proxy phishing only when weaker branches are removed, because attackers do not need to defeat the cryptographic method if they can downgrade the session into a recoverable or alternative path. That makes fallback governance part of the control surface, not an implementation detail. Practitioners should judge authentication by the weakest surviving route.

MFA downgrade surface is the real control gap in most passkey rollouts. The article describes a familiar failure pattern: organisations add passkeys but leave SMS, push, email resets, and backup codes in place. That creates a standing bypass route that adversaries can target without touching the passkey. The implication is that security teams must measure whether any phishable method remains reachable after enrolment, because one active fallback voids the practical assurance of the stronger method.

Phishing-resistant authentication and account recovery must be designed together. Recovery is where many deployments lose assurance, because reset workflows often preserve convenience at the expense of identity proofing strength. In governance terms, recovery is not outside authentication, it is the second authentication system. Practitioners need to treat recovery paths as privileged access flows with the same scrutiny they would apply to admin sign-in.

Cryptographic domain binding is a named control concept practitioners should use more often. It captures why passkeys succeed where human decision-making fails: the device checks the relying party before it signs, so the attacker cannot reuse a code across domains. That concept is more useful than generic MFA language because it explains the mechanism that defeats AiTM phishing. Teams should anchor phishing-resistant architecture on domain binding, not on factor count.

Identity assurance erodes whenever convenience paths outlive the threat model they were meant to soften. QR cross-device flows, fallback prompts, and legacy protocols all start as usability features, then become security exceptions that attackers selectively exploit. The right governance question is not whether the organisation has passkeys, but which alternative paths still remain callable under pressure. Practitioners should remove or tightly constrain every path that weakens assurance after enrolment.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Fallback governance is the new phishing control point: once passkeys are enrolled, the remaining risk is not credential theft through the strongest method, but policy drift that keeps SMS, push, email, or reset flows callable. Identity teams should map every alternate branch in the authentication tree and remove the ones that preserve human-relayed secrets.

Passkey adoption without fallback removal creates a false sense of phishing resistance. The practical test is simple: if an attacker can still route a user to a weaker factor or recovery path, the authentication programme is not yet closed to AiTM attack patterns.

For practitioners

• Audit the fallback surface Inventory every active authentication and recovery path in each identity provider and application, including SMS, push, email codes, backup codes, password reset, and "try another way" options.
• Make phishing-resistant methods mandatory for privileged users Require passkeys or hardware security keys for administrators, finance roles, and production access, rather than offering them as optional enrollment choices.
• Remove phishable recovery routes Redesign account recovery so it cannot bypass the phishing-resistant method through email or SMS, and require stronger identity proofing or pre-enrolled recovery codes instead.
• Decide on QR cross-device usage explicitly Disable QR-based cross-device authentication in high-assurance environments, or require separate device registration where the threat model cannot tolerate hybrid fallback.
• Monitor for MFA downgrade attempts Alert on cases where users enrolled in passkeys authenticate through weaker methods, because that is a strong signal of misconfiguration or active attack.

Key takeaways

• Passkeys reduce proxy phishing risk, but only when the identity stack stops offering weaker alternate routes.
• The real vulnerability is MFA downgrade, where attackers move users from a strong method to a phishable fallback.
• Identity teams should treat recovery, reset, and cross-device flows as part of the authentication control, not as exceptions.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
• Mfa Downgrade Surface: An MFA downgrade surface is the set of alternate login and recovery paths that allow users to bypass a phishing-resistant method and authenticate through a weaker one. In mature programmes, this surface is treated as part of the authentication control, because attackers often exploit the easiest remaining route rather than the strongest factor.
• Cryptographic binding: Cryptographic binding links the authenticator to a specific website, application, or verifier so the credential cannot be replayed against a different target. This is the technical property that makes phishing-resistant authentication work. Without it, an MFA flow may still be vulnerable to impersonation even if it uses multiple factors.

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.