A passkey replaces passwords with a public-private key pair stored on your device. Learn how passkeys work, how they beat MFA on phishing, and how to implement them.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
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.
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:
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.
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.
Three open standards make passkeys work across browsers and devices:
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.
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.
When you create an account or add a passkey to an existing one, the process unfolds like this:
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.
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.
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
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:
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.
Not all passkeys behave the same way. The distinction between device-bound and synced passkeys affects both security and convenience.
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 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.
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.
Beyond phishing resistance, passkeys address several attack vectors that plague password-based authentication.
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.
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.
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.
Passkeys aren't perfect. Understanding the trade-offs helps you decide when and how to use them.
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
