Passkeys explained clearly: The complete Guide [2026]

1. Introduction: why passkeys still need a clear explanation#

Passkeys are no longer new. The standard is mature, every major platform ships support and the largest consumer services have rolled them out. Yet in most engineering and security teams the same three confusions keep coming back: passkeys get mixed up with the fingerprint unlock an app already has, "FIDO token", "OTP" and "passkey" get used interchangeably, and teams that have shipped passkeys are surprised when almost nobody uses them.

This article is the explanation we use when we have to make passkeys clear to a mixed audience of developers and business stakeholders. It is built around three questions:

1. What is a passkey? A mental model you can repeat, plus what users actually see.
2. How does it work and why can it not be phished? The mechanism, in enough detail to defend it in a security review.
3. How do you drive adoption? Because implementing passkeys and getting them used are two very different problems.

If you only take one thing away, take this: people unlock their phones with their face or fingerprint dozens of times a day. Passkeys reuse exactly that gesture for login. The technology is new, but to users it feels familiar from day one if implemented correctly.

2. What is a passkey?#

2.1 A passkey replaces the password with a key pair, not with a shared secret#

A passkey is a secure replacement for the password, standardized by the FIDO Alliance, the industry body that Apple, Google, Microsoft and hundreds of other companies build against. Instead of a shared secret that both sides know, the user authenticates with a cryptographic key pair stored on their device and approves with the same biometric they use to unlock the phone.

Three reasons this is better than a password, in the order we will work through them:

• User experience. Logins get faster and succeed more often, because there is nothing to remember, type or wait for.
• Security. Phishing resistance is a property of the protocol. It does not depend on the user spotting a fake site.
• Cost. Every passkey login is an SMS OTP that does not have to be sent. At consumer scale that is a real line in the budget.

2.2 What users see: three flows, no app and no hardware to buy#

There is no app to install and no hardware token to hand out. Everything runs on devices users already own:

• Creating a passkey: confirm with Face ID or the fingerprint sensor, done. Users who are already signed in enter nothing at all, a username only comes into play at account creation.
• Logging in: tap the username field, the passkey autofills, confirm once.
• Logging in on a device with no passkey: scan a QR code with the phone that has one. This is cross-device authentication.

2.3 Passkeys vs. local biometric authentication: same face, different job#

This is the single most common question from teams whose app already uses fingerprint unlock: we already have biometrics, what is different?

Local biometric authentication unlocks something on one device. It never talks to a server, so the server learns nothing and gets no security guarantee from it. A passkey signs the user in to a service: the server verifies the signature, it works across devices and it is bound to the real domain, which is what makes it phishing-resistant.

If a team remembers one table from this article, it should be this one. Same gesture, completely different job.

2.4 How passkeys work technically: register once, then sign a challenge#

Under the hood the flow has three steps and no secret ever moves in a way that an attacker can reuse:

1. Registration. The device creates a key pair. The public key goes to the server once. The private key stays on the user's side, held by the passkey provider.
2. Challenge. At login the server sends a random, one-time challenge.
3. Signed challenge. The device signs it with the private key after the user authenticates locally and the server verifies the signature with the public key it already has.

Nothing secret is ever transmitted to the server or stored there. The user database stops being a honeypot of password hashes and becomes a list of public keys that are worthless to steal.

In one sentence: passkeys are two-factor authentication in disguise. Something you have, the device holding the private key, and something you are, your face or fingerprint, in a single gesture. If the local authentication is a PIN or a pattern, the second factor is something you know instead.

2.5 Synced vs. device-bound passkeys: reach versus sole control#

The private key lives with a passkey provider, and that is where the standard gives you a choice that gets mixed up constantly.

Synced passkeys live in a provider such as iCloud Keychain, Google Password Manager or 1Password, end-to-end encrypted, and they follow the user to their other devices. This is what consumers get by default and it is what solves account recovery.

Device-bound passkeys are created inside the hardware of one authenticator, a security key or a platform authenticator such as Windows Hello, and the private key never leaves it. There is no sync, and that is the point.

Two consequences matter for implementation teams. Device-bound authenticators can attest, meaning they prove to your server which authenticator model produced the signature, and their private key cannot be exported, which is exactly what NIST SP 800-63B Revision 4 demands at AAL3. Syncable authenticators are ruled out at that level by name and top out at AAL2, which is still the right target for almost every consumer service, as we have worked through in our NIST passkeys analysis. Synced passkeys give you reach and recovery instead. The trade-off in one line: reach versus control. Consumer services lead with synced, regulated access and administrator accounts use device-bound and many services offer both.

