Over 80% of web application breaches still trace back to stolen passwords. That’s not speculation. That’s the 2025 Verizon DBIR report talking.
And yet—in 2026—your app is probably still asking users to create a password, store it in their brain (or worse, their Notes app), and type it every time they want to log in. Apple shipped passkey support in 2022. Google followed. Microsoft got there too. But the authentication layer in most production apps? Still stuck in 2005.
The gap isn’t because passkeys are conceptually hard. It’s because the path to shipping them is a minefield of undocumented edge cases, confusing WebAuthn specifications, and an API that looks straightforward in tutorials but explodes the moment you deploy to real users. What does allowCredentials actually do? Why does navigator.credentials.get() silently fail on some browsers? How do you move 500,000 existing users to passkeys without forcing them to abandon their current login flow?
These aren’t rhetorical questions. They’re the obstacles keeping passkeys and WebAuthn from becoming the default instead of the exception.
The Math That Should Scare You
Let’s be specific. Phishing attacks succeed because passwords are a shared secret. Your server knows it. The user knows it. Anyone who intercepts it in transit—or finds it in a breached database—has the key to everything. That’s not a vulnerability. That’s the architecture.
Passkeys invert this entirely.
With a password:
User → sends password → Server compares hash
Attack surface explodes: phishing, credential stuffing, database breach, transit interception.
With a passkey:
User → signs challenge with private key → Server verifies with public key
The private key never, ever leaves the user’s device. The server only stores the public key—which is, by definition, public. Even if your database leaks tomorrow, attackers get public keys. Useless. Completely, cryptographically useless.
“The private key never leaves the user’s device. The server only stores the public key. Even if your entire database leaks, attackers get nothing useful.”—Verizon DBIR 2025
There’s something almost elegant about that constraint. It’s not just a security improvement. It’s a fundamental architectural shift.
Why This Matters More Than You Think
Phishing-resistant authentication isn’t marketing speak. A passkey is cryptographically bound to your domain—your Relying Party ID. A fake login page on evil-example.com cannot trigger a passkey created for example.com. The browser enforces this at the protocol level. No amount of social engineering, no fake TLS certificate, no DNS hijack gets around it. The binding is mathematical.
No shared secrets means no credential stuffing. No hashing, no salting, no hope that your salt was good enough. Your server never touches secret material at all. This isn’t belt-and-suspenders security. This is removing the belt entirely and building suspenders that don’t need it.
And here’s what catches most teams off guard: a passkey is built-in multi-factor. You get “something you have” (the device) plus “something you are” (biometric) or “something you know” (device PIN). That’s MFA-grade authentication without asking your users to install Authy or scan QR codes. It just… works.
How WebAuthn Actually Works (The Part That Breaks in Production)
The Web Authentication API defines two ceremonies: registration (creating a credential) and authentication (using it). The flow looks simple in diagrams.
Browser talks to Server. Server sends a challenge. Browser talks to Authenticator (your phone, security key, whatever). Authenticator prompts for biometric. User approves. Authenticator returns a signed assertion. Server verifies it. Session created. Done.
Except it’s not done. Because allowCredentials might be empty on some browsers. Because navigator.credentials.get() will silently fail instead of throwing an error. Because attestation verification has seventeen different validation paths and you need to choose the right one. Because if your challenge is reused, an attacker can replay the assertion. Because cross-origin requests have specific CORS rules that aren’t obvious.
This is why rolling your own WebAuthn from scratch is a one-way ticket to a security bug you won’t discover until it’s in production. The CBOR parsing, the attestation verification, the challenge management—these are the kinds of things where “close enough” becomes “exploitable in three months.”
The only sane path is a battle-tested library. SimpleWebAuthn is the most widely adopted TypeScript implementation. It’s not perfect, but it’s been through the minefield already.
The Database Schema Nobody Talks About
Here’s where most guides hand-wave. You need two tables.
One for users (standard stuff—UUID, username, display name). One for passkey credentials. And here’s the part that matters: one user can have multiple passkeys. They might have one on their phone, one on their laptop, one on a hardware security key. Your schema needs to reflect that.
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
username VARCHAR(255) UNIQUE NOT NULL,
display_name VARCHAR(255),
password_hash VARCHAR(255), -- Keep this during migration
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE passkey_credentials (
id VARCHAR(255) PRIMARY KEY,
user_id UUID NOT NULL REFERENCES users(id),
public_key BYTEA NOT NULL,
counter INT DEFAULT 0,
transports VARCHAR(255)[],
created_at TIMESTAMPTZ DEFAULT NOW(),
last_used TIMESTAMPTZ
);
That counter field? It prevents cloned authenticators. That transports array? It tells your client whether this passkey lives on USB, NFC, internal storage, or somewhere else. It’s not just database design. It’s the bridge between cryptography and user experience.
The Migration Problem Nobody Wants to Admit
Let’s say you have 500,000 users on traditional password auth. You can’t flip a switch. You can’t force everyone to migrate overnight. Users will abandon your app, call support, blame you for breaking their login.
The phased migration strategy is the only move that works:
Phase 1: Parallel Auth. Both passwords and passkeys work. Users who want to create a passkey can. Everyone else continues with passwords. This runs for months. You’re not forcing anyone. You’re introducing the option.
Phase 2: Nudge, Don’t Force. After passkey creation is popular, start encouraging password users to migrate. A banner, a prompt, whatever. But not a requirement. Some users will always prefer passwords (they’re wrong, but they exist).
Phase 3: Deprecate Passwords. Only after passkey adoption reaches critical mass—70%, 80%, whatever your threshold—do you start sunsetting passwords. And even then, you give people time to migrate before you disable it.
Rushing this will cost you users. Every forced migration that breaks workflow increases churn. The companies that pull off passkey adoption smoothly aren’t the ones that move fast. They’re the ones that move carefully.
What Actually Breaks When You Ship This
Older browsers don’t support WebAuthn. Safari on iOS came late. Android had fragmentation for years. You still need a fallback authentication method. For most apps, that means keeping password auth alive longer than you’d like.
Conditional UI—where the passkey prompt appears inside the password field—sounds smoothly in theory. In practice, it’s browser-dependent. Chrome handles it differently than Safari. Firefox has different timing. You need to test extensively.
Cross-origin requests are a minefield. If your auth server is on auth.example.com and your app is on app.example.com, the RP ID needs to be set correctly or nothing works. This isn’t a subtle bug. It’s a complete failure that takes hours to debug.
Device syncing is real. If a user creates a passkey on their phone, can they use it on their laptop? That depends on the device’s syncing capability (iCloud Keychain, Google Password Manager, Windows Hello). You don’t control this, but users expect it to work.
The Real Cost-Benefit Here
Implementing passkeys isn’t free. It requires architectural changes, database migrations, client-side code, server-side code, testing, staged rollouts, and documentation. The upfront cost is real.
But the breach cost is worse. A single password database leak can cost millions in liability, notification, credit monitoring, and lost trust. Passkeys don’t eliminate that risk entirely—device theft is still a problem—but they eliminate the most common attack vector: the stolen credential.
For fintech, healthcare, or any app handling sensitive data, that trade is obvious. For everyone else, the answer is still yes. The migration is happening whether your app jumps in now or waits three years and plays catch-up.
🧬 Related Insights
- Read more: How TeamPCP’s Self-Propagating Worm Turned Open Source Into a Backdoor Factory
- Read more: I Built a PII Detection API Without Touching AI—And It’s Faster Than Every Enterprise Tool
Frequently Asked Questions
Can I implement WebAuthn without a third-party library? Technically yes. Practically no. The specification is complex enough that building attestation verification, CBOR parsing, and challenge management without battle-tested code is a security risk. SimpleWebAuthn, Passkey.dev, and similar libraries have already found and fixed the edge cases you’ll otherwise discover in production.
What happens if a user loses their phone and their passkey is synced to iCloud/Google? If the passkey is synced to the cloud (iCloud Keychain, Google Password Manager), they can restore it on a new device. If it’s local-only, it’s gone—they’ll need to use a backup passkey or fall back to an alternative authentication method. This is why the “multiple passkeys” strategy matters.
Do I really need to keep password authentication during migration? Yes, unless you want to force your entire user base to adopt passkeys simultaneously (you don’t). Parallel auth means users migrate at their own pace. You support both until adoption is high enough that passwords become a liability instead of a feature.
How long does a typical migration to passkeys take? For a production app with hundreds of thousands of users, plan for 6-12 months minimum. That’s Phase 1 (parallel auth), Phase 2 (encourage migration), and Phase 3 (deprecate old auth). Rushing this costs you users and customer support tickets.
