Passwords have a structural problem that no amount of complexity requirements or rotation policies fixes: they're shared secrets. When you authenticate with a password, you're proving you know something that the server also knows. That means the server's password database is a high-value target — breach it, and every user credential is potentially exposed. It also means any system that sees your password in transit, including any phishing site you're tricked into visiting, has everything it needs to impersonate you.
Passkeys — built on the WebAuthn standard and the FIDO2 protocol — replace this model with asymmetric cryptography. Your device generates a key pair: a private key that never leaves the device, and a public key that gets registered with the service. When you authenticate, the server issues a challenge; your device signs it with the private key; the server verifies the signature with the stored public key. The private key is never transmitted and never stored server-side. A breach of the service's database exposes public keys — which are mathematically useless for impersonation.
What a Passkey Actually Is
A passkey is a FIDO2 credential — specifically a WebAuthn credential that lives on a device or security key. It consists of:
- A private key, stored in secure hardware (the device's Secure Enclave, TPM, or a hardware security key) and protected by your device's unlock mechanism (biometric or PIN)
- A public key, stored by the service you're authenticating with
- A credential ID, used to look up the correct key pair during login
Passkeys are origin-bound: each credential is cryptographically tied to the exact domain it was created for. A passkey for havenmessenger.com cannot be used on havenmessenger-login.com or any other domain. This binding is enforced at the protocol level, not by the user's vigilance.
Phishing works by convincing you to enter credentials on a lookalike site. A password entered on a fake site is immediately usable by the attacker. A passkey cannot be used on a different origin — even if you tap "authenticate" on a phishing page, the credential won't work because the origin won't match the one the key was bound to at creation.
How Authentication Works Without a Password
The authentication flow is straightforward once you understand the key exchange:
- You navigate to the service and click "Sign in with passkey" (or the site detects you have one registered)
- The server sends a randomly generated challenge — a nonce that cannot be predicted or reused
- Your device prompts for your local authentication: Face ID, fingerprint, or PIN
- The device uses your private key to sign the challenge, along with the current origin and other data
- The signed response is sent to the server
- The server verifies the signature against your stored public key — if it matches, you're authenticated
The server never sees your biometric data, your PIN, or your private key. It only sees a valid cryptographic signature that proves you control the device holding the private key. The biometric or PIN is purely a local gate — it unlocks the key on your device, nothing is transmitted.
Passkeys vs. TOTP 2FA: A Direct Comparison
TOTP (time-based one-time passwords), the six-digit codes from apps like Authy or Google Authenticator, is currently the most widely deployed form of 2FA. It's substantially better than passwords alone. Passkeys are substantially better than both.
| Property | Password | Password + TOTP | Passkey |
|---|---|---|---|
| Phishing resistant | ✗ | Partial | ✓ |
| Server breach safe | ✗ | ✗ | ✓ |
| No shared secret | ✗ | ✗ | ✓ |
| User memorization required | ✗ | ✗ | ✓ None |
| SIM swap resistant | ✗ | TOTP yes / SMS no | ✓ |
| Works if device is offline | ✓ | TOTP yes | ✓ (synced) |
The "partial" phishing resistance of TOTP deserves explanation. A real-time phishing attack — where an attacker proxies your login session live — can steal a TOTP code within its 30-second validity window. This is the attack that has successfully bypassed 2FA on major services. A passkey cannot be proxied this way because the signed challenge is origin-bound; a proxy cannot produce a valid signature for a different domain.
If you're comparing passkeys to hardware security keys like YubiKeys: hardware keys implement the same FIDO2 protocol passkeys use. A hardware key is a passkey stored on dedicated hardware rather than on your phone or computer. The security properties are equivalent; the form factor differs.
Synced Passkeys and the Cloud Trade-Off
Major platforms — Apple, Google, and Microsoft — sync passkeys across your devices through their respective credential stores (iCloud Keychain, Google Password Manager, Windows Hello). This is convenient: create a passkey on your iPhone and it's available on your Mac. It also introduces a dependency on the cloud sync provider.
The private key material is encrypted before being synced; neither Apple nor Google can access the key in plaintext. The encryption key is derived from your account credentials (iCloud password + device biometrics, or Google account + device unlock). If your cloud account is compromised, the sync protections may not hold.
For high-security use cases, a hardware security key stores the passkey on the device itself and never syncs it. No cloud dependency, no cross-device availability — but also no recovery if the key is lost. For most people, synced passkeys represent a better practical trade-off than passwords, even accounting for the cloud component.
Where Passkeys Fall Short
The current landscape has gaps worth knowing about.
Account recovery. If you lose all your devices and have no backup codes, passkey recovery is service-dependent. Most services fall back to email-based recovery — which reintroduces email account security as a dependency. The strength of your passkey login is now bounded by the strength of your email account.
Cross-platform portability. Passkeys synced via iCloud Keychain don't automatically appear in Google Password Manager, and vice versa. Moving from iPhone to Android requires either re-enrolling passkeys or using a hardware key as the primary credential. This is improving — the FIDO Alliance's Credential Exchange Specification is designed to enable cross-provider passkey migration — but it's not yet universally implemented.
Service adoption. Not all services support passkeys yet. Password managers remain necessary for services that haven't implemented WebAuthn. Passkeys reduce the attack surface where they're available, not universally.
Getting Started
Major services that support passkeys as of 2026 include Google, Apple, Microsoft, GitHub, PayPal, Shopify, and many others. The process is generally: go to security settings, find "passkeys" or "sign-in methods," and follow the enrollment flow. Your device will handle key generation.
If you use a password manager like 1Password or Bitwarden, both now support storing and using passkeys cross-platform, which solves some of the platform lock-in concerns.
Passkeys aren't a silver bullet — they don't protect against a compromised device, a compromised cloud account with access to synced keys, or services that implement them poorly. But they eliminate a wide class of attacks that succeed today: credential stuffing from breached databases, real-time phishing proxies, and SMS interception for account takeover. For the threat model most people face, that's a meaningful improvement worth adopting.