Passkeys Explained: How They Work, Why They Beat Passwords and Where They Still Fall Short
A passkey is a login credential made of a cryptographic key pair instead of a shared secret. You unlock it with whatever unlocks your phone or laptop (a fingerprint, your face, a PIN), and the website never receives anything it could leak or that you could be tricked into typing somewhere else. Passkeys are the consumer name for FIDO2 credentials, and Apple, Google and Microsoft have supported them since 2022. They fix the two biggest problems with passwords, phishing and reuse, almost completely. They also introduce new problems, mostly around what happens when you lose your devices or want to switch ecosystems. This page covers how they work, what they protect against, and where the weak spots are as of October 2026.
How a passkey works
Passkeys rest on public-key cryptography, the same idea behind HTTPS certificates and signed software. Two standards define them. WebAuthn, a W3C specification, is the browser API websites call. CTAP (Client to Authenticator Protocol), from the FIDO Alliance, is how the browser talks to the authenticator, the thing that holds the key. Together they are called FIDO2.
Registration goes like this:
- You choose “create a passkey” on a site such as github.com.
- Your authenticator (the phone’s secure hardware, a password manager, or a USB security key) generates a fresh key pair just for that site.
- The private key stays with the authenticator. The public key goes to the site, which stores it alongside your account.
Signing in:
- The site sends a random challenge, a one-time value.
- You approve with a fingerprint, face scan or device PIN. This step, called user verification, happens locally; the biometric never leaves your device.
- The authenticator signs the challenge with the private key and returns the signature.
- The site checks the signature with the public key it stored. If it verifies, you’re in.
The site never holds a secret that would let someone sign in as you. A database breach exposes public keys, which are useless to an attacker. Each passkey is unique to one site, so there’s nothing to reuse and nothing for credential stuffing (trying leaked passwords on other sites) to work with. And since unlocking requires the device plus your biometric or PIN, a passkey counts as multi-factor on its own: something you have and something you are or know.
Why passkeys stop phishing
Phishing resistance is the real reason passkeys matter, and it’s built into the protocol instead of relying on users noticing a fake page.
Every passkey is bound to a relying party ID, normally the site’s domain. When a page asks for a signature, the browser tells the authenticator which domain is asking, and the authenticator only offers passkeys created for that domain. A lookalike site at githuub-login.com can’t request your github.com passkey, because the browser won’t let it claim to be github.com. Even if you fall for the fake page completely, there is nothing to hand over. The signed response also includes the origin it was produced for, so it can’t be replayed elsewhere.
Compare that with SMS codes or authenticator app codes. Modern phishing kits run as a live relay (adversary-in-the-middle): they show you a perfect copy of the login page, pass your password and one-time code to the real site in real time, and steal the session cookie that comes back. Voice phishing works the same way with a human on the phone. Groups like ShinyHunters have used exactly this method against Okta and Salesforce logins, talking employees into typing SSO credentials and MFA codes into a fake portal. Passkeys make that attack fail at the cryptographic level. Microsoft has reported that passkey sign-ins succeed about 98% of the time against 32% for passwords, and run about eight times faster than a password plus a second factor.
Synced and device-bound passkeys
The single biggest design choice in passkeys is whether the private key can leave the device.
| Synced passkeys | Device-bound passkeys | |
|---|---|---|
| Where the key lives | A credential manager (iCloud Keychain, Google Password Manager, 1Password, Bitwarden, Dashlane and others), copied end-to-end encrypted across your devices | One piece of hardware: a YubiKey or other security key, or a TPM or secure enclave set to non-exportable |
| Lose your phone | Passkeys survive on your other devices or after you restore the account | That credential is gone; you need a backup key |
| Security depends on | The security of the cloud account that syncs them | Physical possession of the hardware |
| Typical users | Consumers, most employees | Administrators, high-risk staff, regulated environments |
Synced passkeys are what made passkeys usable for ordinary people. The original FIDO model of one key per device meant losing a phone locked you out of everything; syncing fixed that. The trade-off is that the passkey is now only as strong as the Apple, Google or password-manager account that syncs it. Those accounts are well protected, but they become a single point of failure.
Regulators draw the line here too. NIST’s digital identity guidelines (SP 800-63-4, finalized in August 2025) accept synced passkeys at Authenticator Assurance Level 2, the level most online services need, but forbid them at AAL3, which requires a non-exportable key in protected hardware. In practice, companies give most staff synced passkeys and issue hardware security keys to administrators and anyone with access to sensitive systems.
Platform support
Passkeys work on all the major platforms now, though details differ.
- Apple: synced via iCloud Keychain since iOS 16 and macOS Ventura (2022). Third-party passkey providers can plug in since iOS 17 and macOS 14. iOS 26 added an account creation API that signs a new user up with a passkey from the start, automatic upgrade of password accounts to passkeys after a password sign-in, and import and export between credential managers.
- Google: synced via Google Password Manager on Android 9 and later and in Chrome. Third-party providers on Android 14 and later.
- Microsoft: Windows Hello can create and use passkeys, and Windows 11 can sign in with a phone over the cross-device flow. Third-party passkey provider support arrived with Windows 11 version 25H2. Since May 2025, new Microsoft consumer accounts are passwordless by default, and Microsoft said at the time that it was seeing nearly a million passkey registrations a day.
- Cross-device sign-in (the FIDO “hybrid” flow) lets you use a passkey on your phone to log in on a computer that doesn’t have it: the computer shows a QR code, the phone scans it, and Bluetooth proximity checks that the phone is physically nearby. The proximity check stops a remote attacker from relaying the QR code.
On the site side, a FIDO Alliance survey from April 2025 found that 48% of the world’s top 100 websites support passkeys, and that 69% of consumers surveyed had enabled at least one. Amazon, Google, Microsoft, PayPal, GitHub, TikTok and a growing number of banks and retailers offer them.
Moving passkeys between managers: CXP and CXF
For years the strongest complaint about passkeys was lock-in. A password can be exported to a CSV file (insecurely, but it works); a passkey created in iCloud Keychain could not be moved to 1Password or Google Password Manager. Users had to create a new passkey on every site after switching.
The FIDO Alliance’s answer is a pair of specifications written with Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, NordPass, Samsung and SK Telecom:
- Credential Exchange Format (CXF) defines a standard data structure for passkeys, passwords and related data. It reached Proposed Standard status, with errata, on March 9, 2026.
- Credential Exchange Protocol (CXP) defines an encrypted way to transfer that data between two providers, on the same device or across devices. It was still a working draft as of October 2026.
Implementations have arrived ahead of CXP’s final version. iOS 26 (September 2025) lets you export passkeys and passwords from one credential manager app to another on the same device, approved with Face ID instead of an unencrypted file. Android 14 and later gained import and export through a Google Play services update in July 2026. Full cross-platform transfer, for example from an iPhone to an Android phone, depends on CXP being finished and adopted.
Where passkeys still fall short
Account recovery is the weak point. A passkey is only as strong as the easiest other way into the account. Most services still let you fall back to a password, an email link or an SMS code when “you’ve lost your passkey,” and attackers simply pick that route. The same goes for help desks that reset credentials over the phone, which is how many 2025 and 2026 breaches began. Turning on passkeys without removing or hardening the fallbacks leaves the front door locked and the side window open.
The sync account becomes the crown jewel. With synced passkeys, whoever takes over your Apple Account, Google Account or password manager vault gets every passkey in it. Protect those accounts with their own passkey or a hardware key, and set up recovery contacts or recovery keys before you need them.
Session theft still works. A passkey protects the login. It doesn’t protect the session cookie issued afterwards. Infostealer malware that copies cookies from a browser bypasses passkeys entirely. Device-bound session credentials, which tie a cookie to a key on the device, are the emerging fix but are not yet widespread.
Inconsistent experience. Sites word passkey prompts differently, some create several passkeys for one account, some don’t show passkeys in account settings at all, and some require a password to manage the passkey. Shared accounts (a family streaming login, a team mailbox) don’t map cleanly onto per-person keys.
Enterprise fit. Large organizations need attestation (proof of which authenticator model created a key), lifecycle control and audit trails. Synced consumer passkeys don’t offer all of that, which is why enterprise deployments mix synced passkeys with managed hardware keys, often alongside a zero trust access model that keeps checking the device after login.
The cryptography itself will need replacing. Today’s passkeys use elliptic-curve signatures (usually ECDSA with P-256), which a large quantum computer could break. Because passkeys are signatures and not encryption, there’s no harvest-now risk: a recorded login can’t be replayed. But the ecosystem will eventually need to move to algorithms like ML-DSA, covered in the explainer on post-quantum cryptography.
The practical takeaway
For individuals: turn on passkeys wherever they’re offered, starting with email, your Apple or Google account, your password manager and your bank, and protect the account that syncs them as carefully as anything you own. Keep a recovery method you control, and once passkeys are working, remove SMS as a fallback where the site allows it.
For organizations: passkeys solve phishing only if the fallbacks go too. Pair them with strict recovery and help-desk procedures, use hardware keys for privileged accounts, and keep watching for session theft. The same pattern of public-key authentication shows up in enterprise WiFi with 802.1X and RADIUS, where certificate-based EAP-TLS has long beaten passwords for the same reasons. For the vocabulary around all of this, see the cybersecurity glossary, and for how the vulnerabilities that slip past strong logins get tracked, see the guide to CVE, CVSS and CISA KEV.