Passkeys and WebAuthn Explained: Phishing-Resistant Login

Passwords leak. One-time codes get phished through fake login pages and SIM swaps. Passkeys are the industry's answer — a login method that is both easier for users and fundamentally resistant to phishing. This article explains what passkeys are, how the underlying WebAuthn standard works, and what to think about before rolling them out.

What is a passkey?

A passkey is a public/private key pair bound to a specific website, created and stored by the user's device. There's no shared secret to leak: the private key never leaves the device, and the server only ever stores the public key. To log in, the device proves it holds the private key by signing a challenge.

Passkeys are built on two web standards: WebAuthn (the browser API) and CTAP (the protocol between the browser and authenticators like phones, laptops, and security keys). Together they're often called FIDO2.

The user experience is what makes them compelling: instead of typing a password, the user approves the login with the same biometric or PIN they already use to unlock their device — Face ID, a fingerprint, or a screen lock.

Why passkeys resist phishing

This is the part that matters most. A passkey is cryptographically bound to the website's origin (its domain). When you register a passkey for example.com, the browser records that origin. If a user later lands on examp1e.com — a convincing phishing clone — the browser simply will not offer the passkey, because the origin doesn't match.

Compare that to passwords and OTPs: a user can be tricked into typing either into a fake page, and an attacker relays them to the real site in real time. Passkeys remove the human from the trust decision entirely. There is no secret the user can be socially engineered into handing over.

How WebAuthn works, step by step

WebAuthn has two ceremonies: registration (creating a passkey) and authentication (using it).

Registration

1. The server generates a random challenge and sends it to the browser along with the site's identifier (the "relying party ID") and the user's info.
2. The browser calls navigator.credentials.create(). The authenticator generates a new key pair scoped to this origin and prompts the user (biometric/PIN).
3. The authenticator returns the public key and a signed attestation proving the credential was created.
4. The server verifies the response and stores the public key and a credential ID against the user's account.

Authentication

1. The server sends a fresh random challenge.
2. The browser calls navigator.credentials.get(). The user approves with their biometric/PIN.
3. The authenticator signs the challenge with the private key.
4. The server verifies the signature using the stored public key. If it checks out, the user is authenticated.

The challenge is single-use and random, which defeats replay attacks. The signature proves possession of the private key without ever revealing it.

Synced vs. device-bound passkeys

There are two flavors, and the distinction affects your recovery strategy:

• Synced passkeys are backed up to a cloud keychain (iCloud Keychain, Google Password Manager, etc.) and follow the user across their devices. Great for usability — if they get a new phone, their passkeys come with them.
• Device-bound passkeys never leave the hardware they were created on (typical of physical security keys like YubiKeys). Stronger guarantees, but losing the device means losing that credential.

Most consumer products lean on synced passkeys for reach; high-assurance environments may require device-bound keys.

Adoption without lockouts

The biggest risk in rolling out passkeys isn't security — it's accidentally locking users out. Practical guidance:

• Treat passkeys as additive at first. Let users add a passkey alongside their existing password or email login rather than forcing a switch.
• Allow multiple passkeys per account so a user can register their phone and their laptop and a backup security key.
• Keep a recovery path. Email-based magic links or recovery codes give users a way back in if they lose access to their authenticators.
• Use conditional UI ("autofill") so returning users see a passkey suggestion right in the username field — adoption climbs sharply when it's frictionless.
• Show users their registered passkeys in account settings, with device names and the ability to revoke.

Where passkeys fit alongside other methods

Passkeys don't have to be all-or-nothing. A pragmatic modern auth stack often looks like:

• Passkeys as the primary, phishing-resistant method.
• Magic links or OTP as a fallback and for account recovery.
• Passwords retained only for users who haven't migrated yet, with a nudge to upgrade.

The direction of travel is clear: passwords are slowly being demoted from "the way you log in" to "the legacy fallback." Passkeys won't replace every method overnight, but for most products they're now the best default to offer — better security and a better experience at the same time, which is a rare combination in authentication.