---
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-10-02T13:10:07.859Z'
keywords: 'passkeys explained, how do passkeys work, passkeys vs biometrics, phishing-resistant authentication, WebAuthn, CTAP'
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 and does not depend on user training.** A
  passkey is bound to the real domain's Relying Party ID and the browser never offers it
  elsewhere.
- **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.

## 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](https://www.corbado.com/blog/passkeys-stakeholder). 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](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/faq/is-face-id-passkey) 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](https://www.corbado.com/blog/qr-code-login-authentication) with the phone that has one. This is
  [cross-device authentication](https://www.corbado.com/blog/proximity-exchange-protocol-pxp).

### 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](https://www.corbado.com/blog/passkeys-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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-providers).
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](https://www.corbado.com/blog/passkey-providers), 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](https://www.corbado.com/glossary/icloud-keychain),
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) or
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis), 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](https://www.corbado.com/glossary/authenticator), a [security key](https://www.corbado.com/glossary/security-key) or a
[platform authenticator](https://www.corbado.com/glossary/platform-authenticator) such as
[Windows Hello](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/authenticator) can attest, meaning they prove to your server
which [authenticator](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/nist-passkeys). Syncable [authenticators](https://www.corbado.com/glossary/authenticator) are ruled
out at that level by name and top out at [AAL2](https://www.corbado.com/blog/nist-passkeys), 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](https://www.corbado.com/glossary/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 but never binds 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](https://www.corbado.com/faq/are-passkeys-device-specific) do not
sync, so a backup [authenticator](https://www.corbado.com/glossary/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**, the Client-to-Authenticator-Protocol, is the protocol between the client and
  an [external authenticator](https://www.corbado.com/glossary/external-authenticator) such as a
  [security key](https://www.corbado.com/glossary/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.

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](https://www.corbado.com/blog/world-passkey-day-passkey-benchmark-2026) the
[FIDO Alliance](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/nist-passkeys) 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** 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](https://www.corbado.com/glossary/conditional-ui) is broadly available across current browsers
and platforms. [Conditional create](https://www.corbado.com/blog/conditional-create-passkeys) 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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+ 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](https://www.corbado.com/blog/paypal-passkeys), 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](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/blog/vicroads-passkeys) 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](https://www.corbado.com/blog/passkeys-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.