What Is Passkey Authentication and How Does It Work?

A passkey is a cryptographic credential that replaces passwords with a public-private key pair stored on your device. Instead of typing a shared secret, you authenticate with a fingerprint, face scan, or device PIN, and the private key never leaves your hardware.

That's the short version. The longer version is more interesting: passkeys aren't just a new login method, they're a different security model entirely. The server stops storing anything an attacker could meaningfully steal. Phishing stops working because the credential is bound to the real domain. Credential stuffing stops working because the credential is unique per site. This guide walks through how passkey authentication works under the hood, how it compares to passwords and traditional MFA, and what developers need to know to implement it. For the broader landscape of modern login methods, our overview of passkeys covers where each one fits.

Key Takeaways

A passkey replaces a password with a public-private key pair. The private key lives in secure hardware on the user's device and never leaves it.
Passkeys are phishing-resistant by design because they're cryptographically bound to the legitimate domain. A fake site has no matching key.
A server breach exposes only public keys, which cannot authenticate. Credential stuffing and offline cracking attacks become irrelevant.
Passkeys satisfy MFA requirements in a single step: device possession plus biometric or PIN. No SMS codes, no separate authenticator apps.
Synced passkeys via iCloud Keychain, Google Password Manager, or Microsoft Account give consumer-grade convenience. Device-bound passkeys (hardware keys) give enterprise-grade guarantees. Most production systems support both.

What Is Passkey Authentication

A passkey is a digital credential that replaces your password with a cryptographic key pair. Instead of typing a password, you authenticate using biometrics like Face ID or a fingerprint, or your device's screen lock. One half of the key pair lives on your device, the other half lives on the website, and together they prove you're you.

The two halves work differently:

Public key: Stored on the website's server, used only to verify your identity.
Private key: Stored in secure hardware on your device, never shared with anyone.

Because the private key never leaves your device, a server breach exposes nothing useful to attackers. Passwords are shared secrets where both you and the website know them, which is why even hashed passwords require careful tuning. Passkeys flip that model entirely.

How Does Passkey Authentication Work

Passkeys use public-key cryptography, the same math that secures HTTPS connections and encrypted messaging apps. When you register a passkey, your device creates a unique key pair. When you sign in, your device proves it holds the private key by signing a challenge from the website.

The Role of WebAuthn, FIDO2, and CTAP

Three open standards make passkeys work across browsers and devices:

WebAuthn: The browser API that websites call to request passkey operations.
FIDO2: The umbrella standard defining how passwordless authentication works.
CTAP: The protocol connecting external authenticators like hardware security keys or phones to your computer.

Apple, Google, Microsoft, and every major browser support all three standards. You don't need to memorize the acronyms. What matters is that passkeys work consistently everywhere because of them. For a deeper look at the WebAuthn protocol itself, see WebAuthn and passkeys demystified.

Public Key Cryptography Behind Passkeys

Your device generates two mathematically linked keys. The private key signs data. The public key verifies that signature. The critical part: you cannot derive the private key from the public key, even with enormous computing power.

The private key lives in protected hardware (Apple's Secure Enclave, Android's hardware security module, or a TPM chip on Windows). Even if malware compromises your operating system, extracting the private key from this isolated environment is not feasible with current technology.

Step 1. Passkey Registration

When you create an account or add a passkey to an existing one, the process unfolds like this:

The website sends your device a registration request containing its domain name.
Your device prompts you to verify with biometrics or PIN.
Your device generates a fresh key pair unique to that website.
The public key travels to the website. The private key stays in secure storage.

Each passkey belongs to exactly one website. Your bank gets one key pair, your email provider gets another, and so on. Reusing credentials across sites becomes impossible by design.

Step 2. Passkey Sign-In

Authentication follows a challenge-response pattern. The website sends a random cryptographic challenge to your device. Your device prompts you to verify with a fingerprint, face scan, or PIN. Then your device signs the challenge with your private key and sends the signed response back. The website verifies the signature using your stored public key.

The whole exchange typically finishes in under two seconds. You can also authenticate across devices by scanning a QR code on a laptop with your phone. Bluetooth confirms you're physically nearby.

Passkeys vs Passwords

The core difference comes down to shared secrets versus asymmetric cryptography. With passwords, both you and the website know the same secret. With passkeys, only your device knows the private key.

