Passkey Recovery Design for a Lost Device

A passkey recovery design needs to distinguish a lost device from a lost credential. A synced passkey may remain available through its credential manager; a device-bound credential can require another sign-in or recovery route.

For a service implementing passkeys, the account-management problem starts before a phone disappears. The product needs to explain available credentials, establish a recovery method and make the outcome of removing a credential clear.

Google’s passkey user-journey guidance recommends establishing recovery when creating a new account with passkeys. This article examines the implications for product and implementation teams, rather than providing a phone-specific recovery walkthrough.

A device is not always the unit of access

It is tempting to label a passkey “the one on your phone.” That label can mislead if the credential is synchronised and usable in several environments.

Google’s supported-environments documentation describes passkeys managed and synchronised by password managers. For Google Password Manager, accessing a synced credential in a new environment requires the Google account and the relevant screen lock or Password Manager PIN.

That describes a particular provider’s access conditions. It does not establish that every passkey, browser profile or security key uses the same recovery route.

A service should therefore avoid promising that replacing a phone always restores access automatically. The relevant questions are where the credential was stored, whether it was synchronised, and whether the user can access that provider in another environment.

Separate the three recovery situations

Consider three illustrative cases.

These are design cases, not a claim that a specific provider offers every option.

Cross-device authentication is another distinction. Google’s documentation describes using a nearby device to approve a sign-in. A flow that requires the original phone cannot solve the case in which that phone is unavailable.

Likewise, creating multiple passkeys and synchronising one passkey are not identical. The user may have several independent credentials, or the same credential available through a manager on several devices. An account-settings page should not blur those relationships.

Make credential management understandable

Google’s user-journey guidance recommends showing the source of each passkey and distinguishing multiple passkeys in the same ecosystem. That helps users identify what they can manage.

For an implementation team, a label should describe what the service actually knows. A provider name can be useful when available, but a guess about the precise device or storage location can create false confidence.

The decision to remove a credential also needs a clear consequence. Google’s guidance explains that a relying party can remove the public-key record from its server without deleting the corresponding private key from the user’s credential manager.

In other words, server-side revocation and removal from the manager are separate operations. After revocation, the service should no longer accept that credential for the account, even if it remains visible in the manager.

The interface can use the plain term “delete,” as Google recommends, while its help text explains the scope of the action. A user should not have to understand every cryptographic detail to learn what has been removed.

Recovery deserves its own risk review

Google lists email, phone and social sign-in among possible recovery methods, with the choice depending on the application and its security requirements. These are options in the guidance, not a declaration that each is appropriate for every service.

The team must decide what evidence is sufficient to recover the account and which actions the recovered session can perform. A low-impact account and one controlling sensitive operations may require different policies.

A useful implementation review follows the entire route: the user requests recovery, the service verifies evidence, access is restored, credentials are reviewed, and a new passkey can be created. This is an analytical process map, not a prescribed protocol.

Do not claim that passkey-based sign-in makes every fallback phishing-resistant. The protection supplied by an authentication mechanism does not automatically describe a separate recovery method.

Restore a usable credential after recovery

The Google guidance identifies successful recovery as a good time to invite a user to create a passkey. It also recommends providing another opportunity when passkey creation is cancelled or unsuccessful.

For the product team, restored access and successfully created credentials are distinct states. A successful recovery message should not claim that a new passkey exists before creation has actually completed.

A cancelled platform dialog should leave a coherent next step, such as returning to account security settings. The user should be able to distinguish “you are signed in” from “this device now has a passkey.”

If the account offers multiple credentials, the management view can help the user review what remains. The product should explain removal accurately rather than assume that revoking a record also wipes a lost device.

Review the design with unavailable-device cases

A passkey rollout should be evaluated against more than the happy path. Google’s guidance recommends testing the user experience early and frequently.

Useful cases for an implementation review include a missing original phone, a credential manager the user cannot unlock, an available second credential, a cancelled creation dialog and a server-revoked credential still listed in the manager. These are suggested review cases, not tests performed for this article.

The service should also inspect its wording. “Use your old phone” is not an answer to a lost-phone flow, and “delete from account” should not imply deletion from every storage provider.

The same boundary question appears in MCP authorization: a product must define which access it grants and how that access can be revoked.

The objective is to make the access route and its limits visible. A passkey can improve sign-in while the surrounding account design still needs explicit decisions about recovery and revocation.

Reporting & Sources

Google for Developers, Passkeys user journeys, updated September 16, 2025, and Passkey support on Android and Chrome, consulted October 7, 2026. The workflow examples are implementation analysis, not a report of hands-on testing.