This is now a mainstream security recommendation. On April 23, 2026, the UK’s National Cyber Security Centre recommended passkeys as consumers’ first choice wherever they are available. For services that do not support them, its advice remains a password manager and two-step verification. You can make that change account by account; you do not have to abandon your password manager or buy a hardware key to begin.
The website checks a proof instead of a password
A password is a secret you can type, paste or have a manager autofill. A good manager already removes much of the work of remembering passwords and can help you use a different one for every account. The important change with a passkey is what the service checks, rather than whether your fingers touch the keyboard.
When you create a passkey, an authenticator creates a cryptographic key pair for the account. The service receives the public key. The private key is protected by your device, credential manager or security key. At sign-in, the service supplies a fresh challenge, and the authenticator signs a response. The service checks that response with the public key. The W3C WebAuthn standard describes how the response also includes context such as the requesting origin.
That connection to the authorised service provides the phishing protection. A lookalike website cannot simply request the passkey as if it were the genuine service and collect a reusable login secret. Nor does a passkey for one service become a password an attacker can try at unrelated sites. The design removes a recurring decision that passwords leave to the user: whether this particular sign-in page deserves the secret.
This also explains why adding a code to a password is a different defence. A criminal can sometimes relay a password and a freshly entered one-time code to the real service. FIDO’s passkey guidance distinguishes that phishable exchange from service-bound authentication. Keep two-step verification where it is needed, but do not assume that every method labelled “MFA” provides the same resistance to a fake login page.
Your fingerprint or PIN unlocks the credential locally
Your face or fingerprint is not the passkey and is not a new password sent to every website. It authorises the device to use the credential. A device PIN, pattern or other supported unlock method can serve that purpose too. You do not need a fingerprint reader simply because a service offers passkeys.
For a typical consumer sign-in, the combination is possession of the credential and local verification of the person using it. Google’s security explanation confirms that biometric processing stays on the device. The website receives cryptographic assurance rather than a copy of your fingerprint. A PIN entered into the operating system’s genuine unlock prompt has a different role from a short password typed into a webpage. Keep that distinction in mind when a site asks you to create or use a passkey.
Where you save the passkey determines how you get it back
A passkey provider is the software or hardware that creates and manages your passkeys. The browser may offer an operating-system provider, a signed-in password manager or a hardware security key. Pay attention to the provider named in that choice. Two prompts on the same computer can save credentials in places with different backup behaviour.
A synced passkey can become available on your other authorised devices through the same provider and account. A device-bound passkey stays with its particular authenticator. FIDO’s consumer-deployment guidance distinguishes these arrangements and their recovery implications. “The private key never goes to the website” is a useful sign-in rule; “the private key can never leave this phone” is not an accurate description of every synced passkey.
Google’s Chrome passkey instructions give a practical example. Google Password Manager can make saved passkeys available across supported devices using the same Google Account. Saving a passkey locally in Windows Hello is a different choice: that credential does not gain Google Password Manager’s sync simply because you created it in Chrome. Google warns that the local Windows Hello passkey cannot be recovered if the computer is lost or its operating system is reinstalled.
A suitable FIDO2 security key is another storage option. It can provide a separate way into an account when the service permits you to register it. Keeping an additional key somewhere safe can reduce dependence on your daily phone. It also means looking after physical hardware. A lost key does not magically acquire the cloud backup of a different provider, and registering one key does not automatically register a spare.
Using another device can mean three different things
The first route is sync. You set up the same provider on a supported device, meet its authentication and encrypted-data access requirements, and use the credentials it makes available. That is convenient when replacing a phone or adding a laptop. The important dependency is access to the provider account and its recovery material, not merely possession of a new device with the same brand.
Apple’s iCloud Keychain guide describes synchronisation across approved devices. It also describes recovery when all devices are lost, including a configured recovery contact or an escrow process with specific authentication requirements. In the latter process, Apple lists the Apple Account, a trusted phone number and the device passcode. Sync gives redundancy; it does not remove those checks. Prepare the applicable recovery route while you still have access.
The second route is cross-device sign-in. A compatible computer can show a QR code that you scan and approve on a nearby phone holding the passkey. Microsoft’s Windows documentation says the participating devices need Bluetooth and internet connectivity for this flow. The phone authorises the computer’s sign-in without copying the passkey onto it. Completing that login does not, by itself, migrate your credential collection to the laptop.
The third route is moving to a different provider. Check the current export and import support of the providers involved; do not assume that ordinary browser password export carries every passkey. Where direct transfer is unavailable, FIDO describes using the old device to sign in and then creating another passkey in the new device’s provider. Do this before giving up the old provider. A working phone-assisted login can help you establish the new credential, but the two actions remain separate.
Adding a passkey does not always remove your password
A service decides which sign-in methods it accepts and what adding a passkey changes. Some accounts retain password sign-in alongside passkeys; others offer a transition to a passwordless account. A passkey is not automatically the same thing as a “Continue with Google” or “Sign in with Apple” button, which uses another account’s identity service. Follow the security settings of the account you are actually changing.
For a personal Google Account, Google explicitly says that adding a passkey does not remove existing authentication or recovery factors. It also says that a passkey can bypass the separate second step in its two-step verification flow. That is the documented behaviour of that service, rather than a reason to disable codes or other factors everywhere.
A retained password still needs to be unique and protected. If it remains a valid route into the account, adding a passkey does not make a leaked copy harmless. Conversely, “always keep the old password forever” is not a universal rule either. If the service offers password removal, first establish how its alternative sign-in and recovery routes work. Work and school accounts may have policies you cannot change; our Microsoft Entra migration guide addresses that separate administrator task.
Choose a provider you can use beyond today’s phone
Start with the devices and browsers you actually use. An operating system’s built-in manager can be convenient within its supported ecosystem. A cross-platform credential manager may fit a mixture of devices better, provided its passkey support covers your particular browsers and apps. Neither choice can be judged by the word “passkey” alone. Check where credentials are saved, how another device becomes authorised and what account recovery requires.
Google Password Manager illustrates why this detail matters. On a new device, access to encrypted passkeys can require a Google Password Manager PIN or the relevant Android screen-lock credential. Its PIN recovery instructions distinguish changing a forgotten PIN from a previously used, eligible device and resetting the passkeys themselves. The latter deletes all those passkeys and requires you to create new ones at each service. Do not use a destructive reset as a casual way to clear an unfamiliar prompt.
Choose with the loss of your everyday device in mind. A second device using the same synced account helps with a broken phone, but both depend on that provider account. A separately registered security key or another service-supported access route can cover a different failure. What matters is knowing which dependency each route removes. There is no universal recovery phrase that every passkey service issues.
Make the switch one account at a time
Begin on a device you own and control. Keep its software current and its screen lock protected. Open the genuine service directly and find its account security settings. Create a passkey using the provider you intend to keep using. Read the account name and provider in the prompt, especially if you have multiple browser profiles or personal and work identities on the same machine.
Keep your current session available while establishing that the new method works. Use the supported sign-in flow to confirm you can reach the intended account, then establish the additional device or backup method you plan to depend on. Record the provider and credential name where you keep account-recovery information. You do not need to record the private key as though it were a password you should copy into a document.
Review recovery at both levels: the website account and the provider storing the passkey. Check that recovery email addresses and trusted phone numbers are current, and preserve any recovery codes the service actually supplies. Store those codes somewhere you can reach without first unlocking the one account they are meant to recover. This is particularly relevant when your primary email is also the account used by your credential manager.
Before erasing or selling an old device, complete the replacement setup and follow the manufacturer’s transfer procedure. An iPhone erase requires a real backup and account-access plan, not just confidence that cloud services exist. On an encrypted Windows PC, keep the separate BitLocker recovery key available too. A passkey for your Microsoft account helps with online sign-in; it does not replace the numerical key that unlocks an encrypted drive.
If a device is lost, recover access and remove its authority
Use another authorised device, a separately registered key or the service’s documented recovery process. If no credential is accessible, recovery depends on what the provider and website can verify. Knowing the email address or buying a replacement phone does not guarantee that they will release encrypted credentials or restore the account.
After regaining access, review registered passkeys and devices in the service’s security settings. Remove the credential associated with a lost or untrusted authenticator, following the provider’s instructions for automatically created credentials where applicable. Removing a local saved entry and withdrawing the service’s acceptance of that credential are different operations. The service’s registered-credential list is the relevant place to check that it can no longer be used for a new sign-in.
Review existing sessions as well. Revoking a credential is about future authentication; it should not be assumed to terminate every session that was already established. Use the service’s device and session controls, and secure the lost device through its manufacturer’s process. If someone may know the device unlock code, treat that as an access risk rather than relying on the presence of a fingerprint sensor.
Keep the device and recovery process protected
Phishing-resistant authentication is a substantial improvement, but it is not a promise that malware, a compromised device, a stolen session or a weak recovery process cannot affect you. MDN explicitly includes authenticator protection and account-recovery mechanisms among the remaining concerns. Keep the device and credential manager updated, use trusted software and respond to suspicious account activity through the service’s own controls.
