Passwords remain the most common way accounts are compromised, and many forms of multi-factor authentication can now be phished. Passwordless authentication based on FIDO2 and WebAuthn, including passkeys, replaces shared secrets with public-key cryptography bound to the real website or application. It is phishing-resistant by design and, when deployed well, easier for users than passwords plus codes. This guide explains how passkeys and other passwordless methods work, the difference between synced and device-bound passkeys, where each fits for workforce and customer identity, and how to plan a rollout, including account recovery, which is where passwordless programmes usually succeed or fail.
Key takeaways
- FIDO2/WebAuthn credentials, including passkeys, are phishing-resistant because the browser or platform only uses the credential with the legitimate origin it was created for.
- Synced passkeys are backed up across a user's devices through a platform provider; device-bound passkeys (for example on security keys) never leave the device. NIST SP 800-63B-4 permits syncable authenticators at AAL2 but not at AAL3.
- Use device-bound, hardware-backed credentials for administrators and high-risk roles, and synced passkeys for broad workforce and customer adoption.
- Passwordless is only as strong as enrolment and recovery. If a help-desk call can replace a passkey, attackers will make that call.
How phishing-resistant authentication works
With FIDO2/WebAuthn, the user's device creates a key pair for each site or application. The private key stays with the authenticator (a phone, laptop platform authenticator or security key). To sign in, the site sends a challenge; the authenticator signs it after the user unlocks it with a biometric or PIN. The browser includes the site's origin in what is signed, so a credential created for a real site cannot be used on a look-alike phishing site. There is no shared secret on the server to steal.
Comparing authentication methods
| Method | Phishing-resistant? | Main weaknesses |
|---|---|---|
| Password only | No | Reuse, phishing, spraying, credential stuffing |
| Password plus SMS or voice code | No | SIM swap, interception, real-time phishing |
| Password plus authenticator app code | No | Real-time phishing relays the code |
| Push notification | No (number matching helps) | MFA fatigue, adversary-in-the-middle |
| Synced passkey | Yes | Security depends on the sync provider account and its recovery |
| Device-bound passkey or FIDO2 security key | Yes | Loss of device; logistics of issuing keys |
| Certificate-based authentication / smart card | Yes | PKI management overhead |
What NIST SP 800-63B-4 says
NIST published SP 800-63-4 in August 2025. Its authentication volume, SP 800-63B-4:
- Requires services to offer at least one phishing-resistant option at authentication assurance level 2 (AAL2), and requires US federal agencies to mandate phishing-resistant authentication for their staff, contractors and partners.
- Requires phishing resistance and a non-exportable private key at AAL3, which means synced passkeys cannot be used at AAL3.
- Allows syncable authenticators at AAL2 when the sync arrangement meets specific requirements.
Workforce rollout
- Start with administrators and privileged users using device-bound credentials such as FIDO2 security keys or managed-device platform authenticators.
- Extend to high-risk groups: finance, HR, executives, developers with production access and help-desk staff.
- Roll out to everyone with platform authenticators or passkeys, then enforce phishing-resistant methods through conditional access policies.
- Remove weaker fallbacks such as SMS once coverage is high, otherwise attackers simply choose the weaker path.
Customer rollout
- Offer passkeys alongside existing methods at first; prompt enrolment after successful sign-in.
- Synced passkeys give the best usability across devices.
- Keep an account recovery path that does not reintroduce phishable weaknesses. See the Customer IAM Guide.
Enrolment and recovery
Attackers target the weakest part of the lifecycle. Recent help-desk social engineering attacks, such as those against MGM Resorts and the Co-op Group, show why.
- Bind first enrolment to strong identity proofing: an existing phishing-resistant credential, in-person verification, or verified onboarding with a temporary access pass.
- Encourage or require at least two registered authenticators so loss of one does not trigger a risky recovery.
- Make help-desk recovery for privileged users require manager approval or in-person or video verification.
- Alert on new authenticator registration followed by sign-ins from new locations or devices.
What passwordless does not solve
- Session theft after sign-in: stolen session cookies bypass authentication entirely. Combine passwordless with session binding and short sessions. See the IdP and SSO Security Guide.
- Non-human identities: service accounts, API keys and AI agents cannot use passkeys. They need workload identity and short-lived credentials. See the NHI Authentication Guide.
- Compromised endpoints: malware on an unlocked device can act as the user.
Security versus sign-in friction
Every extra step between a person and their account costs something. FIDO Alliance cites a World Passkey Day 2025 consumer study in which 48% of people said they had abandoned an online purchase because they forgot a password. The goal is not the fewest controls, but strong controls placed where they add the least friction.
- Onboarding friction: ask only for what registration needs, and offer a passkey at sign-up or straight after the first successful sign-in. The NCSC said on 23 April 2026 that passkeys should be the default for consumers and that passkey sign-in can be up to eight times faster than a username, password and two-step verification.
- Form abandonment: NIST SP 800-63B-4 requires verifiers to allow password managers and autofill, and says pasting should be allowed. Blocking these drives users to weak passwords and failed attempts. FIDO Alliance publishes deployment results such as Air New Zealand's reported 50% fall in login abandonment; treat vendor case studies as directional and measure your own funnel.
- Step-up only when risk rises: SP 800-63B-4 allows fraud indicators, such as an unexpected location, to trigger additional risk-based controls, but states that these signals do not change the authentication assurance level or replace an authenticator. Use risk signals to decide when to ask for more, not as a substitute for a phishing-resistant method. Apply step-up to sensitive actions such as changing contact details, adding a payee or exporting data.
- Keep alternatives: SP 800-63B-4 requires that alternative authenticator types are available to all subscribers and encourages at least two separate means of authentication, which also reduces recovery friction.
- Measure both sides: track completion rate, time to sign in and help desk volume alongside account takeover and recovery abuse, so a friction cut that raises fraud is visible quickly.
For signal design, see the Risk-Based and Adaptive Authentication Guide.
Practitioner checklist
- Issue device-bound phishing-resistant credentials to administrators first.
- Plan phased rollout to high-risk groups and then all users.
- Enforce phishing-resistant methods through policy and remove weaker fallbacks.
- Strengthen enrolment and recovery, especially help-desk processes.
- Require at least two authenticators per user.
- Combine with session binding, short sessions and monitoring.
- Track coverage of phishing-resistant authentication as a key metric.
Standards and references
- NIST SP 800-63B-4: Authentication and Authenticator Management
- FIDO Alliance: Passkeys
- W3C Web Authentication (WebAuthn) Level 3
- CISA: Implementing Phishing-Resistant MFA
- NIST SP 800-63B-4: Authentication and Authenticator Management
- FIDO Alliance: Passkeys
- NCSC: Leave passwords in the past, passkeys are the future (23 April 2026)
Related NHI Mgmt Group resources: Workforce Identity Security Guide · IdP and SSO Security Guide · Human vs Non-Human Identity · IAM and IGA Basics