3. Why passkeys cannot be phished#

3.1 Every MFA method beats a password, only passkeys survive phishing#

To be fair to what most services run today: every MFA method beats a bare password. If you use SMS OTP, you already protect against guessing and credential reuse.

The row that separates them is phishing. SMS, TOTP and push notification all fail there, because a convincing fake site plus a man in the middle relays whatever code the user types or whatever prompt the user approves.

Push notification is the method teams most often assume is safe, because the prompt arrives out of band, on a separate device and outside the browser. That does not help once an attacker proxies the login in real time. The push is genuine, sent by the real site, and it reaches the user in the same second they expect it, so there is nothing to notice. What the user cannot see is that the session being approved is the attacker's, and the attacker never needs the password at all.

Out-of-band delivery moves the prompt to another device, it does not bind it to the site the user is actually on. That binding is what passkeys add, and it is the subject of the next section.

In the table above, methods marked MFA add a second factor, while PR-MFA stands for phishing-resistant MFA, which only passkeys reach. Passkeys are the only consumer-scale method in that column, and the only one that makes login faster instead of slower. That combination is why regulators now name phishing-resistant authentication explicitly.

3.2 The Relying Party ID binding is what makes phishing impossible#

This is the part worth being able to retell from memory.

When a passkey is created, it is locked to the real domain's Relying Party ID (rpID), and that rpID is stored inside the passkey on the device. At every login the browser checks one thing: does the origin of the page belong to that rpID?

"Belong to" is slightly wider than "is identical to" and the difference matters if you run more than one hostname. The browser accepts the rpID if it is either exactly the origin's domain, or a registrable parent domain of it. A passkey scoped to example.com therefore works on login.example.com as well, while com is on the Public Suffix List and can never be an rpID. Everything outside that relationship is rejected.

On the real site the passkey appears. A look-alike site sits on a different registrable domain, even when the page is a pixel-perfect clone, so the check fails and the passkey simply never shows up. There is no warning to click away and no decision for the user to get wrong. The user cannot be tricked into using a passkey on a fake site, because the browser never offers it.

3.3 Losing the device does not mean losing the account#

The number one user worry is the phone. Synced passkeys come back with the provider account on a new device, so the account survives the loss.

Two honest caveats. Device-bound passkeys do not sync, so a backup authenticator has to be enrolled up front. And once the login itself cannot be phished, attackers move to the weakest remaining path, which is account recovery. Recovery becomes the new front door and needs to be hardened accordingly.

4. The vocabulary: FIDO2, WebAuthn, CTAP and the passkey itself#

Terminology is where most passkey conversations go wrong, because "FIDO token", "OTP" and "passkey" get used as if they were the same thing. Four terms are enough:

• FIDO2 is the overall framework.
• WebAuthn, short for Web Authentication, is the browser API you call in your application.
• CTAP, the Client-to-Authenticator-Protocol, is the protocol between the client and an external authenticator such as a security key.
• The passkey is the credential that comes out of it.

The FIDO Alliance is the standards body behind all of them. That is the whole glossary, and it is enough to decode any passkey discussion.

5. Why passkeys are ready now, not in a few years#

The groundwork is older than the current wave of attention. The FIDO Alliance was founded in 2013 and WebAuthn has been a W3C Recommendation since March 2019, which makes this mature technology rather than an emerging one.

What changed is the platform support. Apple, Google and Microsoft committed to passkeys across their platforms in May 2022, and since then the numbers have compounded. On World Passkey Day 2026 the FIDO Alliance put an estimated 5 billion passkeys in use, with 90% of consumers aware of passkeys, 75% having enabled one on at least one account and 49% using them regularly where they are offered. Those consumer figures come from a Sapio Research study of 11,000 consumers across ten countries, published as The State of Passkeys 2026. On the device side, close to 95% of devices are passkey-ready, so for most services the addressable base is no longer the constraint.

Regulators have followed. Phishing-resistant authentication is named explicitly in guidance from NIST and others, and in India the RBI has moved in the same direction.

6. Driving adoption: creation multiplied by usage#

6.1 Adoption is a product of two numbers and most deployments miss one#

