The password problem, briefly
Passwords have been the weak point of every site we build for as long as we have been building them. Users reuse them, phishing kits harvest them, and support teams burn hours on resets. Password managers help, but they patch a broken model rather than fix the underlying flaw. Passkeys are the first replacement that has felt genuinely ready for mainstream business sites, and in 2026 the platform support has finally matured enough to make the call properly.
This is the practical assessment we now give clients when they ask whether their login should move to passkeys.
What a passkey actually is
A passkey is a public-key credential built on the FIDO2 and WebAuthn standards. When a user registers, their device generates a key pair. The private key never leaves the device and is unlocked with a biometric or PIN. The public key is stored on your server. At login, your server sends a challenge, the device signs it with the private key, and you verify the signature against the stored public key.
The crucial part: there is no shared secret. Your server never holds anything an attacker can steal and replay. A breach of your database leaks public keys, which are useless on their own.
Passkeys come in two flavours, and the distinction matters for how you plan recovery:
- Synced passkeys are backed up to a provider's credential manager — iCloud Keychain, Google Password Manager, or a third-party manager like 1Password. They roam across a user's devices automatically. This is what most consumers will have.
- Device-bound passkeys live on a single device or hardware security key and never leave it. They suit high-security contexts where you do not want a credential syncing to the cloud at all.
For the average business site, synced passkeys are what you are designing for.
How login actually feels
The experience is the reason to care. A returning user clicks "sign in", their device prompts for Face ID, Touch ID, Windows Hello, or a PIN, and they are in. No email field, no password, no "forgot password" detour. On a phone it is a glance; on a laptop it is a fingerprint or a tap.
Because the credential is bound to your domain, there is nothing to phish. A convincing fake login page cannot capture a passkey, because the browser will only release a signature to the real origin. That single property removes the most common account-takeover route we see.
The upside
The benefits stack up quickly, and they are not just security theatre:
- Phishing-resistant by design. The origin binding is enforced by the browser, not by user vigilance.
- No password reuse. There is no password, so a breach elsewhere cannot cascade into your site.
- Fewer resets and support tickets. Password resets are a real cost centre. Removing the password removes the bulk of that queue.
- Faster login. A biometric prompt beats typing a password and waiting on a one-time code, which lifts conversion on sign-in flows.
For any site where people log in regularly, that combination is hard to argue with.
The real challenges
We would be doing clients a disservice to pretend this is free. Passkeys carry genuine friction, and most of it lands on recovery and cross-ecosystem edges.
Account recovery is the hard problem. If a user loses access to their credential manager, you need a way back in. That path — email magic link, identity verification, a backup code — becomes your new weakest link, because an attacker who compromises it bypasses the passkey entirely. Recovery deserves as much design attention as the passkey itself.
Cross-device and cross-ecosystem friction is real. A passkey created in iCloud Keychain does not automatically appear in Google Password Manager. A user who signs up on their iPhone and later logs in on a Windows machine may need to scan a QR code to use their phone as an authenticator, or register a second passkey on the new device. It works, but it is not always seamless, and users notice.
The lost-device story needs an answer. Synced passkeys survive a lost phone because they live in the cloud backup. Device-bound ones do not. Users need to understand which they have, and you need a fallback either way.
Support is broad but not universal. Modern versions of Safari, Chrome, Edge and Firefox on current operating systems handle passkeys well. Older devices, locked-down corporate machines, and some embedded browsers still lag. You cannot assume every visitor can use one.
The throughline is that a passkey rollout without a fallback is a rollout that will lock someone out. Which leads to the main recommendation.
Where passkeys fit — and where they are overkill
Passkeys earn their keep on repeat logins to something that matters: customer account areas, logged-in dashboards, SaaS applications, and especially admin and staff panels where account takeover would be damaging. High-value, high-frequency authentication is exactly where the phishing resistance and speed pay off. For internal admin access, we increasingly treat passkeys as the default.
They are overkill, or simply not worth the effort, where there is no real account to protect — a newsletter signup, a one-off contact form, a low-stakes gated download. If the login is rare and the blast radius of compromise is small, the recovery and support complexity is not justified. Not every form needs a cryptographic handshake.
Our advice: offer, don't force
The pragmatic move in 2026 is to add passkeys alongside your existing login, not replace it overnight. Let users opt in. Someone signs in with their password as usual, and you offer "set up a passkey for faster sign-in next time." Over months, a meaningful share of active users adopt them, your reset volume drops, and you have kept a working path for everyone who cannot or will not switch yet.
Technically, a passkey login is a short WebAuthn exchange in the browser:
const credential = await navigator.credentials.get({
publicKey: {
challenge, // random bytes from your server
rpId: "example.com",
userVerification: "preferred",
},
});
// send credential.response to your server to verify the signature
The heavier lifting is on the server — generating and validating challenges, storing public keys, and building a recovery flow you trust. Well-supported libraries and identity providers handle most of the WebAuthn plumbing now, so the work is less about the crypto and more about the surrounding UX: enrolment prompts, clear messaging about what a passkey is, and a recovery path that is convenient without being the door an attacker walks through.
Passkeys are ready for the sites that benefit most, provided you treat them as an addition rather than a cutover. If you are weighing up whether your accounts, dashboard or admin panel should offer them, we are happy to look at your login flow and recovery model and give you a straight recommendation — get in touch.
