Passkeys are easy. Account recovery is the hard part

Passkeys have moved from pilot project to default recommendation. The FIDO Alliance estimates 5 billion passkeys are now in use worldwide, 75% of people have enabled one on at least one account, and 68% of organizations have deployed or are actively deploying them for employee sign-in. When a client asks whether their next application should support passkeys, the honest answer is yes, and it has been yes for two years.

Then the project starts. The login form turns out to be the easy part. Registration is one JavaScript call, a challenge stored server-side, and a row in a credentials table. The trouble arrives three weeks after launch, when the first user loses a phone in an airport and your help desk has no safe way to let them back in. That is the problem this article is about, because it is the one that decides whether a passkey rollout survives its first quarter.

What a passkey actually is

A passkey is a FIDO2 credential managed by WebAuthn. On registration the user's device generates an asymmetric key pair, keeps the private half inside a secure element or an OS keychain, and hands your server the public half plus a credential ID. To sign in, the server sends a random challenge, the authenticator signs it with the private key, and the server verifies the signature against the stored public key.

Three properties follow from that design and they explain most of the operational benefit.

• The private key never leaves the authenticator, so there is no shared secret for a server breach to expose and no password hash database to crack.
• The credential is bound to a relying party ID, which is the domain you registered it for. An authenticator will not sign a challenge for techhubservices.ca if the browser page came from techhubservices.ca.evil.example. Phishing pages cannot use what they cannot reach.
• The signature is over a server-generated challenge, so a captured assertion cannot be replayed on a later login.

Microsoft's position on the effect is well known: phishing-resistant methods such as FIDO credentials block more than 99% of the identity attacks it tracks. The FIDO Alliance's 2026 Passkey Index puts sign-in success at 93% for passkeys against 78% for passwords and traditional MFA across 15 large consumer services, with passkeys now carrying 36% of successful sign-ins on those services, up from 26% a year earlier.

Where rollouts break: the recovery path

Ask any identity team that has run a deployment what nearly stopped it, and the answer is device loss. A user who enrolled one passkey on one phone, then replaced that phone, has no credential the server will accept. If your only recovery path is "reset the password by email", you have reinstalled the exact weakness passkeys were meant to remove. An attacker who can take over the mailbox can take over the account, and the FIDO credential becomes a decoration.

The inverse mistake is just as common. Teams build a recovery flow so frictionless that it becomes the cheapest way in. A support agent who will read a one-time code to anyone who quotes an employee ID and a date of birth has built a social engineering channel with a friendly voice. Recovery is authentication with lower assurance, so it needs at least as much thought as the front door.

Rules that keep recovery from becoming the hole

• Recovery must not be faster or easier than a normal sign-in. If resetting takes 30 seconds and signing in takes 10, users will reset on purpose and attackers will follow them.
• Recovery assurance should scale with account value. A newsletter account can recover by email re-verification. An administrator account with production access should need a second enrolled device, an IT-issued temporary access pass, or a verified call with a manager.
• Every recovery is a security event. Log who approved it, from where, and against which user, then notify the account owner on a channel the recovering party does not control.
• Put a cooling-off window on high-risk actions after recovery. A twelve-hour hold on payout changes, new API keys, or mailbox export rules costs a legitimate user a few hours and costs an attacker the whole attack.

Design the credential inventory, not just the login button

Users accumulate authenticators. A work laptop with Windows Hello, a phone with a synced passkey, a hardware key on the keyring. Your schema needs to model that from day one, because retrofitting a one-credential-per-user assumption later means a migration under load.

A workable credentials table stores, per row: the credential ID (base64url, indexed), the public key in COSE format, the signature counter, the transports the authenticator reported, the AAGUID, a user-facing label such as "iPhone 15, added 4 Nov", creation time, last-used time, and the backup-eligibility flag. Expect several rows per user. Cap enrollment at a sensible number, ten is generous, so a compromised session cannot quietly register a permanent back door alongside the real devices.

The WebAuthn settings that cause trouble in production

