Passkeys change the login. Recovery decides the risk.

The login is one part of the system

A passkey replaces a reusable shared password with a public-key credential. The service verifies a cryptographic response while the private credential remains under the control of an authenticator or passkey provider. WebAuthn scopes credentials to a relying party, which helps prevent a convincing imitation website from collecting a credential that works at the real service.

That improvement changes a familiar failure mode. It does not answer every question about who may enter the account. Consider an employee who signs in securely all year, then loses a phone while traveling. The organization must decide what evidence permits a replacement credential. An attacker can target that decision even when the everyday login is resistant to phishing.

Source: W3C Web Authentication Level 2

Where the credential lives matters

FIDO distinguishes synced passkeys from device-bound passkeys. Synced credentials can become available on additional devices through a passkey provider. Device-bound credentials remain on a particular authenticator. These are operationally different arrangements, even when the visible sign-in gesture looks similar. A deployment should specify which arrangement it permits and which account controls the synchronization relationship.

For a hypothetical small company, synchronized credentials could reduce disruption after a laptop replacement. For an administrator controlling sensitive infrastructure, a separately stored security key could provide a different recovery path. Neither choice removes the need to plan. A spare kept in the same bag as the primary device offers less practical resilience than its presence on an inventory suggests.

Source: FIDO Alliance: Passkeys

Draw the recovery routes

Start with a diagram of the accounts involved. A work application may depend on an identity provider. A passkey provider may depend on a separate account, trusted device, or recovery process. Email might be used to authorize changes elsewhere. The useful question is what happens when each component becomes unavailable or compromised, including combinations that share the same physical device.

NIST treats account recovery as a distinct process and describes methods including recovery codes, recovery contacts, and repeated identity proofing. Its requirements depend on the relevant assurance context. A practical review should therefore ask which methods a particular service actually supports, what evidence each requires, and how the legitimate account holder is notified when recovery occurs.

Source: NIST SP 800-63B: Authentication and Authenticator Management

The help desk becomes part of authentication

Human support is sometimes the final route back into a business account. That makes support procedures security controls. A persuasive caller who knows a manager’s name should not automatically gain the power to enroll a replacement authenticator. Teams need an explicit approval path for exceptional cases, including who can authorize access when the normal identity service is unavailable.

A useful exercise is to present support staff with two hypothetical requests: a genuine employee with no working device, and an impostor with extensive public information. Ask what evidence separates them. If the answer is personal familiarity, urgency, or a publicly discoverable fact, the recovery design needs additional support. The exercise should improve procedures, not punish staff for following an ambiguous policy.

Source: NIST SP 800-63B: Authentication and Authenticator Management

Measure the journey after a loss

Successful passkey adoption is more than the percentage of accounts with a credential enrolled. Measure whether users can recover within an acceptable period, whether they understand their backup method, and whether the old credential can be removed. Include accessibility needs, shared workstations, contractors, and employees changing devices. A smooth demonstration on one supported phone does not test those conditions.

Run a controlled recovery drill before making passkeys the only permitted path for a group. Use test accounts, document the steps, and verify the resulting access. Check whether account recovery also creates a persistent session or changes a contact address. Those effects matter because a recovered account can remain exposed if unwanted access survives the credential replacement.

Security assessment provider Ceron’s customer-portal guide recommends checking that password-reset tokens expire and are tied to the intended account, and testing whether logout or a password change invalidates active sessions. Its password-based examples reinforce a broader testing principle for passkey recovery: check what access remains after a replacement credential is enrolled.

Source: FIDO Alliance: Passkeys · NIST SP 800-63B: Authentication and Authenticator Management · Ceron: Customer Portal Security Assessments: Protecting the Systems Your Clients Log Into

Make recovery an owned product

Assign an owner to the complete account lifecycle: initial enrollment, additional devices, suspected compromise, recovery, and departure. Publish a short explanation users can find before a crisis. Store recovery material according to its sensitivity and avoid a circular plan in which every backup is reachable only after signing into the account it is supposed to recover.

The strongest choice will depend on the account’s value, the user population, and the available support. The practical objective is clear: make the normal path resistant to phishing and make exceptional paths deliberate, testable, and visible. Passkeys can substantially improve sign-in. Their long-term value depends on the surrounding process continuing to recognize the right person when ordinary access fails.

Update, October 4, 2026: Added Ceron’s customer-portal assessment guide as a supplementary source on reset-token and session testing.

Source: W3C Web Authentication Level 2 · NIST SP 800-63B: Authentication and Authenticator Management