This is where most passkey projects fall short and it is never the cryptography.

Adoption is creation times usage: users saving a passkey, multiplied by users actually signing in with it. Both numbers have to move, because a product with a zero in it stays zero.

Two failure modes show up again and again:

• Created, never used. Users save passkeys, but the login screen still leads with password and OTP, so usage stays near zero and nothing improves.
• Never created. The prompt only lives in a settings menu that nobody opens, so there is nothing to use in the first place.

6.2 Conditional create and conditional UI are the two built-in levers#

The standard gives you one lever for each number.

• Conditional create targets creation. The passkey is saved right after a successful password login, inside a session the user already trusts. No extra screen and no decision to abandon.
• Conditional UI targets usage. Saved passkeys appear directly in the login field, so using the passkey becomes the default path instead of a hidden option.

Their availability is not identical and this is where teams get caught out. Conditional UI is broadly available across current browsers and platforms. Conditional create depends on the active credential provider as well as the browser. Our conditional create guide lists the full set of prerequisites: Safari 18+ or Chrome 136+, no existing passkey for that account, and a credential provider that supports the extension, which today means mainly the first-party managers with third parties following on specific platforms. Windows on the web is the weakest spot. Where the prerequisites are not met the call does not error, it simply does nothing, so both levers need feature detection and a fallback path rather than an assumption that they are always there.

6.3 Field-tested tips: make the passkey the easiest path, then measure both numbers#

Four practices that consistently move the two numbers:

1. Nudge after login. Offer the passkey right after a successful authentication, inside a trusted session, not in a settings menu.
2. Automate the prompt. Automatic and conditional prompts complete far more often than anything the user has to go looking for.
3. Default the login to passkeys. Surface the passkey before the password field, so the passkeys that were created actually get used.
4. Measure creation and usage separately, then expand. Roll out gradually with a fallback in place. A hard cutover is not necessary and rarely survives contact with real users. This is also where most day 2 problems show up.

7. What passkeys deliver in production: faster logins, fewer failures, less fraud#

Published results from large consumer deployments cluster around four outcomes: faster logins, higher login success rates, less account takeover fraud and, where the two levers above were used, real adoption rather than a feature that exists on paper.

Every figure above is public. The sources, in the order they appear:

• Faster logins. VicRoads reports 4x to 6x faster logins after moving 4.8 million customers to passkey-first authentication (FIDO Alliance case study). Microsoft reports 8x faster logins (World Passkey Day 2025 showcase). Mercari reports 3.9x, cutting login from 17 to 4.4 seconds.
• Higher login success. The FIDO Passkey Index aggregates nine large operators, including Amazon, Google, Microsoft and PayPal, and puts passkey sign-in success at 93% against 63% for other methods. Google separately reports 4x higher login success rates, and PayPal reports a 10%+ increase in login success rate.
• Less fraud. CVS Health reports a 98% drop in mobile account takeover fraud across more than 10 million users. PayPal reports 70% lower account takeover rates on passkey-authenticated transactions. NTT DOCOMO reports no unrecognized payments in its online shop since September 2022.
• Real adoption. VicRoads reached 80% activation on mobile and a 30% login rate. KAYAK reports a two-thirds opt-in rate and 50% shorter sign-in time. Intuit reports that more than 85% of customer authentications in its mobile apps now use passkeys.

Our own running collection of these deployments, with the underlying sources, is at state-of-passkeys.io.

8. Conclusion: if you can explain it in one sentence, you understand it#

We started with three questions, so here is what is worth keeping from each of them.

The first was what a passkey actually is. It is the gesture users already know from unlocking their phone, doing a very different job. Local biometrics open a device, a passkey signs a user in to a service. Once that distinction lands, most of the confusion around passkeys tends to go with it.

The second was why it cannot be phished. The passkey is bound to the real domain, so the browser never offers it anywhere else. There is no warning to click away and no judgment call for the user to get wrong, which is why the protection holds even on the day someone is tired and in a hurry.

The third was adoption, and this is the one teams underestimate. Creation times usage is a product, so a strong number on one side is worth nothing while the other side sits at zero. Shipping passkeys and getting them used are two separate pieces of work. The second one is where the return shows up.

There is one honest test of whether an explanation landed: try to give it. Explain passkeys to one colleague, in one sentence. If they get it, the explanation works.