---
url: 'https://www.corbado.com/blog/passkeys-explained-clearly'
title: 'Passkeys explained clearly: The complete Guide [2026]'
description: 'A clear, complete explanation of passkeys: what they are, how they differ from local biometrics, why they cannot be phished, how synced and device-bound passkeys compare and what actually drives adoption in production.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-08-14T11:16:34.067Z'
lastModified: '2026-08-14T11:16:34.067Z'
keywords: 'passkeys explained, what is a passkey, how do passkeys work, passkeys vs biometrics, synced vs device-bound passkeys, phishing-resistant authentication, WebAuthn, FIDO2, CTAP, conditional UI, conditional create, passkey adoption'
category: 'Passkeys Strategy'
---

# Passkeys explained clearly: The complete Guide [2026]

## Key Facts

- **A passkey is a cryptographic key pair**, not a shared secret. The private key stays on
  the user's side, the server only ever holds a public key that is useless to steal.
- **Local biometric authentication and passkeys use the same gesture for different jobs.**
  Local biometrics unlock something on one device, a passkey authenticates a user to a
  service.
- **Phishing resistance comes from the protocol, not from user training.** A passkey is
  bound to the real domain's Relying Party ID and the browser never offers it on a
  look-alike site.
- **Synced and device-bound passkeys are two flavors of one standard.** Synced passkeys
  solve recovery and reach, device-bound passkeys give sole control and attestation.
- **Adoption is creation multiplied by usage.** Most deployments fail on one of the two
  numbers, not on the cryptography.

## 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/parallels-passkeys-cda).

### 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.

![Comparison of passkeys and local biometric authentication across five dimensions: what it does, who verifies you, cross-device support, phishing resistance and device loss](https://www.corbado.com/website-assets/passkeys_vs_local_biometrics_67253dabcc.png)

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.

![Technical view of a passkey login: the user device holds the private key and local authentication, the relying party server holds only the public key, and the three steps register, challenge and signed challenge run between them](https://www.corbado.com/website-assets/passkey_technical_view_2d9edd269a.png)

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.

![Comparison of synced and device-bound passkeys across where the private key lives, sync behavior, device loss, attestation, assurance level and typical use](https://www.corbado.com/website-assets/synced_vs_device_bound_passkeys_3ae3518c62.png)

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](https://pages.nist.gov/800-63-4/sp800-63b.html) 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](https://www.corbado.com/blog/nist-passkeys). 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.

![Man-in-the-middle attack against out-of-band push notification: the victim logs in through a proxied page, the attacker opens a session with the real site, the real site sends a push challenge to the victim's phone, the victim approves it and the attacker ends up with the authenticated session](https://www.corbado.com/website-assets/push_notification_mitm_attack_2abdf82ce4.png)

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.

![Comparison table of password, SMS OTP, authenticator app TOTP, push notification and passkeys against guessing, brute-force, credential reuse, device theft, phishing, server leaks, man-in-the-middle and SIM swapping, plus login speed](https://www.corbado.com/website-assets/passkeys_vs_login_methods_d50a2cb085.png)

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)](https://www.corbado.com/blog/webauthn-relying-party-id-rpid-passkeys)**, 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 legitimate site the passkey prompt appears, on a pixel-perfect look-alike site the browser reports no passkeys available, because the page origin does not match the Relying Party ID stored in the passkey](https://www.corbado.com/website-assets/passkey_phishing_resistance_d71205b35a.png)

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](https://www.corbado.com/glossary/webauthn)**, short for Web Authentication, is the browser API you
  call in your application.
- **[CTAP](https://www.corbado.com/glossary/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](https://fidoalliance.org/overview/history/) and
[WebAuthn has been a W3C Recommendation since March 2019](https://www.w3.org/TR/webauthn-1/),
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](https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/),
and since then the numbers have compounded. On World Passkey Day 2026 the FIDO Alliance put
[an estimated 5 billion passkeys in use](https://fidoalliance.org/fido-alliance-reports-accelerating-global-passkey-adoption-on-world-passkey-day-2026/),
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](https://fidoalliance.org/wp-content/uploads/2026/05/The-State-of-Passkeys-Global-Consumer-and-Workforce-Report-1.pdf).
On the device side, [close to 95% of devices are passkey-ready](https://state-of-passkeys.io/),
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](https://www.corbado.com/blog/rbi-2fa-directives) 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.

![Adoption equals creation multiplied by usage, with the two common failure modes: passkeys created but never used because the login still leads with password and OTP, and passkeys never created because the prompt never comes at the right moment](https://www.corbado.com/website-assets/passkey_adoption_creation_times_usage_8e9a24a442.png)

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](https://www.corbado.com/blog/conditional-create-passkeys)** 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](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill)** 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](https://www.corbado.com/blog/conditional-create-passkeys) 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](https://www.corbado.com/blog/passkey-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.

![Case study overview grouped into four outcomes: faster logins, higher login success rates, less fraud and real adoption, with published figures from large consumer deployments](https://www.corbado.com/website-assets/passkey_case_studies_666dad2ebf.png)

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

- **Faster logins.** [VicRoads](https://www.corbado.com/blog/vicroads-passkeys) reports 4x to 6x faster logins after
  moving 4.8 million customers to passkey-first authentication
  ([FIDO Alliance case study](https://fidoalliance.org/case-study-vicroads/)). Microsoft
  reports 8x faster logins
  ([World Passkey Day 2025 showcase](https://fidoalliance.org/celebrating-world-passkey-day-2025-showcase-of-real-world-passkey-deployments/)).
  [Mercari](https://engineering.mercari.com/en/blog/entry/20230810-mercaris-passkey-adoption/)
  reports 3.9x, cutting login from 17 to 4.4 seconds.
- **Higher login success.** The
  [FIDO Passkey Index](https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/)
  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](https://www.androidpolice.com/google-passkeys-data-faster-dependable-future/),
  and [PayPal](https://www.corbado.com/blog/paypal-passkeys) reports a
  [10%+ increase in login success rate](https://newsroom.paypal-corp.com/2025-01-23-Solving-the-Convenience-and-Security-Equation).
- **Less fraud.** [CVS Health](https://fidoalliance.org/comm_deployment/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](https://fidoalliance.org/passkey-adoption-doubles-in-2024-more-than-15-billion-online-accounts-can-leverage-passkeys/).
- **Real adoption.** VicRoads reached 80% activation on mobile and a 30% login rate.
  [KAYAK](https://www.corbado.com/blog/kayak-passkeys) reports a
  [two-thirds opt-in rate and 50% shorter sign-in time](https://developers.googleblog.com/en/how-kayak-reduced-sign-in-time-by-50-and-improved-security-with-passkeys/).
  [Intuit](https://www.intuit.com/blog/innovative-thinking/tech-innovation/intuit-named-to-fido-alliance-board-in-recognition-of-passwordless-authentication-standards-leadership/)
  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](https://state-of-passkeys.io/case-studies).

## 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.