Most organizations are ready to start using passkeys, but very few should try to go fully passwordless in one step. A passkey replaces a password with a key pair: the private key stays with the user, and the server only ever stores a public key. That removes the shared secret that gets stolen, reused and replayed. The real enterprise questions are which type of passkey to allow for which users, how people recover when they lose a device, and what to do about shared machines.

What is a passkey?

A passkey is a sign-in credential built on FIDO Alliance and W3C standards. When a user registers, their device generates a new public-private key pair for that specific website or application. The public key goes to the server. The private key stays with the user, protected by the device's screen lock, whether that's a fingerprint, a face scan or a PIN.

To sign in, the server sends a random challenge. The user unlocks their device, the device signs the challenge with the private key, and the server checks the signature against the public key it stored. No reusable secret ever crosses the network.

How FIDO2 and WebAuthn fit together

"FIDO2" is the umbrella name for two specifications:

  • WebAuthn (Web Authentication) is a W3C standard. It defines the API that browsers and apps use to create and use credentials, and what the server, called the relying party, has to verify.
  • CTAP (Client to Authenticator Protocol) comes from the FIDO Alliance. It defines how a browser or operating system talks to an authenticator, including external security keys over USB, NFC or Bluetooth.

"Passkey" is the friendlier name the industry adopted for these credentials. In May 2022, Apple, Google and Microsoft publicly committed to expanding support for the FIDO standard across their platforms, and passkeys now work in current versions of the mainstream operating systems and browsers.

Why passkeys resist credential theft

Three properties matter most to a security team:

  1. No shared secret. A leaked database of public keys gives nobody a way to sign in.
  2. Scoped to one service. Each passkey is bound to the domain it was registered for, and the browser enforces that. A passkey created for one service can't be presented to another.
  3. Fresh challenge every time. Each sign-in signs a new random challenge, so a captured response is useless for a later attempt.

Put together, password reuse and credential stuffing stop working against passkey-protected accounts. One limit: passkeys protect the sign-in, not the session that follows. Session token theft still needs its own controls, such as sensible session lifetimes and re-authentication before sensitive actions.

Synced vs. device-bound passkeys: what's the difference?

This is the decision that shapes most of an enterprise rollout.

Synced passkeys are backed up and synchronized through a platform credential manager or a password manager. A passkey created on a phone appears on the user's other devices signed in to the same account. Lose the phone and the passkey survives.

Device-bound passkeys never leave the hardware that created them. In practice that usually means a FIDO security key. Lose the key and that passkey is gone.

Synced passkeys Device-bound passkeys
Where the private key lives Encrypted in a cloud-backed credential manager, copied to the user's devices On one piece of hardware, not exportable
Recovery after device loss Built in, through the sync account Needs a second registered authenticator or a re-enrollment process
Attestation Generally not available Available, typically from security keys
Cost and logistics Low, uses devices people already have Hardware to buy, ship, track and replace
Best fit Most workforce users Administrators and other high-risk roles

What NIST says about syncable authenticators

In April 2024, NIST published a supplement to SP 800-63B titled Incorporating Syncable Authenticators into NIST SP 800-63B. It gives interim guidance on using synced passkeys in both enterprise and public-facing systems. The main points:

  • Syncable authenticators deployed under the supplement's requirements can meet AAL2. They are not treated as meeting AAL3.
  • Private keys held in a sync service must be stored encrypted, protected so only the authenticated user can reach them, and guarded by AAL2-equivalent multi-factor authentication.
  • For enterprise use cases, agencies should use attestation based on what their platform providers offer.
  • WebAuthn's backup eligibility flag lets a relying party tell whether a credential can be synced, which gives you a way to accept only device-bound credentials for certain accounts.

It's written for U.S. federal agencies, but it's a sensible benchmark for anyone: synced passkeys are a large step up for general staff, and the highest-assurance accounts still call for device-bound authenticators.

What is attestation, and why does it matter for admins?

When a passkey is created, the authenticator can include an attestation statement. This is a signed claim about what kind of authenticator generated the key. The server can check the signature against the manufacturer's certificates, commonly using the FIDO Metadata Service, and identify the authenticator model through its AAGUID. That lets you confirm a key is hardware-backed, limit sensitive accounts to approved models, and keep an auditable record of which authenticator belongs to which privileged account.

Synced passkeys generally don't provide attestation, and that's partly by design. The credential moves between devices, so a statement about the device that created it says little about where the key lives now. For most users that's an acceptable trade. For accounts that can change identity provider settings, reset other people's credentials or administer cloud tenants, it isn't.

