Create a passkey only after you know where it will be saved and how you would sign in without your current device. Passkeys improve login security. They do not remove the need for a spare way in.
A passkey is not necessarily trapped on one phone. The FIDO Alliance distinguishes synced passkeys from device-bound passkeys. A password manager can synchronize a passkey across supported devices using encrypted sync. A device-bound passkey stays with its authenticator, such as a compatible hardware security key. These are different storage arrangements for the same kind of sign-in credential.
What goes to the website
The website stores a public key. Your authenticator uses the corresponding private key to sign a fresh challenge during sign-in. The website checks that signature instead of receiving a reusable password. The FIDO Alliance’s security explanation describes this challenge-response process. The private key is not sent to the website as the login secret, even when a passkey provider synchronizes it between your devices.
Passkeys are bound to the service they were created for. That is why a lookalike website cannot simply collect the same credential through a fake password box. Device verification, such as a PIN or biometric check, authorizes use locally; the website does not receive your biometric data. This is a real improvement, not just a password field with better manners.
See how this works: passkey storage
Choose the storage arrangement before enrolling
Synced passkey: choose this when you want supported devices signed into the same passkey provider to have access. Check that the provider works on your actual combination of devices and browsers. Protect that provider account and understand its recovery requirements. A second device that depends on the same inaccessible provider account is not an independent recovery plan.
Device-bound passkey: choose this when keeping the credential on a particular authenticator matters. If the service permits it, register another authenticator and store it separately. Losing the only enrolled key otherwise sends you back to the service’s recovery process.
Using a nearby phone to sign in: this is not the same as syncing a credential onto the computer. Supported cross-device flows let the phone authorize sign-in. Do not assume that successfully using the phone proves the computer can sign in after the phone is gone.
Do a replacement-device rehearsal
Start from the account’s security settings on a device you control. Add the passkey, note which provider or security key saved it, and confirm the service lists it. Do not create one on a shared device just because the prompt offers.
Keep an existing signed-in session available. In another supported browser or device, begin a fresh sign-in and explicitly choose the passkey. Confirm you reach the correct account. To check a synced fallback, use a separate supported device and sign in with the passkey stored by the intended provider there, without using the original device. Another browser on the original device does not test losing that device. If you intend to rely on a spare hardware key, test that key separately.
For Google Accounts, Google documents supported browsers, screen-lock requirements, and the nearby-phone flow. It also notes that private browsing can prevent passkeys working in some combinations, newly created passkeys may have a waiting period, and managed accounts can have different policies. A missing prompt is not proof the credential disappeared.
If the rehearsal fails, check the selected provider, browser support, screen lock, and service-specific restrictions before deleting anything. Keep the old working sign-in method while resolving the problem.
Finally, inspect the remaining password and recovery options. Google explicitly says adding a passkey does not remove existing authentication or recovery factors. Other services make their own choices. Success means a fresh passkey sign-in works and a usable fallback exists. It does not mean every older route into the account has quietly vanished.