Are passkeys phishing-resistant?

Yes. The private key never leaves the authenticator, and signatures are bound to the Relying Party ID (your domain). A phishing site on a different domain cannot induce the authenticator to sign for yours. This is the single largest security win over passwords.

What about users who don't have Face ID or Windows Hello?

They can still use a hardware security key (YubiKey) as a WebAuthn authenticator, or fall back to password + TOTP. Passkeys are a majority-of-users solution, not a universal one.

Do passkeys count as MFA for compliance?

Under most frameworks (NIST 800-63B AAL2, PCI DSS v4), device-bound passkeys with user verification (biometric or PIN) qualify as multi-factor. Synced passkeys are somewhat contested for AAL3; check your specific regime. For SOC 2 and ISO 27001, passkeys are broadly accepted as strong authentication.

Passkeys & WebAuthn: Implementation, UX, Fallbacks

Passkeys are WebAuthn credentials that sync across a user's devices via their platform provider (Apple, Google, Microsoft) or password manager.

Passkeys and WebAuthn: Passwordless Auth That's Finally Ready for Production

Passkeys are the productized, cross-device-syncing form of WebAuthn public-key credentials. From the user's perspective, they sign in with Face ID, Touch ID, or a Windows Hello prompt, and the same credential works across their iPhone, Mac, and iPad (if Apple) or Android and Chrome (if Google) automatically. From the server's perspective, you store a public key per user per credential and verify signed challenges on sign-in — no password hash, no rotation policy, no reset flow that phishers can exploit. Since 2023-2024, all major platforms support passkey sync, and adoption is now realistic for consumer and B2B apps alike.

The mental model in three primitives

(1) Registration: your server sends a challenge and Relying Party ID; the browser prompts the user's authenticator to generate a key pair; the public key returns to your server and you store it against the user account. (2) Authentication: your server sends a challenge; the authenticator signs it with the private key; you verify the signature against the stored public key. (3) Discoverable credentials (aka resident keys): the authenticator can enumerate its own credentials for a given RP, so the user doesn't need to type a username first — the passkey identifies them. This is what enables the 'just tap sign in' experience. Use a well-maintained library (SimpleWebAuthn for Node, py_webauthn for Python, webauthn4j for JVM) — do not implement CBOR decoding and attestation verification yourself.

Rollout strategy: additive, not migratory

Add passkeys as an additional sign-in method next to existing password/SSO, not as a replacement. Prompt existing users to enroll a passkey after a successful password sign-in, framing it as 'faster and more secure sign-in on this device.' New users get an optional passkey prompt during onboarding but can still use email + password if they decline. Track: passkey enrollment rate, passkey sign-in rate among enrolled users (should trend toward 90%+ within 60 days), sign-in success rate for passkeys vs. passwords (passkeys typically win by 5-15 points once users adapt).

Recovery and account portability — the hard part

Passkeys sync within an ecosystem but not across ecosystems (an Apple passkey does not sync to Windows). Recovery paths users need: (1) 'I got a new phone in the same ecosystem' — automatic via iCloud/Google sync, nothing to build. (2) 'I switched from iPhone to Android' — user needs to enroll a new passkey using another auth method (email magic link, existing password, recovery code). Provide this flow. (3) 'I lost access to my email and my devices' — the classic account-recovery hard problem. Passkeys do not make this easier; keep an out-of-band recovery method (support-assisted verification with ID or trusted contacts). (4) Provide multi-credential support: let users enroll passkeys on multiple devices/managers explicitly. This is the pragmatic answer to cross-ecosystem lock-in.

B2B and enterprise nuances

For B2B, passkeys reduce phishing (the top breach vector) but do not replace SSO. Enterprise buyers still expect SAML/OIDC integration with their IdP for provisioning, auditing, and revocation. Passkeys are a per-user credential; SSO is a per-org delegation. Support both: SSO for org-wide identity, passkeys as a per-user MFA-equivalent for orgs without SSO or as a step-up factor for high-risk actions. Attestation (the ability to verify the authenticator model) matters for regulated verticals — enterprise buyers may require FIDO L1/L2 certified authenticators; consumer apps almost never need attestation.

UX pitfalls that kill enrollment

(a) Prompting for passkey enrollment before the user has completed value moments — they decline and the offer rarely re-surfaces. Delay to post-first-success. (b) Confusing 'passkey' with 'password' in copy — users think you're asking them to invent yet another string. Use platform-blessed language ('Sign in with Face ID', 'Use your device') and let the OS branding do the explaining. (c) Failing to detect device support and offering passkeys on browsers where they'll silently fail. Feature-detect PublicKeyCredential and hide the CTA if unavailable. (d) Not providing a graceful fallback when the user cancels the platform prompt — they should land back on the same screen with password as the obvious next option, not an error page.

Frequently asked questions

Are passkeys phishing-resistant?: Yes. The private key never leaves the authenticator, and signatures are bound to the Relying Party ID (your domain). A phishing site on a different domain cannot induce the authenticator to sign for yours. This is the single largest security win over passwords.
What about users who don't have Face ID or Windows Hello?: They can still use a hardware security key (YubiKey) as a WebAuthn authenticator, or fall back to password + TOTP. Passkeys are a majority-of-users solution, not a universal one.
Do passkeys count as MFA for compliance?: Under most frameworks (NIST 800-63B AAL2, PCI DSS v4), device-bound passkeys with user verification (biometric or PIN) qualify as multi-factor. Synced passkeys are somewhat contested for AAL3; check your specific regime. For SOC 2 and ISO 27001, passkeys are broadly accepted as strong authentication.