Aspect	Passwords	Passkeys
What's stored on the server	The password or a hash of it	Only the public key
Phishing risk	High (you can type it into a fake site)	None (bound to the real domain)
Memory required	Yes, for every account	No
Reuse across sites	Common and dangerous	Impossible by design
Value after a breach	Credentials can be tested everywhere	Public keys cannot log in

When attackers breach a password database, they gain credentials they can crack and reuse. When they breach a passkey database, they get public keys, which are mathematically useless for authentication. For the broader context on what makes modern auth different, see auth and modern software.

Stolen credentials appear in 39% of all breaches and remain the primary method attackers use to move laterally, escalate privileges, and monetize access after initial entry - 2026 Data Breach Investigations Report

Passkeys vs MFA and One-Time Passwords

Traditional multi-factor authentication adds a second step on top of your password, usually an SMS code or authenticator app. Passkeys take a different approach by combining multiple factors into one action.

When you authenticate with a passkey, you prove three things simultaneously:

Something you have: The device storing your private key.
Something you are: Your biometric (fingerprint or face scan).
Something you know: Your device PIN as a fallback.

Passkeys satisfy MFA requirements without the friction of copying codes from a separate app. No waiting for SMS messages, no switching between apps, no typing six-digit codes before they expire. For a deeper view of how risk-driven step-ups complement passkeys, see adaptive authentication.

Device-Bound Passkeys and Synced Passkeys

Not all passkeys behave the same way. The distinction between device-bound and synced passkeys affects both security and convenience.

Device-Bound Passkeys

A device-bound passkey exists on exactly one device, typically a hardware security key like a YubiKey. If you lose that device, the passkey is gone. No cloud backup exists that could theoretically be compromised.

Enterprise environments and high-security applications often prefer device-bound passkeys because they offer the strongest guarantees, often layered into broader SSO building blocks for workforce identity. The trade-off is that losing the device means losing access.

Synced Passkeys

Synced passkeys replicate across your devices through encrypted cloud storage. Apple uses iCloud Keychain, Google uses Google Password Manager, and Microsoft syncs through your Microsoft account. If you lose your phone, your passkeys remain accessible from your other devices.

For most consumer use cases, synced passkeys balance security with practicality. You get phishing resistance and cryptographic authentication without the risk of permanent lockout from a lost device.

Why Passkeys Are Phishing-Resistant

Passkeys cannot be phished because they're cryptographically bound to a specific domain. Your device checks the website's actual domain before signing any challenge.

Consider a concrete scenario: an attacker sends you an email with a link to "secure-bank-login.com" instead of your real bank's domain. When you click the link and try to sign in, your device looks for a passkey registered to "secure-bank-login.com" and finds nothing. The legitimate passkey for your real bank won't even appear as an option.

There's nothing to type, nothing to copy, and nothing to accidentally hand over. The cryptographic binding happens automatically without requiring you to spot a suspicious URL. For the broader picture on how phishing, credential stuffing, and password spraying attack credential systems, see common authentication attack vectors.

Security and Privacy Benefits of Passkeys

Beyond phishing resistance, passkeys address several attack vectors that plague password-based authentication.

No Shared Secrets on the Server

When a website stores passwords, even hashed ones, a breach can expose credentials that attackers crack offline. With passkeys, the server holds only public keys. A database breach reveals nothing useful because public keys cannot authenticate. They can only verify.

Resistance to Credential Stuffing and Account Takeover

Credential stuffing attacks use username and password combinations leaked from one breach to try logging into other services (which is why password-driven systems still need breached password detection as a baseline). Since passkeys are unique per site and cannot be reused, credential stuffing becomes irrelevant. A passkey from one service simply does not work anywhere else.

Per-Site Key Pairs and User Privacy

Each passkey generates a unique identifier for each website. Unlike federated login where you might use "Sign in with Google" everywhere, passkeys don't create a shared identifier that websites could use to correlate your activity across services. For the wider picture of where passkeys fit in customer-facing identity, see what CIAM is and the top 5 CIAM trends for 2026.

Limitations and Downsides of Passkey Authentication

Passkeys aren't perfect. Understanding the trade-offs helps you decide when and how to use them.

