A new phone can make an old login habit feel unexpectedly complicated. You remember the website, recognise the account and still have your email address, yet the sign-in screen asks for something stored on a device you are about to trade in. Passkeys can make signing in easier and more resistant to phishing, but a sensible changeover begins before the old device leaves your hands.
The useful question is not simply whether an account has a passkey. It is where that credential is available, which other routes can restore access, and whether those routes will still work after a device change. This guide separates those questions and offers a practical planning worksheet. Its examples are hypothetical, not reports of tested recovery procedures for every provider.
Research was checked on October 27, 2026. The discussion concerns personal accounts. Employer-managed systems can have different policies, and their administrators should direct any changes. No login method makes every device, website session or recovery process immune to compromise.
Start with the credential, the device and the account
FIDO Alliance describes passkeys as FIDO credentials and distinguishes synced passkeys from device-bound ones. A synced credential can be made available through a provider across supported devices; a device-bound credential stays with its authenticator. That distinction is more useful for recovery planning than the appearance of the button used to sign in. [FIDO Alliance’s passkey overview](https://fidoalliance.org/passkeys/) explains the terminology.
Think of three separate entries on your planning sheet: the website account you want to use, the authenticator that can approve access, and any provider account responsible for making the credential available elsewhere. They may be closely connected in daily use, but they are not interchangeable. Knowing the email address for a shopping account does not tell you where its passkey is stored.
A fingerprint prompt can make this distinction less obvious. The prompt is an action you perform on a device; it is not a complete inventory of your available sign-in routes. For your own records, write a plain description such as “personal password manager on supported devices” or “physical security key kept at home.” Do not copy secret material into an ordinary note merely to make the inventory feel complete.
Why the website address still matters
GitHub’s documentation provides a concrete example of the security model. It explains that a passkey uses public-key cryptography and is bound to a website domain. The browser will not use that credential to authenticate to a lookalike phishing website. GitHub also documents how its passkeys can satisfy its password and two-factor requirements during sign-in. These are GitHub-specific details where described, not a promise about every account’s interface. [About passkeys on GitHub](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys).
For a reader planning a changeover, the practical lesson is to start from a known destination. Open the service using a saved address or a route you already trust, then inspect its own security settings. An unexpected message saying that a passkey must be “repaired” is a poor place to begin an account migration. A convincing logo does not establish that a message is part of your normal sign-in process.
Keep the objective narrow. You are checking access to a particular account, not proving that every message or download is safe. A successful passkey login should not become a reason to ignore the rest of the device’s security. Authentication establishes access; it does not evaluate everything you do after entering the account.
Make a short access inventory before changing anything
Choose a small group of accounts that would cause the greatest disruption if inaccessible. Your main email, personal document storage and other accounts central to ordinary life are reasonable places to consider. The exact order depends on your own dependencies. Someone who keeps essential travel documents in one account may prioritise it differently from someone whose main concern is a professional portfolio.
For each account, record the service name, the usual sign-in route, the device or manager involved, and where the official recovery instructions can be found. Add a final column for uncertainty. “Not yet checked” is better than a confident guess. The inventory should help you decide what to verify next, rather than disguise unfinished checks as completed preparation.
Keep this document deliberately modest. It need not contain passwords, recovery codes, identity documents or other sensitive information. It can simply point you to the secure place where legitimate recovery material is stored. If the inventory itself would give a stranger everything needed to enter your accounts, it has become a new problem instead of a planning aid.
Synced does not mean available everywhere
A synced passkey may reduce dependence on one physical phone, but do not translate that into universal portability. Read the instructions for the provider and devices you actually intend to use. A familiar account name on a new device does not, by itself, establish that the relevant credential is already available and usable there.
NIST’s guidance for syncable authenticators treats the synchronisation service as a security boundary. It specifies protections for stored keys and access to the syncing system. It also distinguishes whether a credential is eligible for backup from whether it has actually been backed up. Those implementation details are a reminder that capability and completed configuration are different facts. [NIST’s syncable authenticator guidance](https://pages.nist.gov/800-63-4/sp800-63b/syncable/).
Your personal check can stay simple: identify the documented supported route, use the service’s normal process and confirm the intended result. Avoid creating several new provider accounts during the same changeover unless you need them. Each additional account introduces another set of recovery questions. A clear, understood arrangement is easier to maintain than a collection of alternatives whose ownership you cannot explain later.
A physical key needs a practical storage plan
A device-bound credential is not necessarily trapped inside a phone. GitHub’s explanation includes portable FIDO2 security keys as device-bound authenticators: the credential remains on that authenticator, while the key itself can be connected to compatible devices. This is a useful distinction between moving the physical object and copying the credential to another authenticator.
If you use a physical key, consider ordinary logistics as well as its technical role. Where will it be when you need it? Can you identify which accounts depend on it? Are the device and connection you plan to use supported? These questions do not require you to purchase another product immediately. They require you to understand what your current arrangement can and cannot do.
Consider a hypothetical traveller who keeps a key inside the same bag as a laptop. That arrangement may be convenient, but losing the bag would remove both objects at once. The example illustrates a shared point of loss; it does not prescribe one universal storage method. Your aim is to notice dependencies before a stressful incident makes them obvious.
Verify the new route before retiring the old one
An orderly changeover has a clear sequence: review the official instructions, establish the supported new route, confirm access, then decide what should happen to the old device or credential. The exact screens and prerequisites vary by service. Follow those instructions rather than treating a general article as an account-specific recovery manual.
Use an ordinary sign-in check that does not destroy your existing access. Keep a trusted active session available while you learn the provider’s procedure. Avoid beginning by deleting every old method or signing out of every device at once. A change that looks tidy in a settings list can make troubleshooting much harder if it removes the only route you understand.
Write down the result in practical language. “Signed in successfully on the replacement laptop using the intended manager” is useful evidence. “I think the backup is on” is not equivalent. Also record any remaining caveat, such as a device you have not checked. A short, accurate record is better than an elaborate checklist filled with assumptions.
Recovery deserves its own review
The NCSC’s comparison of traditional credentials and FIDO2 credentials focuses on personal use and considers the credential lifecycle, including recovery. Its findings support FIDO2’s security advantages while stressing protection of the authenticating device, the syncing account and appropriate backups for single-device credentials. It does not turn those findings into a complete enterprise risk assessment. [Read the NCSC comparison](https://www.ncsc.gov.uk/paper/traditional-user-and-fido2-credentials-personal-use).
For your own planning, ask what would happen if the usual device were unavailable tomorrow. Then ask a second question: what if the account used to restore your usual credential were also inaccessible? The point is to discover circular dependencies. A recovery instruction that sends you back to the only account you cannot open needs closer attention before you rely on it.
Do not invent a recovery route from memory. Find the provider’s current instructions, identify what you must have prepared in advance and keep any required material using an appropriate secure method. Some decisions are best made while everything is working normally. That calmer moment lets you compare instructions, understand consequences and avoid making rushed changes prompted by fear.
A hypothetical changeover worksheet
Imagine Maya is replacing her personal phone and also uses a laptop. She starts with three important accounts rather than attempting a complete digital overhaul. For each, she identifies whether her normal sign-in depends on the phone, a manager available on other supported devices, or a separate physical key. She records uncertainties without assuming that all three accounts behave alike.
On the first account, the provider’s documented process allows her to establish the intended access route on her replacement device. She checks it through a normal sign-in and records the result. On the second, she discovers that she has never reviewed the recovery instructions. She leaves the working setup intact while reading those instructions and preparing the required material.
The third account belongs to her employer. Maya stops treating it as a personal configuration task and asks the administrator for the approved process. The example’s success is not that every account changes immediately. It is that each account receives a decision based on its actual ownership and requirements, with no accidental loss of the routes that were already working.
Questions for a service that offers several options
When a settings page presents many sign-in choices, organise your questions around purpose. Which option will you normally use? Which is intended as a backup? Which belongs to a device you no longer control? Which procedure applies if the normal option is lost? Clear answers make it easier to understand what each entry contributes.
You can also ask whether the service lets you name credentials in a recognisable way. If it does, use descriptions that help you distinguish your own authenticators without exposing sensitive details. A descriptive label is an inventory tool, not proof of where a credential currently exists. Confirm the relevant behaviour through the provider’s documented controls.
Avoid interpreting every extra option as automatically beneficial. More entries can mean more flexibility, but they also mean more things to understand and maintain. Review them carefully, and only remove an entry when you understand its role and the consequences. If you cannot tell whether an entry is still needed, consult the official support guidance before making an irreversible choice.
What this guide cannot promise
This article does not verify your individual account, test every operating-system combination or certify a particular password manager. It does not establish that a service’s recovery process will work in your circumstances. Those checks require the current provider instructions and your own authorised account context. A conceptual illustration accompanying the article is not a screenshot of a real security interface.
Be cautious about absolute claims such as “impossible to hack” or “you can never lose access.” They obscure the distinction between a strong authentication mechanism and the broader environment around it. Lost devices, misunderstood recovery arrangements and unsafe account changes still deserve attention. The useful outcome is a better-understood process, not a feeling that further care is unnecessary.
Conclusion: leave yourself an understood way back in
Passkeys are easiest to manage when you can explain where they are available and what you would do if the normal device disappeared. Before replacing a phone, identify your important accounts, distinguish synced and device-bound credentials, read the official recovery instructions and verify the supported replacement route without unnecessarily dismantling working access.
Treat the changeover as a series of small confirmed steps. An account inventory, a tested normal login and an understood recovery procedure each answer a different question. Together they provide a clearer basis for retiring an old device than simply seeing a passkey button and assuming the rest has taken care of itself.
Sources and research note
Primary documentation checked October 27, 2026: [FIDO Alliance](https://fidoalliance.org/passkeys/), [NIST](https://pages.nist.gov/800-63-4/sp800-63b/syncable/), [GitHub Docs](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys) and [NCSC](https://www.ncsc.gov.uk/paper/traditional-user-and-fido2-credentials-personal-use). Source-specific technical summaries are brief; the planning worksheet and hypothetical examples are original editorial guidance. This is a Technology explainer, not a claim that passkeys hold a particular Google Trends rank. Provider interfaces and requirements may change after the research date.