Passkeys are usually sold with two claims: they are easier than passwords and they stop phishing. The first is mostly true. The second is true for a specific, mechanical reason that is worth understanding — because it also explains what passkeys do not protect against.
What a passkey actually is
The FIDO Alliance, the industry body behind the standard, defines a passkey as a FIDO authentication credential: a cryptographic key pair tied to one account on one service. When you create a passkey, your device generates the pair. The private key never leaves your device (or your synced credential manager). The service stores only the public key, which is useless on its own for signing in as you.
Signing in is a challenge-and-response: the service sends a random challenge, your device signs it with the private key after you unlock it with the same fingerprint, face scan, or PIN you use to unlock the device, and the service verifies the signature against the stored public key.
Two consequences follow directly. There is no shared secret to type, reuse, or lose in a breach — a site that leaks its public keys has leaked nothing that lets an attacker impersonate you. And there is nothing to phish in the usual sense, which leads to the second property.
Why phishing mostly fails against passkeys
A passkey is created for a specific domain, and the browser or operating system only offers it on that domain. A lookalike page at a near-identical address cannot request the credential for the real site, and a credential created for the lookalike is worthless against the real account. This origin binding — inherited from the underlying FIDO2 standards, WebAuthn and CTAP — is the entire basis of the phishing-resistance claim. It is a property of the protocol, not of user vigilance, which is why passkeys hold up better than one-time codes: a code can be relayed to the real site in real time, while a passkey signature for the wrong origin cannot.
Adoption is no longer hypothetical. The FIDO Alliance reported in October 2024 that services including Adobe, Amazon, Apple, eBay, Google, Microsoft, PayPal, Shopify, and TikTok supported passkeys, with more than 13 billion user accounts able to use them. Amazon has since said more than 500 million of its customers have enabled passkeys. Those are industry-reported figures, but the direction is not in dispute.
Synced passkeys versus device-bound passkeys
The FIDO Alliance describes two forms. Synced passkeys are stored by a credential manager — Apple Passwords, Google Password Manager, or a third-party manager — and follow you across your devices, with sync protected by end-to-end encryption. Device-bound passkeys live on one authenticator, such as a hardware security key, and never leave it.
The trade-off is the familiar one. Sync is what makes passkeys survivable when a phone is lost, and it is what most people should use for most accounts. A hardware key removes the credential from the sync system entirely, at the cost of managing a physical object and a spare. For an email account that resets everything else, the hardware option deserves consideration.
What passkeys do not do
They do not fix recovery. If a service lets anyone reset access with an emailed link or a support call, that path remains exactly as attackable as before. Passkeys raise the strength of sign-in; recovery is a separate door, and on many services it is still the weaker one.
They do not protect a compromised device. Malware running with your session after you have signed in does not care how you signed in.
They do not remove the password everywhere. Many services keep a password as a fallback sign-in method. Until that fallback is removed, the account's resistance is the weaker of the two methods.
They are not anonymity. A passkey identifies your account to the service more reliably, not less. It protects the account; it says nothing about what the service records once you are in.
A sensible order for turning them on
Start with the accounts everything else depends on: primary email first, then banking and financial services, then the rest as services offer them. When a service offers both a passkey and the option to remove SMS codes as a second factor, take both steps — a passkey plus an SMS fallback is only as strong as the fallback. Keep recovery information current, and if you use synced passkeys, protect the Apple or Google account that holds them with the strongest options it offers, because it has effectively become the master key.