Passkeys Are Ready: How to Add Them to Your App in 2027

Count the password reset emails your support team handled last quarter. Now count the users who never came back. That gap, between a forgotten password and a successful login, is a tax software has been paying for thirty years.

You can finally do something about it. Passkeys aren't a future bet anymore; your users already know the prompt because their bank taught them. Here's what changed, and the order to roll them out without breaking anyone.

What a passkey actually is

A passkey is a public-private key pair. The private key lives on the user's device (or syncs through their platform account); the public key lives on your server. At sign-in, your server sends a challenge, the device signs it, and your server verifies the signature. That's it.

Notice what's missing: no string the user types, no string your server stores. A database breach yields public keys, useless on their own. And because the cryptography is bound to your domain, a phishing site at yourapp-login.com can't trick the device into signing for the real yourapp.com.

A password is a secret two parties share. A passkey is a secret only one party holds. That's the entire shift.

To the user it's Face ID, Touch ID, Windows Hello, or a PIN. Underneath it's WebAuthn, published by the W3C in 2019 and supported by every major browser and OS. Level 3, the revision that formalizes multi-device passkey behavior, was proposed for full W3C Recommendation status in July 2026. The spec is not a moving target.

What actually changed recently

Passkeys have been usable since 2022. What changed is the friction. Four things tipped the balance:

• Cross-ecosystem sync got real. Apple, Google, and Microsoft each sync passkeys across their own devices, and 1Password, Bitwarden, and Dashlane sync across all of them.
• Passkeys became portable. The FIDO Alliance's Credential Exchange Protocol hands credentials from one manager to another with no plaintext file in the middle; Apple shipped it in iOS 26 and macOS 26, and Android supports it through Google Play services. No more one-way door into somebody's ecosystem.
• Cross-device flows stopped being weird. Signing in on a laptop with a passkey stored on your phone now reliably uses a QR code and Bluetooth handoff.
• Adoption hit critical mass. The FIDO Alliance's May 2026 report put roughly 5 billion passkeys in use worldwide, with 90% of surveyed consumers aware of them and 75% having enabled one somewhere. Microsoft now creates new consumer accounts passwordless by default, and Entra ID makes passkeys the default workforce sign-in from September 2026.

If you tested passkeys in 2023 and decided to wait, the wait is over.

How to add passkeys to your app — in the right order

The biggest mistake is treating passkeys as a flag flip. They're a parallel auth system, and the rollout has to respect that.

Step 1 — Add passkeys as an alternative

On day one, passkeys are an option next to the password flow: both on the sign-in screen, and a "set up a passkey" button in settings next to "change password." Boring, and the most important step — you ship and watch real usage with zero risk of locking anyone out.

Step 2 — Make it the default for new signups

Once that flow is stable, flip new account creation to passkey-first, with "use a password instead" as the smaller secondary option. New users take the default, and within months the share of new accounts that even have a password drops sharply.

Step 3 — Migrate active users

For existing users, add a one-line nudge after a successful login: "Sign in faster next time — set up a passkey." One tap registers the passkey using the already-authenticated session, and the nudge dismisses if ignored. No emails, no fear language. Most active users take it.

WebAuthn's conditional create (mediation: 'conditional') can mint a passkey right after a successful password login with no extra dialog at all — Safari 18+, Chrome 136+ on desktop, Chrome 142+ on Android. It won't fire for everyone, so treat it as upside, not as your migration plan.

Step 4 — Plan recovery, then deprecate passwords

Only once a meaningful share of active accounts has both a passkey and a working recovery method should you talk about removing the password — and "remove" usually means stop offering it at signup, keep it for the long tail. Real deprecation is a multi-quarter project, not a release.

The recovery problem

Here's the part nobody wants to talk about. If a user's passkey is synced to iCloud or Google, losing one device is a non-event — the next device they log into gets the passkey too.

Switching ecosystems isn't the trap it used to be either. Import and export now ship on iOS 26, macOS 26, and Android, so a user moving from iPhone to Android carries their passkeys over, and Android's Restore Credentials hands a FIDO2-compatible restore key to the new phone during setup so a well-integrated app can sign them back in silently.

But what if they lose every device at once, or the cloud account itself gets locked? You need an answer that doesn't need human support for routine cases. The good options, in rough order of strength:

• Multiple passkeys per account. Nudge users to register on a second device or provider. Two is much more than one.
• Email-based recovery with friction. A magic link to a verified email, gated by a delay (say 24 hours) and a notification to every other registered device.
• Backup codes. Classic for a reason: they work when everything else fails.
• Identity verification for high-value accounts. Where accounts hold money or sensitive data, a real ID check is a fair last resort.

What you do not want is SMS as your "secure" fallback. SIM swaps undo every phishing-resistance benefit passkeys give you. Keep an SMS path for legacy reasons if you must, but be honest about it in your security posture — the app security basics every founder should know still apply here.

Native vs WebAuthn vs auth provider

Three integration paths, and the right one depends on where your app lives.

• Platform-native APIs. Apple's AuthenticationServices framework and Android's Credential Manager expose passkeys directly to native apps. Credential Manager reaches back to Android 9, with user-selectable third-party providers from Android 14 on. If you ship native, this is the cleanest path — and it lands alongside the other platform shifts in iOS 27 for indie developers.
• WebAuthn directly. For a web app or a web view inside a native shell, you call navigator.credentials.create() and .get() against a WebAuthn library on your server. Mature libraries exist for Node, Python, Go, .NET, Ruby, and PHP — one more input into the web apps vs native apps decision.
• Auth provider. Auth0, Clerk, Stytch, Descope, and Amazon Cognito all support passkeys today, and Supabase Auth shipped its own in beta in 2026. Check before you assume, though — Firebase Authentication still has no native passkey support, so Firebase shops end up bolting on an extension or a second identity service. Where support exists, turning passkeys on is a configuration change, not a project.

Unless you have a specific reason to roll your own, use the provider or library that already does the work. Auth is where "we built our own" becomes a sentence you regret two years later.

Auth method vs trade-offs

Worth seeing the options side by side:

For most consumer apps, synced passkeys plus email recovery with friction is the sweet spot; for high-security business apps, device-bound passkeys plus admin-mediated recovery. The wrong answer is the same either way: passkey-only with no recovery thinking.

Where people go wrong (and when to call a pro)

Passkeys touch the rest of your account model too. The rules of data privacy for apps apply to how you log, store, and recover credentials, and if you take payments, identity binding matters at checkout — which is why we scope passkey work alongside adding payments to your app rather than as a one-off security ticket. If you'd rather not work this out alone, that's what we do under our services.

Frequently asked questions