The most common way accounts get broken into is not clever cryptanalysis. It is someone typing a perfectly good password into a perfectly convincing fake login page. No password policy fixes that – a 30-character random password is phished just as easily as "Summer2024!". This is the problem passkeys were designed to solve, and it is why the passkeys vs passwords debate is not really a debate about convenience. It is about removing the secret that users can be tricked into handing over.
What is a passkey?
A passkey is a login credential based on public-key cryptography, built on the FIDO2 standards from the FIDO Alliance and the W3C's WebAuthn specification. Instead of a shared secret that both you and the website know, a passkey is a key pair:
- A private key that stays on your device or in your password manager and is never sent to the website.
- A public key that the website stores in place of a password.
To the user, signing in looks like opening their phone: a fingerprint, a face scan, or the device PIN. That biometric or PIN never leaves the device either; it only releases the private key for use on that device.
How passwordless login works, step by step
Registration
- You choose "Create a passkey" on a website.
- Your device generates a new key pair specifically for that site.
- The private key is stored securely on the device or in a synced credential manager; the public key and a credential ID are sent to the website.
Sign-in
- The website sends a random one-time challenge.
- Your device asks you to verify yourself with a biometric or PIN.
- The device signs the challenge with the private key and returns the signature.
- The website checks the signature against the stored public key. If it matches, you are in.
Two properties make this powerful. First, the server stores nothing worth stealing – a leaked database of public keys does not let anyone log in. Second, every passkey is bound to the website's domain. The browser will only offer the passkey for the real site, so a lookalike domain gets nothing. That is what "phishing-resistant" means here: not that users are better trained, but that the protocol cannot be tricked into signing in to the wrong place.
Passkeys vs passwords compared
| Passwords | Passkeys | |
|---|---|---|
| Secret shared with the server | Yes | No – only a public key |
| Phishing | Easily phished | Bound to domain, resistant |
| Reuse across sites | Common | Impossible – one key pair per site |
| Server breach impact | Hashes can be cracked | Public keys are useless to attackers |
| User effort | Remember or store, type, often add MFA | Biometric or PIN |
| Recovery | Email reset | Depends on sync and fallback methods |
| Maturity | Universal | Broad support, still maturing in edge cases |
A passkey effectively combines two factors in one gesture: something you have (the device holding the key) and something you are or know (the biometric or PIN). That is why many services treat a passkey sign-in as satisfying multi-factor authentication.
Synced passkeys vs device-bound passkeys
Early FIDO credentials lived only on hardware security keys. If you lost the key, you lost the credential. Modern passkeys are usually synced: Apple's iCloud Keychain, Google Password Manager and third-party managers like 1Password and Bitwarden back up passkeys end-to-end encrypted and make them available on your other devices.
- Synced passkeys are what make consumer adoption realistic: a new phone does not mean starting over.
- Device-bound passkeys, on hardware keys such as YubiKeys or managed devices, never leave the hardware. High-security environments and administrators often prefer them, because the key cannot be exported or synced to an account that might itself be compromised.
There is also cross-device sign-in: you can use a passkey on your phone to log in on a laptop by scanning a QR code, with Bluetooth used to confirm the phone is physically nearby, which blocks a remote attacker from relaying the request.
Where passkeys still fall short
Passkeys are a clear improvement, but it is worth being honest about the rough edges:
- Account recovery is the new weak point. If a user loses every device and their sync account, the site needs a fallback. If that fallback is an SMS code or an email link, attackers will target it instead.
- Ecosystem boundaries. Moving passkeys between different platforms' managers has historically been awkward. Standards for credential exchange between providers are being developed, but users can still feel tied to one ecosystem.
- Shared accounts. Teams that share a single login for a social media account or supplier portal need a password manager that supports sharing passkeys, or better, proper multi-user accounts.
- User understanding. "Where is my passkey?" is a real support question. Clear wording in your UI matters.
- Passwords linger. As long as a password remains on the account as a fallback, it can still be phished. The full security benefit arrives when passwords can be removed.
Adding passkeys to your app
For developers, WebAuthn is a browser API, but implementing the server side correctly – challenge handling, signature verification, attestation options, credential storage – is fiddly. Use a well-maintained library (SimpleWebAuthn for JavaScript, py_webauthn for Python, and equivalents in other languages) or an identity provider that supports passkeys out of the box.
A practical rollout plan:
- Offer passkeys alongside passwords first. Prompt users to create one right after a successful sign-in, when trust is highest.
- Use autofill-assisted sign-in (often called conditional UI), so passkeys appear in the browser's autofill suggestions on the username field without a separate button.
- Let users register multiple passkeys – phone, laptop, hardware key – and show them in account settings with names and last-used dates.
- Harden recovery. Require stronger verification for recovery than for normal login, and notify users by email when a new passkey or recovery method is added.
- Measure. Track sign-in success rates and support tickets per method, so you know when you can push harder.
- Eventually let users remove their password entirely.
When we build authentication flows at Mraviko, passkeys now go in from the first version rather than being retrofitted, because adding them later means migrating users who have already settled into passwords.
For users: should you switch?
Yes, wherever you can. Start with your most valuable accounts – email, password manager, banking where supported, and anything tied to money. Keep at least two ways in, such as passkeys on two devices or a passkey plus a hardware key, and make sure your sync account itself is protected by strong MFA.
The bottom line
In the passkeys vs passwords comparison, passkeys win on the thing that matters most: they cannot be phished, reused or leaked from a server breach in a usable form. Passwordless login works by keeping a private key on your device and proving possession of it, with your biometric acting only as a local gate to that key. The remaining challenges are recovery and ecosystem portability, not security of the core design. If you build software with a login form, the time to start offering passkeys is now.
