If you have logged into anything new lately, you have probably been asked to create a passkey instead of a password. The pitch sounds nice, but the choice can feel murky. This post lays out passkeys vs passwords in plain terms, so you can decide whether to switch without taking anyone’s marketing on faith.
What a password actually is
A password is a shared secret. You pick a string, the site stores a scrambled version of it, and every time you log in you send that string so the site can check it. That model has one stubborn flaw: the secret leaves your hands. It travels to the site, sits in the site’s database, and often gets typed into whatever page asks for it.
That single fact explains most of the trouble. If the database leaks, attackers get the scrambled passwords and crack the weak ones offline. If you reuse one password across ten sites, one breach exposes all ten. And if a fake login page asks nicely, plenty of people hand the secret straight to the attacker. None of this means people are careless. The design simply asks a human to keep a long secret and never give it to the wrong party, which is hard to do every single time.
What a passkey is instead
A passkey is a public private key pair tied to your device. When you create one, your phone or laptop generates two matched keys. The private key never leaves the device. The site only ever sees the public key, which is useless on its own. There is no shared secret to steal.
Logging in works like a challenge and response. The site sends a random challenge, your device signs it with the private key, and the site checks that signature against the public key it stored. To access the private key you use your fingerprint, face, or a device PIN. That biometric stays on the device too. It is a local gate, not data sent to the site.
The core shift is simple. Passwords prove who you are by sending a secret. Passkeys prove who you are by signing a challenge, so nothing worth stealing ever touches the site.
Passkeys vs passwords on the attacks that actually hurt
Here is where the comparison stops being abstract. Three of the most common ways accounts get taken over lose most of their power against passkeys.
- Password reuse. A passkey is unique to each site by design, generated fresh per account. There is no single secret to reuse, so one leaked site cannot open another.
- Phishing. A passkey is bound to the real site’s domain. The signature only works for the domain it was made for. A lookalike page at
yourbanksecurelogin.comcannot collect a signature it can replay against the real bank, because the browser will not sign for the wrong origin. - Credential stuffing. This attack takes username and password pairs from old breaches and tries them everywhere. With no password stored anywhere and no secret to dump, there is nothing to stuff.
This is also why passkeys count as strong two factor by themselves. Something you have, the device holding the private key, plus something you are, the biometric that authorizes it. Worth knowing how that fits the broader picture of authentication vs authorization: passkeys make proving who you are much harder to fake, but they do not decide what you are allowed to do once you are in. That second job still belongs to the app.
The honest tradeoffs
Passkeys are a real improvement, not a finished story. There are rough edges, and pretending otherwise would not help you decide.
Losing the device
If the private key lives only on one phone and that phone goes in a river, can you still get in? The answer depends on whether your passkey syncs. Platform passkeys from Apple, Google, and Microsoft back up to your account and restore to a new device. A passkey stored only on a single hardware key does not. So your recovery story is only as good as your backup, and you should set that up before you need it.
Recovery still leans on older methods
When you cannot use your passkey, most sites fall back to email or a text message code. That fallback can be the weak link. A text message code can be intercepted through SIM swapping, where an attacker convinces a carrier to move your number to their phone. Passkeys raise the front door, but if the back door is a texted code, the account is only as safe as that path. Prefer recovery through a synced account or a second passkey over a text whenever the site lets you.
Sync across platforms is still uneven
A passkey made on an iPhone syncs cleanly across Apple devices. Moving it to a Windows laptop or an Android tablet is smoother than it was, often by scanning a QR code with your phone to approve the sign in, but it is not always one tap. If you live across two ecosystems, expect a few moments where the flow asks you to reach for your phone.
Not every site supports them yet
Adoption is wide but not total. You will keep some passwords around for a while, which means a password manager is still useful for the accounts that have not caught up.
So should you switch?
For most people, yes, and you do not have to do it all at once. A reasonable plan looks like this:
- Turn on passkeys for your highest value accounts first: email, banking, and your password manager itself. Email matters most because it is the reset path for everything else.
- Keep your existing strong, unique passwords as a fallback where the site still requires one. Do not delete them yet.
- Make sure your passkeys sync to a backup you control, so a lost phone is an annoyance and not a lockout.
- Check the recovery options on each account and move away from text message codes where you can.
The thing to hold onto is the underlying change. Passwords ask you to guard a secret and never hand it to the wrong party. Passkeys remove the secret from the equation, so a whole category of common attacks simply has nothing to grab. That is a genuine step forward, and the tradeoffs are about recovery and convenience, not about whether the security is sound.
Stronger login is one layer. The deeper risks usually live in how an app decides what a logged in user may do, the kind of logic flaw that no passkey can cover. Finding those takes understanding how an app is meant to work and testing the assumptions it makes, which is the problem UnboundCompute is built to study.
Frequently asked questions
What is the core difference in passkeys vs passwords?
A password is a shared secret you type and the site stores. A passkey is a key pair where the private key never leaves your device and the site only keeps the public half. Nothing secret is sent or stored on the server, so there is nothing to steal in a breach.
Are passkeys really phishing resistant?
Yes. A passkey is bound to the real site it was created for, so it will not sign in on a lookalike domain. Even a convincing fake page cannot trigger your passkey, which removes the main way passwords get stolen.
What happens if I lose the device that holds my passkey?
Most platforms sync passkeys to your account so a new device picks them up after you sign in. Keep your platform account recoverable and add a second method, since recovery is the main tradeoff in passkeys vs passwords.
Do passkeys work across different platforms?
Support is wide but not perfect. Passkeys sync cleanly inside one ecosystem, and cross platform use is improving through QR based sign in from a nearby phone. For a few services you may still keep a password as a backup for now.
Should I switch to passkeys?
Turn them on for your most valuable accounts first, such as email and banking, since those gain the most from phishing resistance. Keep a recovery method in place, and let the rest of your accounts move over as each site adds support.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.