Editorial illustration; the devices and labels are representative examples, not a live account screen.
Passkeys are designed to make sign-in harder to phish and easier to complete than typing a password. The part that deserves more attention is what happens after setup. A passkey on one phone is convenient until that phone is lost, reset or replaced. The safest rollout is therefore not “turn on a passkey and forget passwords”. It is a small access plan: enrol, test, document recovery, then remove weaker options only when you know the new path works.
Summary
- Start with your main email or password-manager account because it can unlock other accounts.
- Add a second trusted sign-in path before replacing a phone or deleting an old device.
- Test the passkey from a private window or another approved device, then record recovery steps without recording secrets.
What problem does a passkey solve?
A password can be copied, reused or entered into a convincing fake login page. A passkey uses public-key cryptography: the service stores a public key, while the private part remains protected by your device or passkey manager. During sign-in, the website and the authenticator prove that they belong together. Your biometric check or device PIN unlocks the authenticator locally; it is not sent to the website as your fingerprint or face data.
CISA describes FIDO authentication as phishing-resistant and lists passkeys as an acceptable alternative to hardware security keys. That is a useful security property, but it does not make every account-recovery process equally strong. A service may still offer email reset, SMS recovery or support-assisted recovery. Your account is only as strong as the recovery paths you leave active.
The search intent behind “how to use passkeys” is often practical rather than theoretical: “Can I still sign in after I change phones?” This guide focuses on that decision.
Before you enrol
Choose the account that matters most. For many people it is the primary email account, password manager or cloud identity that can reset other accounts. Do not begin with a low-value account as a test if the service has an unusual recovery process you have not reviewed.
Make a short inventory:
- Which devices can currently sign in?
- Is the passkey stored on a device, in a password manager or synchronised by an account ecosystem?
- Is there another trusted device you can use if the primary phone disappears?
- What recovery email, phone number or recovery codes does the service show?
Do not put passwords, recovery codes or private keys into this inventory. Record locations and actions, not secrets.
A safer setup workflow
1. Add the passkey from the real account settings
Open the service by typing its address, using a bookmark you trust or using its official application. Avoid starting enrolment from a link in an unexpected message. Check the domain and the account name before approving the device prompt.
When the service offers a choice, understand where the credential will be stored. A device-bound authenticator and a synchronised passkey can have different recovery characteristics. The correct choice depends on your devices, operating systems and the service’s support for cross-device sign-in.
2. Keep an independent recovery path temporarily
After adding the passkey, leave a known recovery method available until the new sign-in has been tested. “Independent” means it does not rely only on the same lost phone. For example, a second trusted device or printed recovery code stored safely is different from an SMS number that is also on the lost phone.
This is a transition measure, not an argument for keeping every weak option forever. Once you have verified the passkey and understand the account’s recovery controls, remove options you no longer need.
3. Test a fresh sign-in
Use a private browser window, a separate browser profile or another device you own. Sign out only if you have another route back in. Confirm that the service asks for the passkey, that your device can approve it, and that you can reach the account without relying on a saved session.
If the service supports a QR-code cross-device flow, inspect the device prompt before approving it. A QR code is a transport mechanism, not proof that the page is legitimate. Start the process from the real sign-in page and cancel if the request is unexpected.
4. Review the account’s device list
Name devices in a way you will recognise later, such as “personal iPhone” or “office laptop”. Remove old devices only after confirming they are not your only recovery route. Review active sessions, connected applications and recovery contacts at the same time.
5. Write the replacement plan
When you replace a phone, the sequence matters: add the new device, test sign-in, move or recreate the passkey as supported, then wipe and remove the old device. Do not erase the old phone first merely because the new phone appears to contain your apps. Authentication data and account sessions do not always migrate in the same way as photos.
Example: replacing a phone
Suppose your main email account has a passkey on your old phone and a recovery code stored in a password manager. Before wiping the old phone, sign in on the new phone, verify the passkey, open account security settings and confirm the recovery code can be located. Then sign out the old device, remove its session and erase it.
If the new phone cannot sign in, stop. Keep the old phone available while you use the provider’s documented recovery process. This is slower than guessing, but it avoids turning a migration problem into an account lockout.
What passkeys do not solve
Passkeys do not protect a device that is already unlocked, stop every form of account fraud or guarantee that a service has a good recovery process. They also do not tell you whether a third-party application should have access to your account. Review connected applications separately.
They are not a reason to ignore software updates, device lock settings or account alerts. A strong authenticator is one part of an account’s security boundary.
For a broader starting point, see how to protect an admin login without locking yourself out and how to map personal data before protecting it.
Mistakes to avoid
- Enrolling a passkey and immediately wiping the only device that can approve it.
- Assuming a saved browser session is the same as a tested recovery method.
- Keeping every recovery option forever without reviewing its risk.
- Approving an unexpected cross-device prompt just because it uses a QR code.
- Recording recovery codes in an ordinary notes file or the same device you are trying to recover.
My Take
The best passkey rollout is boring and reversible. Add it to the account that matters, test it from a fresh sign-in, and delay irreversible device cleanup until you have a second route. That workflow gives you the security benefit of phishing-resistant authentication without treating recovery as an afterthought.
Conclusion
Use passkeys as part of an access plan. Identify the account that unlocks other accounts, add the passkey from genuine settings, test it on a fresh sign-in, document the recovery route and only then remove old devices or weaker methods. If you are replacing a phone today, keep the old device available until the new sign-in has been proven.