Account recovery complexity: If you lose all your devices and haven't configured synced passkeys, recovery depends entirely on the website's fallback process.
Ecosystem fragmentation: Moving passkeys between Apple, Google, and Microsoft ecosystems is improving but not yet seamless.
Adoption gaps: Many websites still don't support passkeys, though adoption is accelerating.
Shared account challenges: Passkeys tie to individual devices, making shared accounts like a family streaming login harder to manage.
Learning curve: Users accustomed to passwords may find the transition unfamiliar initially.

How to Implement Passkey Authentication

For developers building applications, passkey implementation involves several components working together. Teams currently on a SaaS identity platform and considering passkey support often weigh this against migrating off legacy auth (see why enterprises are leaving Auth0 for Ory and Auth0 alternatives that ship passkeys out of the box).

Step 1. Configure a Relying Party and WebAuthn Server

The "relying party" is your application, the entity requesting authentication. Your server generates challenges, validates responses, and stores public key credentials. Handling the WebAuthn protocol correctly requires origin validation and attestation verification.

Step 2. Build the Registration Ceremony

On the client side, you call navigator.credentials.create() with options specifying your relying party ID, user information, and supported authenticator types. The authenticator creates the key pair and returns an attestation object. Your server validates the attestation and stores the public key credential.

Step 3. Build the Authentication Ceremony

For sign-in, your server generates a fresh challenge. The client calls navigator.credentials.get(), the authenticator signs the challenge, and your server verifies the assertion against the stored public key. Each authentication uses a new challenge to prevent replay attacks.

Step 4. Handle Account Recovery and Fallback

Allowing users to register multiple passkeys across different devices reduces lockout risk. Clear guidance for adding backup passkeys helps users protect themselves. A secure recovery flow handles cases where users lose access to all their authenticators.

By streamlining the sign-up and login journey, the company achieved a significant 20% increase in registrations for its mobile apps, directly converting a smoother user experience into measurable customer growth.

Tanner Sansbury, Distinguished Engineer, RetailMeNot (View the case study)

Run Passkey Authentication in Production With Ory

Implementing WebAuthn correctly involves real complexity: challenge generation, attestation validation, credential storage, and cross-device flows. Ory Kratos provides built-in passkey support with an API-first, headless architecture that handles the protocol details while giving you full control over the user experience. The recent Kratos v25.4 release added passwordless SMS login and Android WebAuthn passkey support, expanding what works out of the box. Whether you deploy open source, self-hosted with an enterprise license, or on Ory Network's managed infrastructure, passkey authentication works out of the box.

Add passkeys to your app with Ory Kratos

Frequently Asked Questions About Passkey Authentication

What Happens if I Lose the Device That Stores My Passkey?

If you use synced passkeys, your credentials back up to your cloud account and remain accessible from other devices in that ecosystem. For device-bound passkeys, you'll use a backup passkey or go through the site's account recovery process.

Can Passkeys Be Phished or Stolen?

No. Passkeys are cryptographically bound to the legitimate website's domain, so they cannot authenticate to a fake site. The private key never leaves your device's secure hardware and cannot be extracted.

Do Passkeys Work Across Different Browsers and Operating Systems?

Yes. Passkeys are built on the WebAuthn standard supported by all major browsers and operating systems. Cross-device authentication via QR code and Bluetooth lets you use a phone's passkey to log into a different platform.

Are Passkeys the Same as WebAuthn and FIDO2?

Passkeys are credentials created using the WebAuthn API, which is part of the FIDO2 standard. WebAuthn and FIDO2 define the technical protocols. "Passkey" is the user-friendly term for the resulting credential.

Do Passkeys Replace Multi-Factor Authentication?

Passkeys inherently provide multi-factor security by combining device possession with biometric or PIN verification. For most use cases, a passkey satisfies MFA requirements without a separate second factor.

See Ory Kratos for passwordless authentication

Passkeys aren't a marginal upgrade over passwords. They're a different security model that removes the shared secret entirely, breaks phishing as an attack pattern, and makes credential stuffing mathematically irrelevant. The teams shipping passkey support today get measurable conversion and security wins. The teams waiting are giving attackers more time to keep using the techniques passkeys make obsolete. For the broader picture on where passkeys fit in modern identity infrastructure, the customer identity and access management hub covers the full authentication landscape.