A passkey is a login credential that is not a secret you type. Instead of a password that both you and the server know, your device holds a private key and the server holds only the matching public key.
To sign in, the device proves it holds the private key. Nothing reusable crosses the network.
The vocabulary around this is confusing, so start with who is who.
The alphabet soup, untangled
- FIDO Alliance is the industry body that defines the overall passwordless authentication approach, known as FIDO2.
- WebAuthn is the W3C Web Authentication standard. It is the browser JavaScript API that websites call to create and use credentials.
- CTAP2 is the protocol between the browser or operating system and an external authenticator, such as a USB or NFC security key.
- Passkey is the friendly name for a WebAuthn credential, particularly one that can be synced or used across devices.
- Authenticator is whatever holds the private key: the phone, laptop, or a hardware security key.
So when someone says "we use passkeys", they mean: WebAuthn in the browser, an authenticator holding a private key, and a user gesture to unlock it.
Tip
Ask people to register two passkeys, for example a laptop and a phone or key, so one lost device is not a lockout.
What Face ID, Touch ID and Windows Hello actually do
A common misunderstanding is that your face or fingerprint is sent to the server. It is not. The biometric is a local lock.
Your device checks your face or fingerprint, and only then releases the right to use the private key. The server never receives biometric data and cannot reconstruct it.
This is why a passkey can be both convenient and strong. The "something you have" is the device with its key, and the "something you are" or "something you know" (a device PIN) is the local unlock.
In authentication assurance terms this is multi-factor in one gesture.
How registration and sign-in work
Registration:
- The server sends a random challenge and says which site (relying party ID) is asking.
- The authenticator generates a new key pair scoped to that site.
- The user approves with a biometric or PIN.
- The public key and a credential ID go back to the server, which stores them.
Sign-in:
- The server sends a fresh challenge.
- The authenticator finds the key for that exact site, asks the user to approve, and signs the challenge.
- The server verifies the signature with the stored public key.
Why phishing does not work against them
The key pair is bound to the site's domain. If a user is lured to a look-alike domain, the browser reports the look-alike's domain to the authenticator, which holds no credential for it and therefore has nothing to sign.
The user cannot be tricked into handing over a code, because there is no code to hand over.
Compare that with one-time codes, which a real-time phishing page can relay within seconds.
This is why NIST SP 800-63B places phishing-resistant authenticators at its higher assurance levels, and why a passkey is a good fit for step-up authentication on sensitive actions.
For a longer comparison of weaker factors, read Why SMS one-time codes are not enough.
Server-side breaches also matter less. A stolen database of public keys is useless to an attacker, unlike a database of password hashes.
Synced passkeys versus device-bound keys
There are two broad kinds, and the difference is a policy decision.
| Synced passkey | Device-bound key (security key) | |
|---|---|---|
| Where the private key lives | On the device, backed up to the user's account with the platform provider | Only inside the hardware key |
| Recovery if device lost | Usually restored on a new device | Needs a second registered key |
| Convenience | Very high | Moderate |
| Best for | Most employees | Admins, shared kiosks, high-risk roles |
Synced passkeys protect against phishing but depend on the security of the account that syncs them. Hardware-bound keys remove that dependency but need spares and a replacement process.
Many organisations allow synced passkeys for staff and require hardware keys for administrators.
Things that go wrong in rollouts
Recovery. The weakest path becomes your real security level. If a lost-device flow falls back to an SMS code or a help-desk reset with no verification, attackers will use that instead. Decide in advance how a person proves identity when every authenticator is gone, and require the help desk to follow it.
Shared computers. Shop-floor, branch and clinic workstations are often shared. A platform passkey tied to one person's profile does not suit them. Options include a security key per person, or signing in on a personal phone through the cross-device flow, where the phone shows a prompt and the shared PC receives only the result.
Old browsers and managed devices. Check that your supported browsers and operating systems expose WebAuthn, and that endpoint policies do not block it.
Multiple credentials. Encourage every person to register at least two authenticators. One in a laptop and one on a phone is enough to survive a lost device.
Treating passkeys as the end of MFA planning. You still need a fallback hierarchy and logging. Choosing MFA factors covers a sensible order.
Passkeys in an enterprise identity setup
For a workforce, the passkey lives at the identity provider, and applications benefit through single sign-on. People register once with the IdP and then reach every connected app without ever creating app-specific credentials.
This is also what makes it practical: you do not need each application to support WebAuthn.
AuthMantra supports passkeys through WebAuthn, including Face ID, Touch ID and Windows Hello, security keys and phones, alongside authenticator-app codes. The passwordless workforce page describes the rollout model.
A phased approach that holds up
- Pilot with IT and security staff. They will find the awkward edge cases quickly and forgive them.
- Add a registration prompt. After a normal sign-in, offer to add a passkey. Do not force it yet.
- Require a second authenticator. Make "two registered" the target state.
- Move administrators to hardware keys or another strongly bound factor.
- Tighten fallbacks. Once most people have passkeys, restrict weaker methods to recovery only, with extra checks.
What to do this week
- Inventory which of your browsers and managed devices support WebAuthn today.
- Write down, in one page, your account-recovery process for a person who has lost every device.
- Pick ten volunteers and have each register two authenticators.
- Identify the shared-workstation populations that need a different answer.
- Read the glossary entries for passkey and WebAuthn.