• rpId must be the registrable domain or a suffix of it. A page on login.example.com can set example.com, but a page on example.com cannot set login.example.com. IP addresses are rejected, ports are ignored, and localhost is the development exception. Get this wrong and every browser fails the ceremony with a security error that tells the user nothing.
• residentKey set to required creates a discoverable credential, which is what allows usernameless sign-in. Without it you must ask for an email first, so the user is back to typing an identifier before the passkey prompt appears.
• userVerification set to required forces biometric or PIN at the authenticator. That is the right default for anything holding business data, and it is what makes the credential count as multi-factor on its own.
• excludeCredentials prevents the same authenticator from registering twice for one account. Without it, users create duplicate rows, then wonder why two of the four listed devices are the same phone.
• Conditional UI, meaning mediation: "conditional" with an autocomplete token of webauthn on the username field, puts passkeys into the browser's autofill dropdown. It is the single largest adoption lever available and it takes an afternoon.
• Signature counters lie. Most synced passkeys always report zero, so treat zero as "not supported" rather than as evidence of a cloned authenticator.
• Attestation is mostly noise for consumer sign-up. Skip it unless you are running a workforce deployment that needs AAGUID allowlists for approved hardware keys, and know that many platforms return none anyway.

WebAuthn Level 3 became a W3C Recommendation in August 2026, which matters less for new features than for stability. The pieces teams actually use, JSON serialization helpers for the options objects, client capability detection, and related origin requests for a set of sibling domains, are now on a settled footing rather than a moving draft.

Synced or device-bound is a policy decision

A synced passkey lives in a platform keychain and follows the user across their devices through iCloud Keychain, Google Password Manager, or a third-party manager. It survives a lost phone, which is precisely why consumer adoption moved so fast. The trade-off is that the credential's security now depends on the security of the user's cloud account, and the private key exists on more than one device by design.

A device-bound credential, including hardware security keys, cannot be copied off the device. That is the right choice for administrators, finance approvers, and anyone whose account can move money or change access rules. Many organizations run both: synced passkeys for the general workforce, hardware keys for privileged tiers. The FIDO Alliance reports that 57% of organizations still rely on phishable methods for employees' primary day-to-day sign-in, which suggests most deployments are running these two policies by accident rather than by design.

Cross-device sign-in is a support cost, so plan for it

The hybrid transport, the QR-code flow where a desktop browser borrows the phone's authenticator, works well when it works. It needs Bluetooth on both ends, a camera the browser can reach, and a user who understands that the QR code is not a link to click. On a locked-down virtual desktop the platform authenticator may live on the host rather than the session, so the prompt appears where the user is not looking. Test sign-in on the machines your staff actually use: a managed Windows laptop, a Mac, a Linux desktop, an iPhone, an Android phone, and whatever remote desktop product your finance team insists on.

Expect a small population that cannot enroll at all. Very old browsers, some Linux configurations without a platform authenticator, and locked-down kiosks are the usual suspects. Give them a hardware key or an IT-issued temporary access pass with a short expiry, not a permanent password exemption that nobody reviews.

A rollout sequence that holds up

Phase one adds passkeys as an option and leaves passwords in place. Instrument enrollment from the first day: prompt after a successful login, explain the benefit in one sentence, and show the passkey in the account settings list with a label the user recognizes. Phase two makes passkeys mandatory for administrators, finance, and anyone with production access, with hardware keys where policy requires it. Phase three retires SMS one-time codes as a fallback, because SMS is phishable and vulnerable to SIM swap, and replaces them with temporary access passes and a documented recovery procedure. Phase four is the one most teams skip: review the data and decide whether the remaining password path is a supported feature or a migration stage with an end date.

The FIDO Alliance's 2026 workforce data gives a reasonable set of expectations for that review. Organizations that deployed passkeys report fewer password reset tickets (35%), reduced phishing incidents (32%), faster employee logins (45%), and improved confidence in their security posture (47%). Those are self-reported numbers from 1,400 decision-makers, so treat them as directional rather than guaranteed, but the direction is consistent across every deployment write-up published in the last two years.

What to measure after launch

• Enrollment rate by cohort. A flat line usually means the prompt is buried or the copy is unclear, not that users dislike passkeys.
• Sign-in success rate per browser and platform. A single platform sitting at 60% is a bug in your options, not a user education problem.
• Recovery attempts per thousand users per month, and the share that required manual approval. Rising manual approvals mean the self-service path is failing.
• Time from first prompt to enrolled credential. Long tails point at a confusing cross-device step.
• Help desk ticket mix before and after. Password reset volume should fall while "I cannot sign in on this device" tickets rise briefly, then settle.

Passkeys are the rare security control that users prefer once they have used it, and the cryptography is no longer the risk. The risk sits in the flows around it: how a user adds a second device, how support verifies a stranger on the phone, how quickly a recovery can be abused. Build those before you ship the login button, and the rollout will look unremarkable to everyone outside the identity team. That is the outcome worth aiming for.