Passkeys in 2026: A Practical Engineering Guide to Passwordless Auth
Authentication is broken at its foundation - not just inconvenient. Passwords are shared secrets: hand one to a server, and you have instantly doubled your attack surface. With over 5 billion passkeys now active globally and Google reporting a 99.9% lower account compromise rate compared to passwords, the industry has already moved. This guide covers how passkeys work cryptographically, how to implement them in TypeScript, and the pitfalls to avoid before going to production.
Why Passwords Are Structurally Broken
The core issue isn't that users pick weak passwords - it's that passwords require a shared secret stored on both sides. The Verizon 2025 DBIR found that 22% of all breaches started with stolen credentials, and 88% of web app attacks relied on them. In 2024, infostealer malware alone harvested 548 million passwords. Adding 2FA helps but doesn't fix the root problem: SMS codes are SIM-swap targets, and TOTP tokens can be phished in real time by proxy attackers who replay codes within their validity window.
What Passkeys Actually Are
A passkey is a credential built on public-key cryptography, standardized through the WebAuthn spec and FIDO2. When you register, your device generates a public-private key pair - the private key stays locked in hardware (Secure Enclave, StrongBox, or a hardware key), and the server only receives the public key. At login, the server sends a random challenge, your device signs it with the private key after biometric or PIN verification, and the server verifies the signature. No secret is ever transmitted. This eliminates credential stuffing, server-side breach exposure, and phishing - because passkeys are cryptographically bound to a specific origin domain.
The Cryptography Worth Understanding
The standard algorithm is ES256 - ECDSA with the P-256 curve and SHA-256. Each credential is tied to a specific relying party ID (your app's domain). A passkey created for yourapp.com cannot be used on yourapp-phishing.com because the origin is embedded in clientDataJSON and verified by the authenticator before it signs anything. The registration flow involves your server generating a one-time challenge, the client calling navigator.credentials.create(), the authenticator signing an attestation with the new private key, and your server verifying and storing the public key and credential ID. Authentication mirrors this with navigator.credentials.get().
Implementing Registration with SimpleWebAuthn
Don't implement raw WebAuthn from scratch - CBOR decoding and signature verification are easy to misconfigure. The standard library for TypeScript/Node.js is SimpleWebAuthn. Install it with: npm install @simplewebauthn/server @simplewebauthn/browser
Server-side registration (Express) - generate options and verify response:
// Server: Generate registration options
app.get('/auth/register/options', requireSession, async (req, res) => {
const options = await generateRegistrationOptions({
rpName: 'Your App', rpID: 'yourapp.com',
userName: req.user.email,
excludeCredentials: req.user.passkeys.map(pk => ({ id: pk.credentialID })),
authenticatorSelection: { residentKey: 'required', userVerification: 'required' },
});
req.session.registrationChallenge = options.challenge;
res.json(options);
});
// Server: Verify registration response
app.post('/auth/register/verify', requireSession, async (req, res) => {
const verification = await verifyRegistrationResponse({
response: req.body,
expectedChallenge: req.session.registrationChallenge,
expectedOrigin: 'https://yourapp.com',
expectedRPID: 'yourapp.com',
});
if (verification.verified) {
const { credential } = verification.registrationInfo;
await db.passkeys.create({ userId: req.user.id, credentialID: credential.id, counter: credential.counter });
req.session.registrationChallenge = undefined;
}
res.json({ verified: verification.verified });
});
Client-side registration using startRegistration() from @simplewebauthn/browser follows the same pattern - fetch options, call startRegistration, post the result to verify endpoint./heading2Implementing AuthenticationThe login flow mirrors registration - generate a challenge server-side, have the device sign it via startAuthentication() on the client, and call verifyAuthenticationResponse() on the server. After successful verification, always update the credential counter in your database using authenticationInfo.newCounter to detect cloned authenticators./heading2Where Adoption Stands Right NowFIDO Alliance research from April 2026 shows 75% of people globally have at least one passkey, up from 69% six months prior. Google serves 800 million passkey-enabled accounts with 4x higher sign-in success rates than passwords. Amazon has 175 million passkey users, TikTok reports 97% auth success rate. If your app doesn't support passkeys yet, you're behind the median curve.
Four Common Implementation Bugs
These appear repeatedly in production incidents.
Challenge reuse - Challenges must be single-use, server-generated, and stored in the session between options generation and verification. Any deviation opens a replay attack window.
Skipping counter updates - Always call updateCounter after a successful login to detect cloned credentials.
No account recovery path - A user who loses their device loses their passkey. Build backup email codes or recovery keys before you launch passkeys in production.
Cross-device UX dropoff - Same-device completion rates run 79-98%. Cross-device flows on Windows web drop to 52-67%. Keep a password fallback during migration.
Migrating From Passwords Without Breaking Things
Treat the migration as three additive stages, not a hard cutover.
Stage 1 - Opt-in: Prompt users to register a passkey after a successful password login. Nothing changes for those who skip it.
Stage 2 - Flip the default: Once 60-70% of active users have passkeys, make the passkey flow primary. Conversion follows naturally because the UX is better.
Stage 3 - Require for new signups: New accounts register a passkey as part of onboarding. Apple's OS 26 includes Automatic Passkey Upgrade for reference.
NIST guidelines updated in 2025 require phishing-resistant MFA for US federal agency systems. Syncable passkeys satisfy AAL2.
Browser and Platform Support
WebAuthn has approximately 95% global browser coverage in 2026. Chrome (v67+), Edge (v18+), Safari (v13+ and iOS v14.5+), and all major Chromium forks support it. Platform authenticators cover every major OS: Touch ID and Face ID on Apple, Windows Hello on Windows, Android biometrics on Android 9+. Use browserSupportsWebAuthn() from SimpleWebAuthn to gate the passkey UI at runtime.
