Security Signing in safely: 2FA, passkeys and account recovery
Passkeys explained: signing in with no password at all
What a passkey is, how the phishing resistance actually works, what happens when you lose the device, and whether it is time to switch your main accounts over.
The short answer
- A passkey is a cryptographic key pair: the private half stays locked on your device, the site keeps only the public half, and you prove who you are by signing a one time challenge.
- It resists phishing because the browser tells your device which domain is asking, and a passkey will not sign for a domain it was not created for, with no override button.
- Synced passkeys survive a lost phone and device bound ones do not, so the choice is really a choice about how you plan to recover.
- Signing in on someone else's computer uses a QR code plus a Bluetooth proximity check, which is why a remote scammer cannot talk you through it.
- Most accounts keep the old password and the text message fallback alive, so the phishing resistance only becomes real when you can turn those off.
- Secure the account or vault that stores your passkeys first, because every passkey inside it inherits that account's security.
A passkey replaces your password with a pair of linked cryptographic keys. When you create one, your phone, laptop or password manager generates a private key that stays locked in secure storage on that device, and a public key that it hands to the website. To sign in later, the site sends a random challenge, your device asks you to confirm with your face, your fingerprint or the device PIN, and it signs the challenge with the private key. The site checks the signature against the public key it already holds. Nothing reusable crosses the network, and the site is not storing a secret that would be worth anything to a thief who breaks in.
What a passkey actually is
Passkey is the friendly name for a credential built on the WebAuthn and FIDO2 standards. Underneath it is one key pair per account per site, and the two halves do different jobs.
The private key can produce signatures. It never leaves the secure chip or the encrypted store that holds it, and no screen ever shows it to you. You cannot read it out to a caller, type it into a form, or paste it into a chat, because it is not the kind of thing that has a readable form.
The public key can only check signatures. That is the part the website keeps. If the site is breached tomorrow and the whole database is published, an attacker gets a list of public keys, which lets them verify signatures and produce none. Compare that with a password database, where even hashed passwords can be attacked offline for months.
The signature is different every time, because the challenge is, so a recorded sign-in cannot be replayed. A passkey also carries two factors in one step: you have to be holding the device and you have to unlock it, so possession plus a biometric or a PIN are proved at once. That is the pairing described in two-factor authentication, compressed into a single tap.
Why a fake site cannot use your passkey
Every passkey is stored against the domain that created it. When a page asks for a sign-in, the browser or operating system, not the page, tells the authenticator which domain is actually in the address bar. If that domain does not match the one recorded with the key, no signature is produced. There is no warning to click through and no advanced button to override it. The credential for your bank simply does not exist as far as a lookalike domain is concerned.
The signed data also contains the origin the browser saw. So the modern relay attack, where a fake page forwards your password and your six digit code to the real site within seconds, has nothing to forward. The attacker can copy the page pixel for pixel and still get an empty hand. That single property is why a convincing phishing page stops being a realistic way to take a passkey protected account, and why passkeys are treated as a different category rather than a nicer looking code.
The limits are real. A passkey defends the sign-in. It does not defend you against malware already running on your computer, against someone who can unlock your phone, or against being talked into making a payment yourself once you are legitimately signed in.
Synced and device bound passkeys
Passkeys come in two shapes, and most arguments about them come from comparing different shapes without saying so.
| Type | Where the private key lives | Survives losing the device? | Best suited to |
|---|---|---|---|
| Synced by the platform | Encrypted in your Apple, Google or Microsoft account and copied to your devices | Yes, restored when you sign in to the platform account on a new device | Everyday accounts for people who live inside one ecosystem |
| Synced by a password manager | Encrypted in your manager vault, available on every platform the app supports | Yes, restored when you unlock the vault on a new device | People who use a mix of Windows, Android, Mac and iPhone |
| Device bound on a phone or laptop | In that machine only, never copied anywhere | No, the key is gone with the device | Work laptops and high value accounts with a second credential registered |
| Hardware security key | On the physical key you carry | No, unless you registered a second key | Accounts where you want the credential to be an object you can put in a drawer |
Syncing trades a little theoretical security for a lot of practicality, and that trade is usually correct. Notice what it moves rather than removes: your everyday sign-ins now rest on the account or vault holding them, so that one account needs a long unique master credential and its own second factor. If you are choosing where to keep them, how a password manager holds a vault explains the encryption the manager route depends on.
Signing in on a device that does not have your passkey
You are at a friend's computer and your passkey is on your phone. The standard has an answer, and it is worth understanding because it looks strange the first time.
The site shows a QR code. You scan it with your phone camera. The phone and the computer then set up a direct channel, and here is the useful detail: they confirm that they are physically near each other using Bluetooth. Your phone signs the challenge and sends the signature back to the browser session. The private key never travels to the computer, and nothing is left behind on it.
The proximity check is not a formality. It is the reason a scammer on a call cannot talk you through scanning a QR code they email you from another country: the two devices have to be in the same room. If a site or a caller asks you to scan a passkey QR code that did not appear on a screen in front of you, that is the moment to stop.
Most sites then offer to save a new passkey on that computer. Say no on a machine that is not yours.
What happens when you lose the device
The honest answer depends on which shape you chose.
With synced passkeys, a lost phone is an inconvenience. Sign in to your platform account or manager on the replacement device and the passkeys reappear. But notice the assumption: that you can still get into that account. If it is protected only by a code sent to the phone you just lost, you have built a loop. Some platforms also offer an optional recovery key that makes the vendor unable to let you back in, which is strong against anyone impersonating you and unforgiving if you lose the paper.
With device bound passkeys, the key is genuinely gone. The fix is planned in advance: register two credentials on every important account, for example a phone and a hardware key kept at home. Before you rely on any of this, walk through the recovery settings on the account, and on the account that syncs your keys.
The password that is usually still there
Here is the part that marketing leaves out. On most consumer sites today, adding a passkey does not remove the password. The old password still works, the text message code still works, and the account recovery form still works. An account is only as phishing resistant as its weakest accepted route, so in practice you have made the good path easier rather than closing the bad one.
Attackers have already adapted. The script is a page or a call that says the passkey system is having problems and asks you to use the code instead. The technical defense is gone at that point, and you are back to judgment. Treat any prompt that steers you away from the passkey as suspicious by default.
A few services now let you delete the password once a passkey is registered, or accept only phishing resistant credentials. That is the point where the benefit becomes real. Until then, keep the fallback strong instead of pretending it is not there: a long unique password, and an app based code rather than a text, which setting up an authenticator app covers.
Two smaller limits are worth naming. Portability is still awkward: an export and import standard exists, but support is arriving slowly, so assume that moving a pile of passkeys between managers may mean re-registering them. And site support is uneven, with many services accepting a passkey to sign in but demanding the password for sensitive changes.
The setup worth doing today
Start with the store, not the accounts. Decide whether your passkeys live in your platform account or in a password manager, then give that one account a long unique master credential and a second factor. Everything else inherits its security.
Then add passkeys in this order: the email address that receives your password resets, the manager or platform account itself if it supports one, payment and shopping accounts, then social and messaging. On each one, register a second credential before you need it: another device, a hardware key, or recovery codes on paper.
Leave the old password in place at first, make it a good one, and delete it only when the site offers a real passkey only mode. If your phone does the unlocking, spend two minutes on its screen lock too, because the whole arrangement rests on it: face and fingerprint unlock explains what the passcode underneath is doing.
Common questions
Are passkeys safer than a password and a 2FA code?
Yes, and the difference is specific. A password plus a texted or app generated code can all be captured by a fake sign-in page that relays them to the real site in seconds. A passkey cannot be captured that way, because it only responds to the genuine domain and produces a one time signature rather than a secret you could hand over.
What if my phone is stolen, can the thief use my passkeys?
Only if they can unlock the phone. Every passkey use requires the device unlock first, so a strong six digit or longer passcode is what stands between a thief and your accounts. Report the device lost so it can be remotely wiped, and change the password on the account that syncs your passkeys.
Do passkeys work without internet or across brands?
The signing itself is local, but the site you are signing in to needs to be reachable, so you still need a connection. Across brands it is improving but uneven: a passkey stored by one platform can usually be used on another device through the QR code flow, while moving the stored keys themselves between managers is still awkward.
Should I delete my password once I have a passkey?
Only when the service genuinely supports it. Most sites keep the password active as a fallback, so deleting it is not an option and removing it from your manager would just lock you out of that path. Where a service offers a passkey only mode, turning it on is what actually closes the phishing route.
Where are my passkeys stored, exactly?
In whichever keystore created them: the secure hardware on your phone or laptop, your platform account if it syncs them, your password manager vault, or a hardware security key. You can see the list in your device or manager settings, and on each website there is usually a security page listing the passkeys it recognizes.