Passkeys Explained: What Actually Replaces Your Passwords (2026)

A passkey is a cryptographic key pair that signs you in without a password. The site stores the public half; the private half stays on your phone, laptop or security key, unlocked by the same fingerprint, face or PIN that unlocks the device. No shared secret crosses the wire, so there is nothing for a phishing page to capture and nothing in a breached database worth cracking.

That much survives contact with the marketing. What the marketing tends to skip: passkeys come in two kinds with different security classifications, recovery differs on every platform, and moving passkeys between ecosystems is a standard in progress, not a shipped feature. This guide sticks to the primary documents — W3C WebAuthn, NIST SP 800-63B-4, FIDO's credential exchange specs — plus what Apple, Google and Microsoft publish about losing your device.

What a passkey actually is

The specification behind passkeys is W3C WebAuthn. Its formal name for the thing is a client-side discoverable public key credential source — "discoverable" because the site does not need to hand your browser a credential ID first; the authenticator finds the right key on its own, which is what makes username-less sign-in possible. The older names "resident credential" and "resident key" are now explicitly historical, and the Level 3 draft acknowledges what everyone calls them anyway: passkeys.

Registration generates a key pair on your authenticator — a phone, a laptop with a secure enclave, or a hardware security key. The site keeps the public key; the private key, in the spec's words, is "expected to never be exposed to any other party." At sign-in, the site sends a random challenge, the authenticator signs it after you unlock with biometrics or a PIN, and the site verifies the signature. Your fingerprint never leaves the device; it only unlocks the key locally.

To be precise, WebAuthn Level 3 is a Candidate Recommendation Snapshot dated 26 May 2026, not yet a full W3C Recommendation. Level 2, from 2021, still holds that status. We cite Level 3 for terminology, not as a finished standard.

Why a fake site can't ask for it

The claim of phishing resistance holds up because it is structural, not behavioral. Each credential is scoped to a Relying Party ID — essentially the legitimate domain — and per the WebAuthn spec that scoping "is enforced jointly by conforming User Agents and authenticators." Browser and authenticator both check which origin is asking; a look-alike domain is not the Relying Party, so the real credential is never offered to it. There is no code to mistype into the wrong site, because there is no code.

NIST formalises this in SP 800-63B-4 §3.2.5. Phishing resistance means the protocol prevents disclosure of authentication secrets to an impostor verifier "without relying on the vigilance of the claimant" — the guarantee cannot depend on you noticing the URL is wrong. NIST recognises two qualifying methods: channel binding, which it rates more secure, and verifier name binding, which is how WebAuthn qualifies. It is blunt about the alternative: authenticators that involve manually typing a code — SMS codes, app OTPs — "SHALL NOT be considered phishing-resistant." Passkeys beating SMS codes is a standards determination, not vendor positioning.

Synced vs device-bound: where NIST draws the line

NIST 800-63B-4 distinguishes between two kinds of passkeys. A syncable authenticator manages its keys "using a sync fabric (e.g., a cloud provider)" — the consumer passkey in iCloud Keychain or Google Password Manager, the kind that appears on your new phone automatically. The catch is in §3.3.2: because syncing requires the private key to be exportable, syncable authenticators "SHALL NOT be used at AAL3," NIST's highest assurance level. They are permitted at AAL2 — the assurance level NIST permits them at.

That is the honest trade-off. Synced passkeys buy recoverability at the price of the key no longer being provably bound to one piece of hardware. Device-bound passkeys keep single-device assurance and reintroduce the oldest problem in authentication: lose the device, lose the credential.

Losing your phone: recovery on the three platforms

Recovery is where the platforms differ, and each vendor's documentation is more candid than its keynote slides.

Apple's design escrows the keychain so recovery is possible while Apple stays unable to read the contents — the escrow record is wrapped with the public key of an HSM cluster, and your device passcode does the unlocking. Google backs passkey secrets up end-to-end encrypted and leans on Google Account recovery, plus a documented remote-removal step for a lost device. Microsoft is the bluntest about device-bound credentials, and its "digital spare key" advice — register passkeys on more than one device — is worth following on every platform, not just Windows.

Portability: standardising, not arrived

The sharpest question in 2026 is about portability: can you move passkeys between ecosystems? The answer has two parts, at different stages of completion.

The format is real: FIDO's Credential Exchange Format (CXF) became a Proposed Standard on 14 August 2025. It defines the data structures for credentials "being passed or referenced between two applications during credential exchange" — the container for passwords, passkeys and more, designed to be designed for secure transfer between providers.

