Passwordless authentication lets a user sign in without typing a shared secret. Most modern versions use a public key credential, such as a passkey or security key, unlocked by a fingerprint, face scan or device PIN. The private key never leaves the device, which is why it resists phishing and credential theft.
How does it work?
The web standard behind it is WebAuthn, from the W3C. It describes strong, attested, scoped, public key based credentials. When a user registers, their authenticator creates a key pair. The service stores the public key. Each credential is scoped to a given relying party, meaning the website that asked for it.
At sign-in, the service sends a challenge, the authenticator signs it after the user confirms with a biometric or PIN, and the service checks the signature. The biometric or PIN only unlocks the key on the device. It is not sent to the service.
Why does it resist phishing?
Because the credential is bound to the site that created it. A fake page on another domain asks the authenticator for a credential it does not have, so there is nothing to hand over. A password can be typed into any page that looks right. A code from an authenticator app can be relayed by an attacker in real time. A scoped key cannot.
CISA's guidance for small businesses makes the same point: any form of multi-factor authentication raises the cost of attack, but the one widely available phishing-resistant option it names is FIDO authentication, which blocks attempts on imposter sites and is built into the browsers and phones people already use.
What does NIST say about assurance levels?
NIST SP 800-63B-4 defines authentication assurance levels. At the highest, AAL3, the authenticator must have a non-exportable private key and provide phishing resistance. It also states that syncable authenticators, where the private key can be copied between devices through a cloud account, shall not be used at AAL3. A passkey synced across your devices is convenient and strong against phishing, but it is a different risk from a hardware-bound key. The same publication notes that verifiers may use flags to tell device-bound from syncable credentials and set policy on them.
Where can passwordless still fail?
Three places come up often. Account recovery: if a stolen email address or a help desk call can reset the account, attackers will use that instead. Session theft: a stolen session cookie bypasses sign-in entirely, and NIST's revision added guidance on session management and device-bound session credentials for this reason. Enrollment: an attacker who can register their own passkey on a hijacked account keeps access.
Passwordless also does not fix authorization. A user who signs in cleanly can still be granted too much.
A constructed example
A 40-person agency moves to passkeys for its email and code hosting accounts. Staff register a passkey on their phone and a hardware key as backup. Admins use hardware keys only. The agency also changes its recovery process: a lost device requires a second admin to approve, with a delay, and a notification to the user. Six months later a phishing email reaches several staff. The fake login page cannot obtain a usable credential, and nobody has a password to reset. The recovery rule, not the passkey, is now the weakest part, so the team reviews it quarterly.
How to check or apply this
- List the accounts that matter most: email, identity provider, source control, cloud console, finance.
- Enable passkeys or security keys on those first, with a second registered authenticator per user.
- Use device-bound hardware keys for administrators and break-glass accounts.
- Rewrite recovery so it is as strong as sign-in: no email-only reset, approvals for privileged accounts, user notifications.
- Shorten and monitor sessions for sensitive apps, and revoke sessions on credential changes.
- Keep a fallback method only where you must, and track its usage so you can remove it.
Quick check
Is a passkey the same as passwordless?
A passkey is one kind of passwordless credential, a discoverable public key credential that may sync across devices. Passwordless also includes hardware security keys and device-bound credentials.
What if the user loses their phone?
They need a second registered authenticator or a defined recovery process. Plan this before rollout, because recovery is where attackers look next.
Sources
- W3C Web Authentication Level 3
- NIST SP 800-63B-4, Authentication and Authenticator Management
- CISA, Cyber Guidance for Small Businesses
Last reviewed: 18 October 2026.
