Think about everything we've built to protect passwords. Hashing with bcrypt or Argon2. Complexity rules. Breach checks. Rate limiting. Two-factor codes. "Forgot password" flows. Security training that tells people to look carefully at the URL.

And still, accounts get taken over every day because someone typed a perfectly good password into the wrong website.

Passkeys take a different approach: there's no shared secret to steal, reuse or type into a fake page. Apple, Google and Microsoft all support them, and you've probably been offered one already. So is this the end of passwords? Not quite yet. But it's the first real candidate.

The idea: a key pair instead of a secret

With a password, you and the server know the same secret. If the server's database leaks, or you type it into a phishing page, the secret is out.

A passkey uses public key cryptography instead:

• When you create a passkey, your device generates a new key pair just for that website.
• The private key stays with you: on your phone, laptop, password manager or security key.
• The public key goes to the server. It's safe for anyone to see.

To log in, the server sends a random challenge. Your device signs it with the private key after you confirm it is you with your fingerprint, face or PIN. The server checks the signature with the public key. The private key never leaves your device, and your fingerprint never leaves it either; biometrics only release the key locally.

It's the same idea as SSH keys, made friendly enough for your parents to use.

Why phishing stops working

This is the part that makes security people genuinely happy. A passkey is bound to the website's domain. The browser, not the user, checks which site is asking.

So if someone builds a perfect copy of your bank's login page on my-bank-secure-login.com, the browser simply has no passkey for that domain. There is nothing for the user to get wrong. Compare that with passwords, and even SMS or app codes, which a user can be tricked into typing into a fake page.

And a database breach on your side leaks only public keys, which are useless to an attacker.

Myths and realities

What it looks like in code

Under the hood, passkeys use the Web Authentication API (WebAuthn). Registration, simplified:

// options come from your server, including a fresh random challenge
const credential = await navigator.credentials.create({
  publicKey: {
    challenge,                       // ArrayBuffer from the server
    rp: { name: 'Example App', id: 'example.com' },
    user: { id: userIdBytes, name: '[email protected]', displayName: 'Sara' },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },   // ES256
      { type: 'public-key', alg: -257 }, // RS256
    ],
    authenticatorSelection: { residentKey: 'required', userVerification: 'preferred' },
  },
});
// send credential to the server, which verifies it and stores the public key

Login uses navigator.credentials.get() with a new challenge. Add mediation: 'conditional' and autocomplete="username webauthn" on the username field, and the browser offers saved passkeys right in the autofill dropdown, which is the smoothest experience by far.

On the server, you store a credential ID, the public key and a signature counter per passkey, linked to the user. Verifying the responses involves binary formats and careful checks of the challenge, origin and signature.

The parts nobody puts on the slide

Account recovery is now your weakest link

If a passkey can't be phished, attackers go after whatever else gets someone into the account. An email reset link, an SMS code or a support agent who can be talked into resetting things now carries the security of the whole system. Make recovery deliberate: encourage users to add a second passkey, offer recovery codes, and add friction (and notifications) to account recovery.

Let users manage their passkeys

People need a settings page that lists their passkeys with friendly names ("iPhone", "Work laptop"), shows when each was last used, and lets them remove one. Without it, a lost device is a support ticket.

Roll out gently

The usual path is: keep passwords, offer "create a passkey" after a successful login, then make passkeys the default sign-in option once enough users have one. Forcing everyone at once mostly produces locked-out users.

Shared and business accounts

A shared admin login, or an account an assistant uses on someone's behalf, doesn't fit "one person, one device" neatly. Proper per-user accounts with roles are the real fix, and passkeys are a good excuse to finally do it.

So, is it the end of passwords?

For phishing and password reuse, passkeys are the biggest step forward in years, and every site with logins should be planning for them. For passwords as a whole, not yet. As long as recovery flows, older devices and unconvinced users exist, most sites will run both for a while.

The realistic goal for 2026 isn't "no passwords". It's "passwords become the backup, not the front door".

Have you added passkey login to anything you've built yet? What was harder than you expected: the code, or the user experience around it?