The transfer protocol is not: the Credential Exchange Protocol (CXP), which would actually move credentials between managers, remains a Working Draft carrying FIDO's own warning that it is "not intended to be a basis for any implementations as the Specification may change." As of 22 July 2026, no Proposed Standard version of CXP appears on FIDO's specification index. Apple has published a credential export API (ASCredentialExportManager) in its developer documentation, which signals direction, but the cross-provider protocol it would speak is still draft.

So: standardised cross-ecosystem migration is arriving, not arrived. Until CXP ships and the platforms implement it, the practical answer is the unglamorous one — register a passkey for each important account in more than one place, rather than counting on moving a single copy later.

Adoption in 2026 — as claimed

The headline numbers all come from one place: the FIDO Alliance's World Passkey Day release of May 2026, based on a survey of 11,000 consumers and 1,400 enterprise decision-makers across ten countries, Singapore among them. FIDO is the industry body promoting passkeys — read these as the promoter's figures, not an independent audit.

Service support is easier to verify from the services themselves. GitHub's documentation states that with two-factor enabled, "passkeys satisfy both password and 2FA requirements, so you can complete your sign in with a single step." PayPal's own pages describe passkey sign-in for Apple and Android users through the app or via Safari and Chrome on the web. Beyond those and the three platform vendors, we have not verified further support claims.

What passkeys don't fix

NIST's phishing-resistance definition protects one thing: the authentication event — disclosure of secrets and authenticator outputs to an impostor verifier. That definition's boundary is the sign-in event itself; it doesn't cover what happens after. A session cookie stolen by malware or replayed by an attacker rides an authentication that was itself phishing-resistant. Passkeys close the front door; they say nothing about the windows.

Shared accounts are the second gap: a passkey is bound to one person's authenticator or sync fabric, and household or team sharing of one account has no first-class story in the core standards.

And at the high-assurance end, the syncable convenience that makes consumer passkeys recoverable is exactly what disqualifies them from AAL3 — sync requires an exportable key, which AAL3 exists to rule out. Organisations with AAL3 obligations still need device-bound authenticators.

Passwords still matter — for years

NIST 800-63B-4 did not retire the password; it modernised it. Passwords remain specified at every assurance level, with rules that finally match the evidence: at least 15 characters single-factor (8 with another factor), no composition rules, and no periodic expiry — you change a password on evidence of compromise, not on a calendar. Fallback flows, recovery paths and every service that has not shipped passkeys will keep passwords in your life for years. Our companion guide, a password system for 2026, covers running that side well.

The Singapore angle: Singpass

Singapore's national digital identity has joined in. Singpass's own site carries the invitation directly — "Create your passkey in the Singpass app today" — with the caveat stated just as plainly: "Available on iOS. Android and desktop coming soon." For a credential that fronts Singapore government services, phishing-resistant sign-in is a meaningful upgrade. On an iPhone, set it up now; Android and desktop users wait for the rollout.

Where our tools fit

The fallback-password era is not over, so our two client-side tools still have a place. The password generator runs entirely in your browser on crypto.getRandomValues() with rejection sampling to eliminate modulo bias, configurable character sets, optional exclusion of ambiguous characters, and batches of up to ten — nothing is sent to any server. The password strength tester is a zxcvbn-inspired entropy and crack-time estimator, also fully client-side: it penalises common passwords, sequential runs and keyboard patterns, and models crack time across four attacker profiles; the password never leaves the page. Both are simplified aids for the passwords you still keep, not a full audit.

FAQ

Can a passkey be phished?

Not in the way a password or OTP can. The credential is scoped to the legitimate site's Relying Party ID, and both browser and authenticator enforce that scope, so a look-alike domain cannot request it. What remains possible is everything downstream of sign-in — device malware, stolen session cookies, or being talked into approving actions inside a genuine session.

What happens if I lose my phone?

It depends on the passkey type. Synced passkeys survive: Apple recovers your escrowed iCloud Keychain with your device passcode, and Google restores access when you sign back in to your account — which also lets you remove the passkey from the lost device remotely. Device-bound passkeys do not survive; Microsoft's advice applies everywhere: register passkeys on multiple devices as a spare key.

Can I move my passkeys from iPhone to Android?

Not through a finished standard yet. FIDO's Credential Exchange Format became a Proposed Standard in August 2025, but the Credential Exchange Protocol that would perform the transfer is still a Working Draft FIDO itself says is not a basis for implementations. Until that changes, create separate passkeys per ecosystem for accounts you care about.

Do passkeys mean I can stop using a password manager?

No. Passwords remain in NIST's framework at every assurance level, and most services still use them somewhere — primary sign-in, fallback, or recovery. What changes is the mix: passkeys where offered, long random passwords everywhere else, a manager holding both.