TL;DR: AI-powered phishing, with AiTM kits and deepfake lures, is making traditional MFA easier to bypass while FIDO2 and passkeys stop proxy attacks through cryptographic domain binding, according to WorkOS. The real risk is not passkey adoption itself, but leaving SMS, push, email reset, or QR-code fallbacks active, which reopens the attack path.
NHIMG editorial — based on content published by WorkOS: Passkeys stop phishing. Your MFA fallbacks undo it
By the numbers:
- AI-generated lures have pushed click-through rates to 54%, compared to 12% for traditional phishing.
Questions worth separating out
Q: How should security teams eliminate MFA downgrade risk after deploying passkeys?
A: Treat the passkey as the required path, not an optional enhancement.
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.
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.
Practitioner guidance
- 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.
- Require passkeys for privileged identities Make FIDO2 or passkeys mandatory for admins, finance, and production-access accounts.
- Redesign recovery as a governed process Use multiple enrolled passkeys, recovery codes issued at enrollment, or in-person identity verification for break-glass recovery.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- WebAuthn implementation specifics, including the exact login APIs and relying party configuration.
- Step-by-step guidance for disabling phishable fallback methods after passkey enrolment.
- Recovery design choices for high-assurance accounts, including hardware key redundancy and in-person verification.
- Configuration advice for QR-based cross-device authentication and attestation in stricter environments.
👉 Read WorkOS's analysis of passkeys, FIDO2, and MFA fallback risk →
Passkeys and MFA fallbacks: are your controls actually phishing-resistant?
Explore further
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.
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.
A question worth separating out:
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.
👉 Read our full editorial: Passkeys fail when MFA fallbacks remain in place