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.
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
Related NHI Mgmt Group resources: Workforce Identity Security Guide · IdP and SSO Security Guide · Human vs Non-Human Identity · IAM and IGA Basics
