INTRODUCTION
A sign-in demo usually ends at the pleasant moment: the device recognises its owner, the account opens, and nobody types a password. The more revealing demo starts a day later, with a missing phone and a person who needs something urgently. What does the product let them do now?
Passkeys can make the front door easier to use. The design work still includes the way back in. For a product team, that means treating recovery as a journey with its own decisions, explanations and finish line. A small “Try another way” link cannot carry an undefined operating policy.
Separate the missing device from the missing account
FIDO Alliance’s January 2024 consumer deployment paper explains that synced passkeys can remain available across supported devices. Losing access to the passkey provider can still require another route. A device-bound passkey has different backup needs. The practical question is therefore what access remains, rather than simply whether the phone is missing.
That distinction belongs in the first recovery conversation. Someone with another working sign-in method needs a short route back to the product. Someone with none needs a different process. Asking both people the same long series of questions wastes the first person’s time and gives the second person false expectations.
Write the policy before polishing the screen
Consider a hypothetical client portal containing project files. A customer replaces a damaged phone and can no longer sign in. The team has drawn an attractive recovery screen, but nobody has decided whether support can restore access, what evidence it can accept, or who can resolve an uncertain case.
The interface has reached the edge of an organisational decision. Adding reassuring copy will not complete it. Write down who owns the case, what the customer can expect next, and how the team will communicate a delay. The security team should determine the verification rules; the product team must make those rules understandable.
Put that policy through an awkward example. What happens when the customer contacts support from a new email address? What happens outside support hours? A useful design review follows one case until the person can either return safely or understand why the process cannot continue. Stopping at “Request received” leaves the difficult work invisible.
Make the alternatives distinguishable
A recovery page should help someone choose a relevant action without asking them to understand authentication architecture. Describe the situation each route serves. Avoid a row of equally prominent buttons whose names make sense only to the implementation team.
Keep language consistent between sign-in, account settings and support. If settings call something a passkey, a recovery page that suddenly calls it a security credential creates an extra puzzle. The wording should also say when an action opens another service or requires a device the person must have nearby.
There is a real tradeoff here. Listing every possible route can overwhelm a worried user; hiding all alternatives behind one vague link can strand them. Start with the most likely situation, then make the remaining routes discoverable. Test the choice with someone who has not watched the successful sign-in demo.
Treat recovery as a security boundary
FIDO’s recovery guidance, published on 6 February 2019, makes recovery part of the authentication design. A convenient fallback can undermine the assurance of the main method. The choice of evidence therefore needs a deliberate policy.
For the interface, the consequence is straightforward: never promise instant restoration when a review may be required. Show the next step and the expected communication channel. Explain any restrictions in useful language. A customer who knows what is happening has less reason to submit repeated requests or improvise through unrelated support channels.
Test the return, including what comes after it
Run a tabletop rehearsal with design, support and security. Use three fictional situations: another device still works; no sign-in method works; the person is uncertain which account they used. Ask each participant to point to the next action using only the screen and the stated policy.
Then continue after access is restored. Can the customer review how they sign in? Can they understand which old access method needs attention? Does the confirmation clearly distinguish successful recovery from a request that is still being considered? These are product acceptance questions, not decorative finishing touches.
Before releasing a passkey journey, give one person responsibility for following the recovery case from beginning to end. Record the decisions the rehearsal exposes and resolve them alongside the happy path. For more work on the relationship between interface choices and delivery, explore the Blanche journal.
Sources checked on 9 November 2026. This is an evergreen product-design analysis; the cited guidance is not a new launch announcement.