How Should Account Recovery Be Designed for a Mobile App Using Passkeys?

Short answer

Adding passkey sign-in does not remove the need to design account recovery. Device loss, moving to another device, an accessible fallback and support intervention must be defined separately. The weakest recovery step can undermine strong authentication, so recovery also needs security and usability testing.

Sign-in and recovery are different user tasks

With passkeys, users must understand which devices and account ecosystems they can sign in from. Having no usable credential on a device does not mean they have no account in the organisation’s system. The screen must distinguish these cases and show suitable alternatives rather than force another registration. Include the new-device scenario in the product scope from the start.

The FIDO passkey approach provides public-key authentication instead of passwords. Recovery policy, however, depends on the product’s account and risk model. Do not assume that provider synchronisation or device behaviour is identical across platforms. Include supported devices, browsers and account types in the real-device test list.

Limits on the support team

Specify which information support staff can access and which decisions they can make during recovery. Do not ask users for authentication secrets or sensitive key information. For privileged accounts, address post-recovery role changes and active-session management separately. Granting account access solely on easily discoverable profile information weakens strong authentication.

Recovery events should be traceable through notifications, action records and additional approval when necessary. Instead of prescribing a universal duration or verification method, establish a policy suited to the organisation’s risk and support capacity. Explain the current stage to the user; avoid unclear messages that make them open the same request again.

Real-device acceptance testing

Test a device with a passkey, a new device without one and a lost-device scenario. After alternative sign-in, check that access is linked to the same user record. Verify expected handling of old sessions, notifications and administrator privileges during recovery. Screen-reader and keyboard testing are also part of the workflow; secure recovery that cannot be completed is not a functional product.

Implementation checklist

Are supported devices defined?
Is the new-device message distinct from an account-not-found message?
Are support verification permissions limited?
Is there a post-recovery session policy?
Are real-device and accessibility tests complete?

Frequently asked questions

Can the fallback workflow be removed after adding passkeys?

Not without evaluating users’ access scenarios. Recovery is a separate product and security decision.

Can recovery be handled solely through a support email?

An email request alone does not verify identity; a defined verification and authorisation process is required.

Scope and limitations

Verify identity-provider and platform behaviour for the specific application. This article does not claim that any particular provider supports every recovery feature.

Sources and currency

Source review: 7 October 2026. Linked document versions and provider terms may change. Check the current version of the relevant source before implementation.