← Back to blog

Passkeys have won. Here's why you should move your logins

4 min read#authentication#passkeys#fido2#defensive

A field-update explainer published on this site. Sources at the bottom.

There's been a lot of "the password is dead" rhetoric over the years. Most of it has been wrong. This time it's mostly right.

In 2026, passkeys have crossed the line from experiment to mainstream. Apple, Google, and Microsoft all support them as defaults. Google reports over 800 million accounts now using passkeys. Amazon enrolled 175 million users in the first year alone. The total addressable user base is past 15 billion accounts.

The headline number that matters most: Google reports passkey accounts have a 99.9% lower compromise rate than password accounts.

This post explains what a passkey actually is, why phishing fundamentally stops working against them, and what holdouts (mostly enterprise IT and a long tail of legacy services) still need to plan for.

What a passkey actually is

A passkey is a cryptographic key pair, with the private half stored on your device (in the Secure Enclave on iPhone, the Titan chip on Pixel, or equivalent on every modern laptop), and the public half stored on the website you registered with. "Logging in" means: the website sends a random challenge, your device signs it with the private key, the website verifies the signature with the public key. The private key never leaves your device.

This is FIDO2 / WebAuthn. The names are clunky; the underlying tech is straightforward asymmetric crypto. Same primitives that secure HTTPS, applied to login.

What the user sees: a Face ID prompt, or a fingerprint scan, or a PIN. What the website sees: a signed challenge. Done.

Why phishing stops working

A passkey is bound to a specific origin, the exact domain you registered it on. Your bank passkey works on bank.com. It does not work on bank.com.attacker.tld. It does not work on bank.com if the URL is actually being served from an attacker's mitmproxy session. The browser's WebAuthn API checks the origin before signing anything, and there's no way for the attacker to forge that check.

Compare to a password: a password works wherever you type it. The phisher's job is to make a page that looks like the real one, get you to type, and the password works equally well on their server as on the real one.

A passkey doesn't have that property. Even if the user is fooled by a perfect phishing page, their device refuses to sign. It's not a question of user judgement. It's a structural property of the protocol.

This is why Google sees a 99.9% lower compromise rate. Most account compromises are downstream of a phishing email. Take phishing off the table and the curve bends.

What it actually replaces

Passkeys replace the password and 2FA combined. You don't add a passkey on top of your password and TOTP, the passkey is both. Cryptographically, it's the strongest 2FA you can have (something you have: the device, plus something you are: the biometric to unlock the device), but presented as a single login step.

The migration shape that works:

  1. Add passkey support alongside password.
  2. After enrolment, prompt users to default to the passkey.
  3. Once adoption is high, remove password as a primary login method (keep it as recovery only).
  4. Eventually retire passwords entirely for that service.

Apple, Google, and Microsoft accounts are at step 4 for users who opt in. Most of the rest of the internet is still at step 1.

What still needs solving

Passkeys are not a complete win yet. The main rough edges:

  • Recovery and account portability. If you lose your only device with a passkey on it, recovery flows vary wildly between services. Apple, Google, and Microsoft sync passkeys across devices via their cloud (convenient, but adds back a credential dependency on those accounts). Hardware-key passkeys (YubiKeys) don't sync but require thinking about backup keys.
  • Cross-platform UX. Logging in from a Windows machine to an account whose passkey lives on your iPhone works (via Bluetooth + camera + cross-device flow), but the UX is still awkward enough that some users give up and fall back to a password.
  • Enterprise legacy. Banking portals, government services, internal HR tools, anything built on SAML 1.0; these will be password-and-OTP for years. Expect a long tail.
  • Phishing-resistant is not social-engineering-proof. A passkey defeats credential phishing. It doesn't defeat "please run this PowerShell script my IT department sent" or "please approve this consent prompt for what looks like a Microsoft app." Different attacks, different defenses.

What to do

If you have a personal account on a service that supports passkeys (most major consumer services do now; check passkeys.directory), enroll one. The next phishing email that lands in your inbox will fail in a way it wouldn't have last year.

If you run a service that uses passwords, the planning starts now. The user expectation is shifting fast. Apple, Google, and Microsoft setting passkey-by-default makes "why doesn't your service support this?" a question your support inbox will start receiving. The IETF FIDO2 / WebAuthn libraries are mature in every major language. The implementation lift is days, not months.

The tipping point already happened. The rest is roll-out.

Further reading