Passkeys, for people who manage a lot of accounts
Passkeys are the first genuinely new thing in consumer authentication in a long while, and the marketing around them ("just use your face!") hides the part that actually matters. If you manage many accounts, it's worth understanding the mechanism — because it tells you exactly which accounts to move first and which to leave alone for now.
What a passkey is
A passkey is a public-private key pair created for one specific website. The private key stays on your device or in your vault and never leaves it. The public key goes to the site.
Logging in works as a challenge and response. The site sends a random challenge; your device signs it with the private key, after checking that you're present — a fingerprint, a face scan, a PIN, a tap on a hardware key. The site verifies the signature against the public key it already holds.
Three consequences follow, and they're the whole point:
- Nothing reusable is transmitted. The signature is valid for that one challenge. Intercepting it gains an attacker nothing.
- Nothing reusable is stored by the site. A breach of the service leaks public keys, which are public by design. There is no password database to crack.
- There is nothing for you to type. So there is nothing you can be tricked into typing somewhere else.
Why this beats a code from an app
This is the part worth internalising, because it's the reason passkeys matter more than "one less password to remember".
A six-digit code from an authenticator app is a real improvement over a password alone — but it's still a secret you read off one screen and type into another, and you are the one deciding whether the destination is legitimate. A convincing fake login page asks for the code, you type it, and a script relays it to the real site within its validity window. Your second factor just walked through the front door with the attacker.
A passkey can't be relayed this way, because the browser binds the signature to the site's actual origin. Ask a passkey to authenticate to a lookalike domain and it simply won't produce a signature — not because it detected fraud, but because the lookalike isn't the site the key was created for. The check happens in software, before any human judgement is involved.
Passkeys and hardware security keys are the only widely available factors that defend against real-time phishing. That's a categorical difference from passwords, SMS, and TOTP codes — not an incremental one.
Synced versus device-bound
Passkeys come in two flavours, and the distinction drives every practical decision you'll make about them.
Synced passkeys live in a credential manager — a platform account or a password manager — and replicate across your devices. Lose a phone, and the passkeys are still there on the laptop. This is the ergonomic option and the one most people should use for most accounts.
Device-bound passkeys never leave the hardware they were created on, typically a physical security key. There is no copy anywhere. Lose it without a backup registered, and that credential is gone.
| Synced | Device-bound | |
|---|---|---|
| Survives losing one device | Yes | Only if you registered a second key |
| Weakest link | The sync account and its recovery flow | Physical possession |
| Works on a borrowed machine | Usually, via the vault | Yes — plug it in |
| Best for | Tier 2 and Tier 3 accounts | Tier 1 accounts |
The trap with synced passkeys is easy to miss: your passkeys are now only as strong as the account they sync through. If that platform or vault account can be recovered by someone who controls your email and answers a few questions, then every passkey inside it inherits that weakness. Secure the sync account first, with its own strong factor, before you move anything important into it.
Where passkeys still fall short
Worth knowing before you plan a migration, because these are the things that will bite you:
Coverage is uneven. Large consumer platforms support passkeys well. The niche B2B dashboard, the legacy registrar, the regional payment provider — often not. You will be running a mixed setup for years, so plan for both rather than a clean cutover.
Passkeys are often added beside the password, not instead of it. Many services let you register a passkey while leaving password login fully enabled. That's convenient and it also means the phishable path is still open — an attacker simply chooses it. Where a service offers to disable password sign-in after passkey enrolment, that's the setting that converts a convenience feature into a security one. Where it doesn't, understand that you've gained ergonomics, not protection.
Recovery flows can undercut everything. If losing your passkey drops you into "we'll email you a reset link", the account's real security is your email account's security. This is not a passkey problem so much as a reminder that the recovery path is part of the threat model — see the 2FA guide for how to audit it.
Shared accounts are awkward. Passkeys are built around individual identity, which is correct but unhelpful when a vendor sells one seat. Some password managers support sharing a passkey within a team vault; where they don't, you're back to a shared password. The single-seat guide covers the options.
Automation doesn't get along with them. A passkey requires a user-presence gesture by design — that's what makes it phishing-resistant. Anything doing unattended, scripted login will not be able to use one. If a workflow depends on automated sign-in, that account stays on a password, and you compensate elsewhere: narrow permissions, IP restrictions, monitoring.
A migration order that makes sense
Don't try to convert everything. Work in the order where each step buys the most protection:
- The sync account itself — your platform account or password manager. Everything else will depend on it, so it gets a hardware key and a verified recovery path first.
- Tier 1 — registrar, DNS, primary email, cloud root, code hosting. Use device-bound keys here, and register two, stored in different places. Then disable password login if the service allows it.
- Tier 2 — payment, billing, CRM. Synced passkeys are fine. Keep a TOTP factor registered as a fallback until you trust the setup.
- Tier 3 — everything else, opportunistically. Enrol a passkey when a service offers one; don't make a project of it.
At each step, record in your inventory which accounts now use a passkey and where that passkey lives. An account whose passkey location is undocumented is a lockout with a delay on it — the same failure mode as an untracked TOTP seed.
Before you enrol anything
Two checks that take a minute each and prevent the two most common regrets:
First, confirm you have a second way in. Register the passkey, then immediately verify that a backup key, a TOTP factor, or a set of backup codes still works. Do not remove the old method until you've tested the new one — from a different device if you can. Enrolling a passkey and deleting the password in the same sitting is how people lock themselves out.
Second, find out what happens on the service's account-recovery page. If it's a self-serve email reset, your passkey is a convenience improvement rather than a security boundary, and you should protect that mailbox accordingly.
Is it worth it?
For your Tier 1 accounts, yes, clearly — that's where phishing resistance is worth the setup effort, and where the small number of accounts makes registering two hardware keys practical.
For everything else, treat passkeys as a welcome ergonomic upgrade you adopt when offered. Don't force a migration, don't disable working 2FA to chase them, and don't let the project distract from the higher-value work: eliminating reused passwords, and knowing where every second factor actually lives.