Passkeys Explained: How They Work, What They Protect, and How Not to Get Locked Out
Most people have been offered a passkey by a site they log into and hesitated. This guide covers what a passkey is, the two storage models under one word, and the recovery planning that keeps you safer rather than locked out.
The short version
A passkey is a public/private key pair created for one specific website or app. The private half stays on your devices, unlocked by your face, fingerprint, or device PIN. Signing in proves you hold that private key without sending a secret the site could lose in a breach.
It is meaningfully harder to phish than a password. The residual risk moves to whatever unlocks the device or account storing your passkeys, and to your ability to recover when that is unavailable.
What a passkey is, in credential terms
The underlying standard is WebAuthn, the browser API for public-key credentials, built alongside the FIDO Alliance's passkey programme. Creating one produces a key pair bound to that site's origin: the public key is registered with the website, the private key never leaves your side.
At sign-in:
- The site asks your browser to authenticate, presenting its origin and a one-time challenge.
- Your browser asks the provider which saved credential matches that origin.
- You verify yourself to the device — Touch ID, Windows Hello, a fingerprint, or a PIN.
- The device signs the challenge with the private key and returns only the signature.
- The site checks it against the public key stored during enrolment.
Two properties follow: the transmitted secret is a single-use signature, so nothing reusable can be captured; and because the credential is scoped to an origin, a lookalike domain will not match.
Two kinds of passkeys, and the difference that matters
One word covers two storage models. Before deleting a password, work out which one you created.
| Synced passkey | Device-bound passkey | |
|---|---|---|
| Private key lives | Provider sync vault — an OS keychain or password manager | One physical device or security key |
| Other devices | Yes, any device on the same provider account | No — you carry the hardware |
| Lost device means | Sign in from another synced device, if you control the provider account | Gone until you re-enrol |
| Its weak point | The provider account's recovery process | Physical custody and spare hardware |
Apple's iCloud Keychain is the clearest synced example: iCloud Keychain must be set up on the Mac before you can create one there — see Sign in to an account on your Mac with a passkey. Windows is the opposite default: Microsoft's guidance on managing saved passkeys calls a device-bound passkey one stored to that Windows device and deletable from Settings.
Set one up without painting yourself out
Creating one is quick; verifying you could still get in without it is the part people skip. In order:
- Sign in with your password first. Enrol from an authenticated session, not a recovery flow.
- Confirm where it was stored. The prompt usually names the provider — a keychain, a password manager, or "this device". If it is ambiguous, also create the passkey on a second device rather than assuming sync.
- Create a second passkey on hardware you do not carry with the first. A laptop plus a phone is a reasonable pair; a phone plus the watch on the same charger is not.
- Keep at least one non-passkey method working. A retained password, a recovery code, or a verified second email address. Do not remove it in the same week you enrol.
- Test the fallback while everything is fine. Sign out, sign in with the second passkey, and confirm the provider account can still be unlocked from a rarely used browser.
- Only then make the passkey your primary method.
On shared or borrowed hardware, skip enrolment entirely: anyone who can unlock the device can complete verification, so a passkey created there is effectively a shared key.
The recovery risk is the real story
A passkey removes the "I forgot my password" path but not the need for recovery — it relocates it. For a synced passkey, your provider account becomes the master dependency: if it is locked, or its recovery process social-engineered, the passkeys inside move with it. For a device-bound passkey the dependency is physical: lose the only key and you are back to whatever fallback the site still allows.
Passkeys cut credential theft on the site side, but they concentrate importance on the account that stores or syncs them. Treat that account — usually your primary email or platform login — as needing the strongest second factor and the most careful recovery settings.
Where passkeys go wrong: the common failures
- Enrolling on one device only. The usual route to a lockout.
- Assuming cross-vendor portability. A passkey synced into an Apple keychain is available to Apple devices; a Windows or Android device is not automatically covered. Cross-device sign-in by QR code exists because sync does not cross provider boundaries — practise it as a fallback, do not assume it.
- Deleting the password immediately. Sites differ in supported browsers and platforms, and the fallback is what you need on an unfamiliar machine.
- Forgetting passkeys inherit the device's trust. A weak unlock — a four-digit PIN shared with family, an always-unlocked tablet — makes the passkey as weak as that unlock.
- Never revoking. Old passkeys for a phone you sold or a laptop you wiped stay valid until removed. Both Windows Settings and each site's account security page list what is enrolled.
If your device is lost: the order of operations
- Sign in to the affected site from any device you still control, using your fallback.
- Open its account security or passkey management page and remove the credential tied to the missing hardware.
- If your provider account may itself be exposed, change its password and end active sessions before touching individual sites.
- Enrol a replacement passkey on a device you have, then verify the revoked one no longer appears.
- Re-check the enrolled-credential list once things have settled: an entry for the replaced device can survive a re-enrolment.
When a passkey is not the right answer
Some accounts genuinely warrant a hardware-bound credential instead of a synced one: banking, a domain registrar, an Apple or Google account that unlocks backups. There device-bound is a feature — you trade convenience for the guarantee that no remote sync can hand an attacker your key. Conversely, on low-stakes accounts with no recovery options at all, a passkey on a single device can turn a lost phone into an unrecoverable situation.
FAQ
Are passkeys the same as two-factor authentication?
No. A passkey is a complete credential, not a second factor bolted onto a password. It proves identity with a signature from a private key that stays on your side, so there is usually no password step and no code step. Many accounts still list both methods side by side.
Can a passkey be stolen or reused on another website?
It cannot be replayed on a lookalike domain because the credential is scoped to the origin it was made for. What can go wrong is losing access to wherever the private key lives — an unlockable device, or a sync account that gets locked or recovered by someone else.
What happens if I lose the device holding my passkey?
Synced passkeys are available from another device on the same provider account, and you can revoke the old credential from account security settings. Device-bound passkeys, such as those on a security key, are simply gone until you re-enrol. That distinction decides how bad the loss is.
Should I delete my passwords after creating a passkey?
Not right away. Support varies by site and browser, older hardware may not complete a passkey prompt, and losing the provider account password would take your synced passkeys with it. Keep a fallback until you have signed in successfully on more than one device.
Related on ToolStep: 1Password vs Bitwarden covers whether a password manager should hold passkeys for you, and the best password managers ranking explains which sync credentials across platforms. If you are switching managers rather than authentication methods, follow our vault migration guide first; see Security tools for more. Our methodology is in how we test.