Passkeys vs. Passwords: What Actually Changed in Authentication

It's easy to mistake a passkey for a slightly more convenient password — unlock with your fingerprint or face instead of typing something, same basic idea underneath. That's not actually what changed, and the difference matters more than the convenience angle suggests. A passkey isn't a faster way to prove you know a secret. It eliminates the shared secret entirely, which closes off an entire category of attack that no amount of password complexity or manual vigilance was ever fully able to close.

The Actual Cryptographic Difference

A password is a shared secret: you know it, and the service you're logging into also stores a version of it (ideally hashed, but stored nonetheless), and proving your identity means demonstrating you know the same string of characters the server has on file. That shared-secret model is the root of almost every major authentication problem — the secret can be phished by a fake login page, it can be stolen wholesale in a server-side data breach, and it can be reused across services, meaning one breach compromises every account where you reused the same password.

A passkey, built on the FIDO2 standard (combining the WebAuthn browser API with the CTAP2 authenticator protocol), works on a fundamentally different principle: public-key cryptography. When you set up a passkey for a service, your device generates a mathematically linked pair of keys — a private key that never leaves your device, ever, under any circumstance, and a public key that gets sent to and stored by the service. To log in, the service sends a unique cryptographic challenge, and your device signs it using the private key; the service then verifies that signature using the public key it already has on file. The critical structural difference: even if an attacker steals the service's entire database of public keys, that's useless to them for logging in as you, because the public key alone can't be used to generate a valid signature — only the private key, sitting only on your device, can do that.

Why This Is Structurally Phishing-Resistant, Not Just "More Secure"

The phishing-resistance claim around passkeys is often stated vaguely, so it's worth being precise about the actual mechanism, because it's a genuinely different kind of protection than "harder to guess." A phishing attack against a password works by tricking you into typing your real credential into a fake site that looks identical to the real one — the attack succeeds because a human, not a machine, is the one deciding whether the site looks legitimate, and humans get fooled. A passkey credential is cryptographically bound to the specific domain it was created for, and that binding is checked and enforced by the browser and operating system automatically, not by asking you to judge whether a URL looks right. If you're on a convincing phishing site impersonating your bank, your device's passkey system simply won't offer up a signature for that domain at all, because the domain doesn't match the one the passkey was registered against — the protection works even if you, the human, are completely fooled by the fake site, which is precisely the scenario where password-based defenses (and even many one-time-code-based two-factor systems) fail.

How "Sync" Actually Works, and Why It Doesn't Undermine the Model

A reasonable objection at this point: if the private key never leaves your device, how do passkeys work across your phone, laptop, and tablet without setting up a new one on each device separately? The answer is that major platforms sync passkeys through their own encrypted credential managers — Apple's iCloud Keychain, Google Password Manager, or a dedicated password manager like 1Password — using end-to-end encryption specifically designed so that even the platform operator can't read the private key in transit or at rest, only your own authenticated devices can decrypt and use it. This is a genuinely different security model than, say, a cloud backup of your password database, but it's still worth knowing as a real, if narrow, point of trust: you're trusting Apple's, Google's, or your password manager's specific encryption implementation to actually work as claimed, rather than trusting nothing beyond your own local device the way a non-synced hardware security key would require.

Where Adoption Actually Stands

The two biggest platform holders have both made concrete, dated moves that matter more than any survey statistic: Google made passkeys the default sign-in option for personal accounts in October 2023, and Microsoft followed with the same default shift for its own accounts in May 2025, after which Microsoft reported a 120% jump in actual passkey usage — a clear signal that defaults, not just availability, are what actually drive real-world adoption, since passkeys had already been technically available on both platforms for a while before either default change. On the infrastructure side, over 95% of smartphones sold since 2023 support passkeys natively, since the underlying capability shipped in iOS 16+ and Android 9+, and the same WebAuthn standard is supported across all modern desktop browsers on macOS Ventura and later and Windows 10 and later — meaning the remaining adoption gap at this point is overwhelmingly about services turning the option on and users actually opting in, not about missing device or browser support. Adoption still varies considerably by industry, with fintech services (where phishing losses are highest and the incentive to push adoption is strongest) seeing meaningfully higher real adoption than lower-stakes categories like media and entertainment services — a pattern that tracks fairly closely with how much a given industry actually loses to credential-based attacks in the first place.