Passwords have one unfixable flaw. To prove you know a secret, you have to send it somewhere, and once you have sent it, whoever received it knows it too. Every phishing page, every credential-stuffing list and every leaked database is a consequence of that single design decision.
Passkeys change it. Instead of sending a secret, your device performs a calculation that proves it holds a key without revealing the key. That difference sounds academic and turns out to eliminate phishing almost entirely.
The mechanism, in plain terms
When you create a passkey for a site, your device generates a matched pair of cryptographic keys.
- The private key stays on your device, protected by your fingerprint, face or screen lock. It never leaves.
- The public key is sent to the website, which stores it against your account. It is not a secret and is useless to a thief.
When you log in later, the site sends a random challenge. Your device signs it with the private key and returns the signature. The site checks the signature against the stored public key. If it matches, you are in.
At no point does a reusable secret travel across the network. There is nothing in the site's database worth stealing, and nothing for you to accidentally type into the wrong box.
The signature is bound to the exact domain that requested it. A passkey created for your bank will not produce a valid signature for a lookalike domain — the browser refuses, without asking you. The protection does not depend on you spotting the fake, which is important, because everybody eventually fails to spot one.
What using one feels like
Less dramatic than the cryptography suggests.
- You go to log in and enter your username, or the site recognises the device.
- Your phone or laptop prompts for the fingerprint, face or PIN you already use to unlock it.
- You are in.
No password, no code from a text message, no authenticator app. On the same device it is about two seconds. Signing in on a different device usually means scanning a QR code with your phone, which takes a few seconds longer.
Where the passkey lives
This is the part that causes most confusion, because there are two quite different models.
Synced passkeys. Stored in your platform account or password manager and available on all your devices. Convenient, and you do not lose access when you drop your phone in a canal. The trade-off is that the security of your accounts now rests on the security of that one account.
Device-bound passkeys. Stored in a specific piece of hardware — a security key, or the secure element in one phone — and never copied anywhere. Stronger, because there is no cloud copy to compromise, but if you lose the device without a backup you are relying on the site's recovery process.
For most people, synced passkeys in a well-secured password manager or platform account are the right answer, plus at least one hardware key as a backup for the two or three accounts that matter most: your primary email and whatever holds your money.
The honest problems
Passkeys are better, not finished.
Account recovery is the weak link. Your login is now unphishable, but the "I lost my device" flow is often still an email link or a support call. Attackers move to the weakest path, and that is now recovery. Some services have done this thoughtfully; many have not.
Uneven implementation. Some sites treat a passkey as a full replacement. Others treat it as a shortcut and leave the password active as a fallback, which means the phishable credential still exists. That is progress you cannot rely on.
Shared accounts. Passkeys are built around a person and a device. A household streaming login or a team account is genuinely awkward.
Platform friction. Moving passkeys between ecosystems has improved, but exporting and importing is still not as simple as a password export, and support varies.
Recovery of last resort. With passwords, you could write one down and put it in a drawer. With a device-bound passkey, if the device is gone and the site has no recovery, the account is gone.
What to do this month
A realistic plan, in order of value.
- Turn on passkeys for your email first. Email is the master key to everything else. Securing it has the highest return of any single action here.
- Then your money. Bank, payment services, anything with a card stored.
- Buy two hardware keys. Register both on those critical accounts. Keep one in a different physical location. Two, because one will eventually be lost.
- Where a password remains, remove it if the site allows. A password kept "just in case" is an attack surface kept just in case.
- Use a password manager for everything else. Most accounts will not support passkeys for years. Long, unique, generated passwords remain the correct answer there.
- Check your recovery settings. Old phone numbers and dead backup addresses are a common way accounts get taken over.
How it compares
| Method | Phishable | Reused across sites | Breach exposes it | Effort |
|---|---|---|---|---|
| Password alone | Yes | Very often | Yes | Low |
| Password plus SMS code | Yes | Often | Partly | Medium |
| Password plus authenticator app | Yes | Often | Partly | Medium |
| Hardware security key | No | No | No | Medium |
| Passkey | No | No | No | Low |
That last row is what makes passkeys unusual. Every previous improvement in login security cost the user effort, which is why adoption stalled. Passkeys are both stronger and less work, and that combination is rare enough to be worth acting on.
The realistic timeline
Passwords are not disappearing. Too much of the web is too old, and too many organisations have no reason to change. What is happening is that the accounts most worth attacking are becoming unphishable, which pushes attackers toward recovery flows, support desks and device compromise.
That is still a large improvement. Moving the fight away from "can we trick this person into typing their password into a convincing copy of their bank" is worth a great deal, because that fight was one people were always going to lose eventually.