What we recommend for privileged accounts:

  • Require device-bound passkeys on FIDO security keys for every admin and privileged account.
  • Enforce attestation and allow only approved authenticator models.
  • Issue two keys per admin, register both at the same time, and store the backup key separately.
  • Keep admin identities separate from everyday accounts. The daily account can use a synced passkey while the admin account uses hardware.

How do you handle account recovery with passkeys?

Recovery is where passwordless projects most often give back their security gains. If someone who loses their passkey can get back in with a password and a text message code, the account is only as strong as that fallback.

Design recovery before you roll anything out:

  • Register more than one authenticator. Require at least two per user where you can, such as a synced passkey plus a security key, or two security keys for admins. Losing one then becomes an inconvenience rather than a recovery event.
  • Treat the sync account as part of your security. For synced passkeys, the platform account is the recovery path. Where you manage those accounts, apply the same MFA standards you apply everywhere else.
  • Verify identity before re-enrollment. When someone needs a new credential, use a defined process: an in-person check against photo ID, a live video check against HR records, or manager approval plus a callback to a number already on file. Then issue a short-lived, single-use enrollment code, never a new password.
  • Retire the password. Once a user has passkeys, disable their password, or set it to a long random value they never see, where your identity provider allows it. A password that still works is still a way in.
  • Alert on credential changes. A new passkey registration or a removed authenticator is a security event. Send it to your monitoring and notify the user through a separate channel.

What about shared and kiosk devices?

Passkeys assume a device belongs to one person. Shared workstations, warehouse terminals, clinical carts and retail tills break that assumption.

  • Roaming security keys. Each worker carries a personal FIDO key (USB or NFC) and uses it on whichever shared device they sit at. This is usually the cleanest answer.
  • Cross-device sign-in with a phone. WebAuthn's hybrid flow lets a user scan a QR code on the shared device and approve with the passkey on their phone. It relies on Bluetooth to confirm the phone is physically nearby, so it suits environments where phones are allowed and Bluetooth is on.
  • No platform passkeys on shared machines. A passkey saved to a shared device's built-in authenticator or browser profile can be used by anyone who can unlock that device.
  • Short sessions. Enforce automatic sign-out and short session lifetimes, and clear browser state between users.

Where none of these fit, such as sites with USB ports disabled and no phones allowed, document an exception with compensating controls rather than stalling the program.

How to roll out passkeys in phases

A phased rollout lets you find the friction points while the blast radius is small.

Phase 1: Assess and decide

  • List which applications sign in through your identity provider (IdP) and which keep their own passwords. A passkey at the IdP covers everything federated behind it. Apps outside single sign-on are a separate job.
  • Check operating system and browser versions, USB and NFC availability, and whether Bluetooth is enabled.
  • Confirm your IdP can tell synced from device-bound credentials, enforce attestation, require user verification, and apply policy by group.
  • Write down who gets synced passkeys, who needs device-bound keys, and exactly how recovery works.

Phase 2: Start with IT and administrators

Issue security keys to IT staff and privileged users first, with attestation enforced. These accounts have the most to gain, and their owners are best placed to find rough edges.

Phase 3: Pilot with a representative group

Choose users across departments, operating systems and work locations, including one team that uses shared devices. Offer passkeys alongside existing methods and track enrollment, failed sign-ins and help desk tickets.

Phase 4: Roll out broadly

Add passkey registration to onboarding and prompt existing users at sign-in. Publish short, platform-specific guidance, and answer "what happens when I get a new phone?" up front.

Phase 5: Enforce and retire weaker methods

Require passkeys through sign-in policy, then remove SMS and voice codes, then passwords wherever your IdP allows it. Announce dates in advance and handle exceptions explicitly. Until the weaker methods are gone, they remain the way around your passkeys.

Frequently asked questions

Are synced passkeys secure enough for business use?

For most staff, yes. They remove passwords and replayable one-time codes, and NIST's supplement recognizes them at AAL2 when the sync service is properly protected.

Do passkeys replace multi-factor authentication?

A passkey used with user verification combines something you have (the device or key holding the private key) with something you are or know (the biometric or PIN that unlocks it). That means it can satisfy MFA requirements on its own. Make sure your IdP policy requires user verification rather than just a tap.

What happens to passkeys when an employee leaves?

Disable the account and delete the registered credentials in your IdP. A synced copy may remain in the person's credential manager, but it's useless once the server no longer accepts it. Collect issued security keys, reset them, and reissue them.

Key takeaways

  • Passkeys stop password reuse, credential stuffing and database theft from turning into sign-ins, but they don't protect sessions afterward.
  • Use synced passkeys for general staff and attested, device-bound security keys for admins.
  • Design recovery first. A weak fallback cancels out a strong primary method.
  • Plan shared devices around roaming security keys or cross-device sign-in.
  • Roll out in phases, starting with IT, and finish by removing SMS codes and passwords.