Passwords fail in two ways that no amount of user training fixes. People reuse them, so a breach at one site opens accounts at another. And a password can be typed into a convincing fake page, so phishing works even against careful users. One-time codes help with the first problem and barely touch the second, because a code can be relayed by the same fake page.

Passkeys remove both failure modes by changing what the secret is and where it lives. This post explains the mechanism, the choices you need to make, and how to roll passkeys out without locking people out.

What a passkey is

A passkey is a public and private key pair created for one account on one website. The private key stays inside an authenticator: a phone, a laptop's secure hardware, a password manager or a physical security key. The website stores only the public key.

The standard behind this is WebAuthn, a W3C specification that browsers implement, working with the FIDO Alliance's CTAP protocol for talking to external authenticators. Together they are often called FIDO2. "Passkey" is the user-facing name for a WebAuthn credential that can be found without typing a username first, known in the specification as a discoverable credential.

How passkeys work

Registration

  1. The server sends a random challenge and its identity, the relying party ID, which is a domain such as example.com.
  2. The browser asks the authenticator to create a credential for that domain.
  3. The authenticator checks that the user is present, usually with a fingerprint, face or device PIN, then generates a key pair.
  4. The public key and a credential ID go back to the server, which stores them against the account.

In the browser the call looks like this:

const credential = await navigator.credentials.create({
  publicKey: {
    challenge,
    rp: { id: "example.com", name: "Example" },
    user: { id: userHandle, name: "dev@example.com", displayName: "Dev" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: {
      residentKey: "required",
      userVerification: "preferred"
    }
  }
});

Sign-in

  1. The server sends a fresh challenge.
  2. The browser finds passkeys for the current domain and the user picks one.
  3. The authenticator verifies the user locally and signs the challenge with the private key.
  4. The server verifies the signature with the stored public key.

The fingerprint or PIN never leaves the device. It allows the key to be used on the device; the server only ever sees a signature.

Why this resists phishing

The browser, not the user, decides which domain a credential belongs to. A passkey created for example.com is simply not offered on examp1e.com, and a signature produced for one origin does not verify for another. There is nothing for the user to type into the wrong page, and nothing on the server worth stealing, because a public key cannot be used to sign in.

A passkey also covers two factors in one gesture: possession of the device, plus a biometric or PIN checked on it.

Synced and device-bound passkeys

There are two kinds, and the difference matters for policy.

Synced passkeys

A synced passkey is stored in a credential manager and copied, end-to-end encrypted, to the user's other devices: a platform keychain or a third-party password manager. A new phone restores the passkeys automatically.

The benefit is that losing one device does not mean losing access. The trade-off is that the security of the passkey now includes the security of the sync account and its own recovery process.

Device-bound passkeys

A device-bound passkey never leaves the hardware that created it. Physical security keys are the usual example. It cannot be copied, which gives a stronger guarantee about where the key is, and losing the device loses the credential.

Choosing between them

  • For consumer accounts and most staff, synced passkeys are the practical default. Their recovery story is what makes adoption possible.
  • For administrators and high-privilege roles, consider requiring device-bound keys, with at least two registered per person.
  • WebAuthn reports whether a credential is eligible for backup and whether it is currently backed up, so a server can apply different rules to each kind.

A rollout plan

Passkey projects fail on logistics more often than on cryptography. A sequence that works:

  1. Offer, do not force. Add passkey creation in account settings and prompt for it straight after a successful sign-in, when the user is already authenticated.
  2. Start with a pilot group. Internal staff reveal which devices, browsers and shared workstations cause trouble.
  3. Enable autofill. With conditional mediation the browser offers a passkey in the username field, so existing sign-in pages work for both passkey and password users.
  4. Encourage a second passkey. One on the phone and one on the laptop or a security key removes most lockouts.
  5. Make passkeys the default. Once adoption is high, show the passkey option first and the password second.
  6. Retire weaker methods for groups that are ready. Begin with administrators, where the risk justifies it.

Measure the share of sign-ins using passkeys and the number of recovery requests. A spike in recovery requests means the rollout is moving faster than enrolment.

Fallback and recovery

Every account's security equals that of its weakest sign-in or recovery path. A passkey protects nothing if "forgot my passkey" sends a link to an email account guarded by a reused password.

Plan for three situations.

  • The passkey is unavailable right now. Someone is on a borrowed computer. Cross-device sign-in, where a phone approves over a QR code and a proximity check, covers many cases. Otherwise a second method is needed.
  • A device is lost. With synced passkeys the replacement device restores them. With device-bound keys the user needs the second key they registered.
  • Everything is lost. This is account recovery, and it should be slower and more heavily checked than sign-in. See account recovery without account takeover.

Two rules keep fallback from undoing the benefit. First, whatever fallback you keep should be the strongest you can support, such as an authenticator app with backup codes, and not text-message codes. Second, give users a clear list of their passkeys, with when each was last used and a way to remove one. A stolen laptop should be removable from the account in seconds.

For actions that need more assurance than the current session offers, ask again at that moment. See step-up authentication.

How AuthFI does it

AuthFI supports passkeys over WebAuthn in two roles: as a passwordless sign-in and as a second factor. On the workforce identity page they are described as the default AuthFI recommends, because there is nothing to phish.

You choose which ways in a project offers. Alongside passkeys, the options include authenticator codes from any standard authenticator app, with backup codes, and passwords with lockout after repeated failures. Passwords found in known breaches are refused. A second step is part of every plan, and an application can require the stronger sign-in.

Each person has a workspace where their passkeys, sessions and second step are theirs to manage. For customer-facing products, passkeys are one of the ways in available on the hosted sign-in page.

Key takeaways

  • A passkey is a key pair bound to one website. The private key never leaves the authenticator, and the server stores nothing that can be used to sign in.
  • Phishing resistance comes from the browser tying each credential to its domain.
  • Synced passkeys favour recoverability and device-bound passkeys favour control. Use both, by role.
  • Roll out by offering first, defaulting second and enforcing last.
  • Design fallback and recovery alongside the passkey itself, because attackers will choose the weakest path.