A passkey is a FIDO credential that replaces a password with a cryptographic key pair, approved the same way you unlock your device, for example with a biometric or a PIN. FIDO2 is the set of standards behind it, made of WebAuthn and CTAP. The key point is that each key is tied to the service that created it, so a fake website cannot reuse it. This article builds on which MFA is safer, and its companion covers rolling out passkeys in the enterprise.

Why passwords and one-time codes fall short

A password is a secret that the user and the server both know, so whoever obtains it can use it. CISA describes a widely used technique: an email lures the user to a site that mimics the real login page, and the user enters the username, the password, and the 6-digit code from an authenticator app, all of which the attacker can reuse. CISA notes that some forms of MFA remain vulnerable to phishing, push bombing, SS7 protocol weaknesses and SIM swapping, and it ranks phishing-resistant MFA as the strongest form. NIST SP 800-63B-4 says something similar: authenticators that involve manually typing a value, such as OTP, are not considered phishing-resistant because the value is not bound to the session being authenticated.

How passkeys work

Passkeys use public-key cryptography. At registration, the device creates a key pair for that specific service. The server stores only the public key, while the private key stays on the device or security key. At sign-in, the server sends a challenge, the user unlocks the device to approve, the device signs the challenge with the private key, and the server checks the signature with the public key. Because there is no shared secret to steal from the server, a breach of the user database does not expose passkeys.

INFOGRAPHIC
From registration to sign-in in four steps
1
Register
makes a per-service key pair, shares the public key
2
Receive challenge
server sends a one-time challenge
3
Unlock and sign
approve with PIN or biometric, then sign
4
Verify
server checks with the public key and opens a session

The WebAuthn specification lets a credential be accessed only by origins that belong to the relying party it is scoped to (the site or service where the user registered), and the browser and authenticator enforce this together. Users no longer have to rely on spotting a fake page, because the passkey for the real service will not work on another site.

INFOGRAPHIC
Passwords versus passkeys: where they differ

Traditional passwords

  • Shared secretuser and server know the same value
  • Phishabletyped on a fake site, then reused
  • Reusableone leak puts many systems at risk

Passkeys

  • Key pair per serviceno single value works across services
  • Bound to real domaina fake site cannot use the passkey
  • Server holds public key onlyno secret to steal from the server

If the current computer has no passkey, the user can still sign in with a passkey on another device, for example by scanning a QR code with a phone to sign in on a laptop. This uses the hybrid transport in CTAP, which relies on Bluetooth Low Energy to confirm that the two devices are physically close.

INFOGRAPHIC
Cross-device sign-in with a QR code
01
Laptop
shows a QR code
02
Phone
scans the QR code
03
Proximity check
BLE confirms closeness
04
Approve
unlock and sign

FIDO2, WebAuthn, CTAP and passkey: how the terms fit

These terms are often mixed up. This is how they relate to each other.

  • FIDO2: the set of standards that combines WebAuthn and CTAP
  • WebAuthn: the browser API that websites call, published by the W3C. WebAuthn Level 3 became a W3C Recommendation on 25 August 2026
  • CTAP (Client to Authenticator Protocol): the protocol that lets external authenticators, such as a security key or a phone, talk to the device over USB, NFC or BLE
  • Passkey: the term the FIDO Alliance uses for a passwordless FIDO credential, covering both synced and device-bound types
  • Authenticator: the component that holds the private key and signs. It can be built into a laptop or phone (platform authenticator) or be a separate device such as a USB security key (roaming authenticator)
INFOGRAPHIC
Who does what in FIDO2
FIDO2
WebAuthn plus CTAP
WebAuthn
website talks to browser
CTAP
device talks to external authenticator
Authenticator
holds the private key and signs
Passkey
the credential users see and use

Synced and device-bound passkeys

The FIDO Alliance splits passkeys into two kinds by where the key lives. Both resist phishing, but they differ in recovery and lifecycle control.

  • Synced passkeys: backed up and usable across devices registered with the same passkey provider, through a cloud service. They are easier to recover after losing a device, but part of their security depends on the provider and the account used for syncing, which may not meet every organization's requirements
  • Device-bound passkeys: stay on the device that created them and cannot be exported, for example a passkey on a hardware security key. They give better lifecycle control, but if lost you need a backup key or an organization-defined recovery process

In its enterprise guidance, the FIDO Alliance maps the types to assurance levels. For low assurance, both are sufficient. For moderate assurance, device-bound is sufficient and synced may be. For high assurance, device-bound may be sufficient depending on the authenticator and requirements such as FIPS 140, while synced is not.

Passkeys and NIST SP 800-63B

NIST SP 800-63B-4 was published in final form in July 2025 and supersedes the 2020 edition. It is written for US federal systems, but many organizations use it as a reference benchmark. It defines three authenticator assurance levels (AAL). These are the points that matter for passkeys.

  • AAL2: verifiers must offer at least one phishing-resistant option and should encourage its use wherever practical
  • AAL3: requires a phishing-resistant authenticator with a non-exportable key, so syncable authenticators cannot be used at AAL3
  • Syncable authenticators: Appendix B says they may be offered as an option for applications aiming for up to AAL2, subject to requirements, for example synced keys must be stored only in encrypted form and access to them must be protected by AAL2-equivalent MFA
  • OTP and SMS codes: not considered phishing-resistant, because the user types the value manually

Common mistakes

  • Treating all passkeys as equal: synced and device-bound differ in recovery and assurance level. Match the type to the risk of each user group
  • Forgetting recovery design: account recovery is a common attack target. FIDO advises that recovery should never rely on a weaker factor than the credential being recovered
  • Keeping passwords as a permanent fallback: FIDO notes that if recovery still depends on an active password, the benefit of passkeys is reduced. Treat it as a transition state, not a permanent one
  • Using platform passkeys on shared computers: other users of the machine can reach the credential. FIDO suggests hardware keys instead, with a backup key
  • Expecting passkeys to fix everything: they protect the sign-in step against phishing and password reuse, but they do not replace endpoint protection or access control

Start today

  • Check whether your core systems support passkeys: SSO, email, VPN and key SaaS. CISA notes that most hosted email and SSO services support FIDO, which makes them a good starting point
  • Try it with the IT team first to see the real user experience and the gaps in account recovery
  • Identify the highest-risk accounts, such as administrators and executives, and put them in the first group
  • Register more than one authenticator per person, such as a backup security key, because a device-bound passkey cannot be recovered on its own
  • Plan the organization-wide rollout using the steps in rolling out passkeys in the enterprise. Passkeys are part of the identity pillar in Zero Trust Architecture and one of the measures that reduce ransomware risk

To see where your organization's authentication stands against good practice, try the self-assessment.

References and further reading