One-paragraph summary
When you "create a passkey for northgate.edu," your device generates a fresh public/private key pair. It hands the public key to Northgate's server. The private key never leaves your device. To log in later, Northgate sends a random challenge; your device signs it with the private key; Northgate verifies the signature with the public key it stored. The shared-secret problem is gone — there is no secret to leak in a database breach, and nothing for you to type into a phishing form.
The standard is FIDO2, jointly developed by the FIDO Alliance and W3C, made up of the WebAuthn browser API and the CTAP2 protocol between the browser and an authenticator (a security key, a phone, or your OS keychain). "Passkey" is the consumer-friendly name; the underlying protocol is the same one enterprises have used with hardware tokens since 2014.
The full flow, both directions
northgate.edu), the user's account ID, and policy info (e.g. require a user gesture).northgate.edu. The private key never leaves.rpId: northgate.edu.northgate.edu. If not, the assertion never runs. No prompt to the user, no override option.The cryptographic point: the signed assertion includes the origin field. Even if a relay attacker captured the signature, it would be signed for the attacker's origin, not for northgate.edu — and the server would reject it.
Try the origin check
Two browser tabs, both asking you to "sign in with a passkey." The legitimate one is on northgate.edu. The phishing site is on northgate-edu.cn. Click each. Watch the browser's response.
The browser made the security decision, not the user. There is no “I'm sure, do it anyway” button. This is the property that makes passkeys structurally phishing-resistant.
Where the passkey actually lives
Two flavors of passkey exist, differing in where the private key is stored and whether it syncs.
| Type | Where it lives | Synced? | Best for |
|---|---|---|---|
| Device-bound | Hardware security key (YubiKey, Titan) or Trusted Platform Module on a managed device. | No — key never leaves the device. | Enterprises requiring hardware attestation. Highest assurance. |
| Synced platform passkey | OS keychain (iCloud Keychain, Google Password Manager, Windows Hello / 1Password / Bitwarden). | Yes — end-to-end encrypted across your devices. | Consumers. Survives losing a phone (sync recovers); usable on any of your devices. |
Most consumer "passkeys" today are synced platform passkeys. Trade-off: easier recovery + cross-device convenience, at the cost of trusting the platform vendor's sync infrastructure (and whatever account recovers that). For most users this is the right trade. For threat models where compromising an Apple ID or Google account is the attack you care about, device-bound hardware is still the right answer.
Passkey vs password — what changes for users
| Concern | Password world | Passkey world |
|---|---|---|
| Memorizing | You have to remember it (or use a manager). | Nothing to remember. Device unlocks it. |
| Typing | You type it. It's seen by anything that can read keystrokes. | You don't type it. There is nothing to type. |
| Reuse | You probably reuse it across sites. | Cannot be reused — each site gets a unique key. |
| Phishing | You're the last line of defense. | The browser is. You can't be tricked into using a passkey on the wrong site. |
| Server breach | Hashes leak; offline cracking begins. | Only public keys leak. They are useless to an attacker. |
| Recovery | "Forgot password" + email. | Sync from another device, or fall back to a registered second method. |
Caveats and open problems
- Recovery is still the hard problem. When you lose every device with the passkey, you need a fallback. The fallback is usually email-based, which collapses the strength of the chain to email security. Solving recovery without re-introducing phishing is an open design problem.
- Cross-vendor sync is awkward. An iPhone passkey syncs to your Mac via iCloud but not to your Pixel. The FIDO Alliance's Credential Exchange Protocol (CXP), in development, aims to fix this.
- Enterprise deployment is uneven. Microsoft Entra, Google Workspace, Okta all support passkeys, but legacy on-premise systems (LDAP, RADIUS, anything Kerberos-only) need additional bridging.
- Downgrade attacks. If a site offers both passkey and password, the attacker just phishes the password. Sites need to disable password fallback once a user has registered a passkey — few do this yet.
- The biometric is local. If your laptop is unlocked and unattended, anyone who walks up and triggers Touch ID can use your passkey. The device's lock screen is now the perimeter.
Where the industry actually is
- Apple, Google, Microsoft all rolled out consumer passkey support starting in 2022; default behavior across iOS, macOS, Android, Windows 11.
- Major sites with passkey support (2026): Google, Apple, Microsoft, Amazon, Adobe, eBay, GitHub, Shopify, PayPal, Best Buy, Robinhood, Kayak, and most password managers.
- Government adoption: CISA's Phishing-Resistant MFA guidance (2022 onward) effectively names FIDO2/passkeys as the only acceptable production MFA for federal high-value assets.
- NIST SP 800-63-4 (published 2024) elevates phishing-resistant authenticators to a required tier for higher Authentication Assurance Levels.