Passkeys: safer sign-in needs a recovery plan too

A passkey can remove the need to type a password into a website. That makes signing in simpler, but the important ownership question remains: where is the credential stored, and how will you regain access if that device or account becomes unavailable?

Before replacing a working sign-in method, understand both ordinary sign-in and recovery. A secure front door is less useful if the only spare key is locked inside.

What happens when you sign in

A passkey uses a cryptographic credential. The service holds a public key; the authenticator uses the corresponding private key to answer a challenge. Unlocking with a device PIN or biometric check authorises its use. The website does not receive your fingerprint as the credential. FIDO distinguishes synced passkeys from device-bound passkeys. FIDO: passkeys.

WebAuthn's binding to the legitimate service helps resist phishing: a lookalike website cannot simply obtain the same reusable secret that a password form would collect. NIST recognises this mechanism as verifier-name binding. That protection concerns authentication; it does not make a compromised device or stolen active session harmless. NIST SP 800-63B-4.

Synced and device-bound mean different recovery paths

A synced passkey can become available on other supported devices through its credential provider. Recovering that provider account is therefore part of the access plan. A device-bound credential remains on its authenticator, such as a particular security key; losing it requires another registered authenticator or the service's recovery process.

The exact options depend on the website, operating system and provider. Do not assume every passkey moves to every new phone or that adding a second phone automatically creates an independent recovery route. Two devices relying on the same unavailable provider account can share a failure mode.

FIDO's discussion of moderate-assurance use cases is useful background on these deployment choices and their trade-offs. FIDO technical white paper.

A worked example: the phone is lost while travelling

Mara uses a passkey for a project service. Before travelling, she checks that she can sign in from her managed laptop and confirms whether its credential is synced or separately registered. She also records the service's recovery route and keeps any recovery codes in an approved secure place separate from the phone.

When the phone is lost, she uses the already-prepared laptop route. Through the device and account providers' supported controls, she protects the lost device, reviews sessions and removes access that should no longer remain active. Registering a replacement phone is a separate step from revoking the lost device's access.

If the laptop route depends on approving a prompt on the missing phone, it was not a tested fallback. If no usable method remains, she follows the provider's recovery process; creating a new account with a similar name does not recover the old account's rights or data.

Prepare without creating a new lockout

• List the important services and identify where each passkey is stored.
• Add an additional supported sign-in or recovery method where appropriate.
• Test the second route in a fresh sign-in session while the primary route still works.
• Confirm recovery email and phone details are current and independently accessible where possible.
• Record who manages recovery for a business account and how their authority is verified.
• Remove obsolete methods only after the replacement is proven usable.

Recovery codes are secrets. A shared onboarding document is not an appropriate place for them. An inventory can say where the protected recovery material is held without containing the material itself.

Shared computers and workplace accounts

On a shared device, avoid accidentally saving a personal credential into another person's browser profile or sync account. Use only sign-in options permitted by the organisation and understand whether a credential remains after the session. Signing out and removing a saved passkey are different actions.

When cross-device sign-in presents a QR code, initiate the process from the service you intend to use and follow the provider's documented flow. Do not approve an unsolicited request because it resembles a familiar sign-in screen. For a business service, recovery should survive an employee's departure through organisational roles rather than sharing that employee's account.

What passkeys do not solve

They do not decide whether a user should have access to a document, stop an authorised recipient copying information or replace device updates. A website may still retain password or email recovery, which affects the overall account's security. Review those remaining routes as carefully as the new credential.

The practical goal is reliable, phishing-resistant authentication with a recovery process appropriate to the account's value. See Digital account continuity for planning beyond a lost device.