Learn what a passkey is, how it differs from a password, where it's stored, and how to sign in or recover access when you change or lose a device.
You clicked into your account settings and saw a button: "Create a passkey." Before you tap it, here's what you're agreeing to.
A passkey is a cryptographic credential tied to your account on a specific website or app. You don't create it yourself, and you don't need to remember it. Instead, your device generates it, and you unlock it the same way you already unlock your phone or computer: with your fingerprint, your face, or a PIN.
That's the part worth being precise about upfront: your fingerprint or face scan isn't the passkey. It's just the everyday action that gives you permission to use one.
Below: how creating and signing in with a passkey works, how it's different from a password, where your passkeys live, and what happens if you lose your phone or switch devices.
When you create a passkey, your device generates a pair of cryptographic keys tied to that specific account and that specific website.
One of those keys is public. It gets sent to the website and stored on its server. The other is private, and it never leaves your device or your passkey provider, the app or service responsible for creating and protecting it. The website never receives your private key, and it never receives your fingerprint or face scan either. Both stay local to your device.
Passkeys come in two forms, synced or device-bound, which affects where you'll find them later. More on that difference in the storage section below.
Signing in follows a fixed sequence:
Nothing about this sends your biometric data to the website. Your device confirms locally that you're really you, and only the resulting signature travels anywhere.
| Comparison point | Password | Passkey |
|---|---|---|
| What you remember | The password itself | Nothing specific to the account, just however you already unlock your device |
| How sign-in is verified | The site checks what you typed against a stored value | The site checks a cryptographic signature against a stored public key |
| What the website stores | Ideally a salted hash of your password, not the password itself, though this depends entirely on the website doing it correctly | A public key and related metadata, which isn't a secret and isn't useful on its own |
| Reuse across websites | The same password often gets reused, which is exactly what makes credential-stuffing attacks work | A given passkey only works for the one site it was created for |
| Phishing resistance | A convincing fake site can simply ask you to type your password in, and you can comply without realizing anything's wrong | Your device checks that it's talking to the real, registered website before it will even offer to sign in; a fake site can't get a valid signature out of it |
| Using another device | Works from any device, since you just type it in | Depends on whether the passkey is synced to that device or you use a cross-device sign-in flow, covered below |
| Recovery | Reset via email or SMS, a familiar but also commonly-attacked process | Depends on your passkey provider's own recovery process, not the website's password reset flow |
| Availability | Supported everywhere, by definition | Growing fast, but not universal; some sites and some older devices don't support it yet |
Here is where people usually get tripped up:
Autofilling a saved password isn't the same as using a passkey, even though both can feel like a one-tap sign-in. It's still the same password underneath.
One PIN on your device can unlock many different passkeys, for many different accounts. It's not a single master password for the internet, it's just the same local unlock step applied separately to each one.
Creating a passkey for an account doesn't automatically delete your password for it. Many sites keep both around, at least for a while, and some let a password stay as a fallback.
And "passwordless" is a broader category than "passkey." A one-time code texted to your phone is also a form of passwordless sign-in, but it isn't a passkey and doesn't carry the same phishing resistance.
For the specific job of signing in, yes, in ways that are fairly well established. The UK's National Cyber Security Centre reviewed the security of passkeys against traditional multi-factor setups and concluded passkeys hold up as well or better than 2-step verification using even a strong password. That's a meaningful comparison, not a marketing line, since it accounts for the layered defenses passwords are usually paired with today, not just a bare password on its own.
The phishing resistance comes from how a passkey is tied to a specific website's identity, not just typed text that could go anywhere. When your browser is about to use a passkey, it checks that the site asking for it is the same one the passkey was created for. A convincing fake login page, even a pixel-perfect copy, is still a different address behind the scenes, so it simply can't get your device to produce a valid signature. That's a structural check your browser makes, not something that depends on you noticing a suspicious URL yourself.
Password reuse across sites disappears as a risk too, since a passkey for one account is worthless anywhere else. And because the public key sitting on a website's server isn't a secret, a server-side breach that exposes it doesn't hand an attacker anything they can use to sign in as you, unlike a leaked password database.
It's also worth not lumping every second-factor method together as equally strong. A password paired with a text-message code is still phishable, since both pieces can be typed into a fake site. A hardware security key is a different category entirely, closer to a passkey's own phishing resistance than to an SMS code.
A passkey protects the moment you sign in. It doesn't protect everything around that moment.
If your device itself is compromised, malware running on it, or someone who's gotten past your screen lock, your passkeys are exposed the same way anything else on that device would be. A stolen, already-open session (the cookie that keeps you logged in after you've signed in) isn't touched by passkeys at all, since that theft happens after sign-in, not during it. And any backup or recovery path tied to your account, an old security question, a recovery email you no longer check, an SMS number you switched away from, is only as strong as its weakest link, regardless of how strong your passkey is.
None of this makes passkeys weak. It means "safer at sign-in" and "your account can never be compromised" are different claims, and only the first one is accurate.
Most people end up with synced passkeys, managed by a passkey provider like Apple's iCloud Keychain, Google Password Manager, or a third-party credential manager such as 1Password or Dashlane.
Here's what that provider does: it creates and protects the passkey, uses your device unlock to confirm it's really you before letting the passkey be used, and copies (syncs) it to your other devices signed into the same account with the same provider. That's how a passkey you create on your phone can show up ready to use on your laptop without you doing anything extra.
Apple's own security documentation is a useful specific example here: passkeys sync through iCloud Keychain, which is end-to-end encrypted, and are recoverable even if every device you own is lost, through an escrow process that still requires your account password, a code sent to a trusted device, and your device passcode to unlock. Google Password Manager and third-party providers each have their own version of this, and the exact steps differ by provider, not by some universal passkey standard.
Some passkeys are deliberately built to never leave a single device or hardware security key. These are common on dedicated USB or NFC security keys, and they're the choice some people make for a specific account, a bank, an email account, a crypto wallet, where they want the strongest possible guarantee that the credential exists in exactly one physical place and nowhere else.
The tradeoff is direct: nothing to sync means nothing that can be recovered through a cloud provider either. If that specific key or device is lost, you're relying on whatever backup sign-in method the website itself offers, not a passkey provider's recovery process.
| Component | Role |
|---|---|
| Website | Registers your public key and checks it against sign-in attempts |
| Browser | Connects the website's request to whatever passkey provider is available on your device |
| Passkey provider | The actual app or service that creates, stores, and uses the passkey, your phone's credential manager, your computer's, or a security key |
| You | Approve each use with your device's existing unlock method |
None of this is fixed for every situation. A passkey isn't always sitting in your browser specifically, it isn't guaranteed to sync everywhere automatically, and it doesn't always stay locked to the device it started on. Which of those is true for a given passkey depends on which provider created it and how you set it up.
The exact wording changes from service to service, but the shape of the process is usually the same:
Here's what that looks like concretely, checked against Google's own current instructions as of this writing.
In your Google Account, under Security, there's a dedicated Passkeys and security keys page. Tapping "Create a passkey" prompts you to unlock your device, and that's the entire creation step, no forms, no new credentials to invent. The next time you sign in, entering your username on Google's sign-in page can surface a saved passkey directly as an autofill-style option; selecting it and unlocking your device is the whole sign-in. Every passkey you've created shows up on that same Passkeys and security keys page, where you can also remove one if you've lost the device it's tied to.
A few things apply no matter which service you use: you generally don't need a fingerprint sensor specifically, a device PIN or pattern usually works as an equally valid unlock method. Don't create a passkey on a device other people also use, since unlocking that device becomes enough to access the account. And creating a passkey isn't a reason to immediately go delete every backup way into your account, keep at least one working fallback until you've confirmed the passkey works the way you expect.
| Scenario | What happens |
|---|---|
| You lose your phone, but have another device with the same synced passkey provider | You can keep signing in from that other device right away. Separately, secure or wipe the lost phone through your provider's own device-management tools. |
| You get a new phone | Whether your passkeys show up depends on signing back into the same passkey provider account on the new device, this is a provider-level step, not something the website you're logging into controls. |
| You lose the only device holding a device-bound passkey | There's no cloud copy to fall back on. You'll need another registered sign-in method, or the website's own account recovery process. |
| You need to sign in on a computer using your phone | Supported sites offer a cross-device flow: a QR code on the computer, scanned by your phone, followed by a fingerprint, face, or PIN check on the phone itself. |
| You're switching credential managers or ecosystems entirely | Moving passkeys between different providers depends on what each specific provider supports for export or transfer. It isn't automatic, and it isn't guaranteed. |
Four things get confused with each other constantly:
Syncing is what makes a passkey available across your own devices through one provider. Cross-device sign-in is different: it lets one device (usually your phone) help you sign in on another device for that one session, without copying the passkey over. Recovering your credential manager gets you back into the vault holding your passkeys. Recovering your account on a specific website is that website's own separate process, and having your passkeys back doesn't automatically fix a locked-out account if something else about it needs verifying.
A new phone doesn't automatically restore access to every account you had passkeys for. It restores access to your passkey provider, and from there, to whichever passkeys that provider has synced.
Where they're offered, yes, generally, but it's worth checking a few things first rather than tapping "Create a passkey" on autopilot:
You don't need to convert every account at once. Passkeys and passwords can coexist on the same account for as long as a site allows it, so a gradual switch, starting with the accounts that matter most, is a reasonable way to do this.
Is a passkey the same as a fingerprint or Face ID?
No. Your fingerprint or face scan is just how you approve using the passkey that's already stored on your device. The passkey itself is a cryptographic credential; your biometric data never leaves your device and is never sent to the website.
Can I use a passkey without biometrics?
Yes. A device PIN or pattern works the same way a fingerprint or face scan does, as the unlock step that authorizes the passkey. Which options are available depends on your specific device and passkey provider.
Do I still need a password after creating a passkey?
Often, at least for a while. Whether a site lets you remove the password entirely, keeps it as a fallback, or requires it for certain actions varies by service. Don't assume it's safe to delete your password just because you've added a passkey, check that specific site's settings first.
Do passkeys replace two-factor authentication?
They change what two-factor authentication looks like more than they eliminate it. A passkey already combines something you have (your device) with something you are or know (your biometric or PIN), so many services treat a passkey sign-in as satisfying 2FA on its own rather than asking for a separate second step. That's a decision each service makes, not a universal rule, so don't turn off 2FA elsewhere assuming a passkey covers it.
Will clearing my browser cache delete my passkeys?
Not on its own. Cache is temporary, disposable data your browser keeps to load pages faster, it isn't where your passkeys are stored. Your passkeys live with your passkey provider, whether that's your device's built-in credential manager or a separate app. That said, some browser or device cleanup options go further than clearing cache, wiping a browser profile or resetting a credential manager can remove passkeys, so check exactly what any "clear data" option covers before using it. For more on what does and doesn't get removed, see what clearing your browser cache removes.
Do passkeys make me anonymous online?
No. A passkey makes it harder for someone else to sign in as you, which is a different problem from being tracked while you browse. Signing in securely and staying untracked are separate goals, addressed by different tools. For that second one, see how websites track you.
