Passkeys past the pilot: the three engineering problems B2B SaaS teams hit in production
Account recovery, shared devices, and phased rollout — the problems the vendor docs skip
The pilot goes well. Ten engineers authenticate with Face ID. Latency is low. The FIDO2 flow works. Someone shows the PM a demo and it looks like magic. You greenlight the migration.
Three months later you're still running passwords alongside passkeys, support tickets have shifted to "I can't log in on my new laptop", and the engineering team is debugging edge cases nobody mentioned in any blog post.
This is the passkey migration stall. It's common enough that it deserves a name. Here's what causes it — and how to get past it.
The pilot works. The migration doesn't.
Passkeys are genuinely better than passwords. They're phishing-resistant, faster to authenticate with, and they eliminate the entire class of credential-stuffing attacks that plague SaaS products. The FIDO Alliance's 2025 benchmark data puts passkey auth success rates above 96% for consumer use cases.
B2B SaaS is not consumer. B2B SaaS has account recovery flows that your password reset emails used to handle. It has shared devices in field operations, retail, or kiosk environments. It has legacy SSO integrations that need to keep working. And it has users who switch between three devices and a web browser every day.
The pilot doesn't surface these. The pilot has ten engineers on personal MacBooks authenticating with Touch ID. The production rollout has a logistics coordinator sharing a tablet with four colleagues.
The three problems below are where production migrations stall. Each one is solvable. None are obvious from the FIDO spec or from vendor documentation.
Problem 1: account recovery without a password fallback
When you had passwords, account recovery was simple: send an email with a reset link. The email address was your ground truth. Passkeys break this assumption.
A passkey is a cryptographic key pair stored on a device or in a syncing password manager like iCloud Keychain or 1Password. If the user loses their device and hasn't synced their passkey elsewhere, the credential doesn't automatically exist anywhere else. Recovery becomes: what is your source of truth for proving identity when the device is gone?
Three patterns handle this, each with different tradeoffs:
| Pattern | How it works | Tradeoff |
|---|---|---|
| Recovery codes | At first passkey enrollment, generate a 16-character code shown once and not stored server-side. User stores it. If device is lost, code triggers re-enrollment on a new device. | Clean and phishing-resistant, but 10–15% of recovery requests involve users who never saved the code. |
| Trusted device + email re-enrollment | If another enrolled device exists, allow re-enrollment from it. If no trusted devices remain, send a time-limited email link that opens a new credential registration flow — not a direct login link. | Good UX fallback. The email link's value is a re-enrollment token, not a session, so phishing resistance is preserved. |
| Admin-assisted recovery | An org admin initiates recovery; the user receives a time-limited re-enrollment link. Auditable, and matches how enterprise IT teams expect identity recovery to work. | Right default for B2B. Requires an admin being reachable, which is occasionally a blocker for solo accounts. |
Problem 2: shared devices and the kiosk problem
A passkey stored on a device is bound to that device unless it syncs through a credential manager. For personal devices, this is fine. For shared devices, it creates problems that vendor documentation mostly skips.
The scenario: a field service team shares an Android tablet. Each technician has their own account. Three realistic options exist, ranked by operational complexity:
| Approach | Works when | Breaks when |
|---|---|---|
| Passkeys per device, multiple enrollments | Users always use the same device and the device set is stable. | Users rotate across many devices. You end up managing a user-device matrix that recovery makes complex. |
| Hardware security keys (FIDO2 tokens) | Each person has their own YubiKey or equivalent. Works on any device they plug it into. | Procuring, distributing, and replacing keys for a 100+ person field team. Overhead is real. |
| SSO as the identity layer | Your enterprise customers already use Okta, Entra ID, or Google Workspace for identity. | Customers without a corporate IdP. Routing through SSO adds friction for small organisations. |
For true kiosk deployments — retail terminals, hospital workstations, shared manufacturing tablets where no individual owns the device — passkeys don't fit well today. Hardware tokens or continued password auth for that specific subset of users is not a failure. Shipping passkeys for 90% of your user base while carving out a clear exception for kiosk workflows is a better outcome than delaying the entire rollout waiting for a perfect solution.
Problem 3: phased rollout without two auth stacks indefinitely
The tempting approach: add passkeys as an optional alternative to passwords, with passwords still fully working. Safe migration path. Also the path to running two auth stacks for two years.
"Optional" means almost no users opt in. Passkey adoption without friction on the password path typically lands in the single-digit percentages. Users keep using passwords because passwords work and authentication isn't something they think about.
A phased rollout that actually ends needs a forcing function. Specifically:
Gate new registrations on passkey. New users who sign up after your rollout date only see passkey enrollment. No password setup for new accounts. This is the lowest-friction gate — new users have no muscle memory to override.
Prompt existing users incrementally. After a successful password login, show an inline enrollment prompt — not a blocking modal. Track dismissals. After three dismissals, increase prominence. After six, make enrollment a hard gate with an explicit opt-out that captures a reason.
Set and communicate a deprecation date. 9–12 months after rollout start, password login is disabled for accounts that have a passkey enrolled. Communicate this in-product at 90, 60, and 30 days. Users who haven't enrolled receive a deadline email at the 30-day mark.
The support cost delta: what actually happens
Marketing materials for passkey adoption often cite support ticket reductions. The claim is accurate, eventually. The transition period is different.
In the 60–90 days following rollout, expect an increase in auth-related support: account recovery requests, "I can't log in on my new phone", confusion about what a passkey is. IT admin requests spike for teams sharing accounts or using shared devices.
Ticket volume drops below the pre-rollout baseline once recovery flows are well understood and the user base is past the initial confusion. The reduction arrives six to nine months in, not in the first quarter. Plan support capacity for the transition window, and invest in a clear in-product "what is a passkey" explanation at first enrollment — one well-written paragraph deflects a meaningful share of tickets.
The net reduction, once stable, is real. Password reset emails account for a significant share of auth support volume on most platforms. When passwords are no longer the primary credential, that category of ticket essentially disappears.
What to measure before calling it done
Four metrics that signal a passkey migration is complete rather than just started:
- Passkey auth rate: the percentage of successful logins completed via passkey. Target 80%+ of active user-months before deprecating passwords. Deprecating at 40% means a large cohort isn't ready.
- Recovery event rate: how many logins in a given period required account recovery. Should trend downward as users enroll passkeys on multiple devices. A sustained upward trend signals a gap in re-enrollment prompting.
- Auth success rate by browser and OS: segment passkey success by client type. Firefox, older Android, and Samsung Browser historically produce the highest WebAuthn edge cases. A materially lower success rate in one segment is a signal to debug that surface before widening the rollout.
- Time-to-login at P95: passkey auth should be faster than password login for most users. If P95 isn't improving, check whether your relying-party server round-trip or assertion verification is on the critical latency path.
The passkey migration stall isn't inevitable. It comes from skipping recovery design, from not thinking about shared devices before deployment, and from leaving rollout optional with no real forcing function. Solve those three problems first, and the migration proceeds like the pilot: cleanly, with no moment where someone decides to roll it back.
Frequently asked questions
Related reading
The second brain, three years in: what worked, what was theatre, and what AI changes
Three years after the second brain movement peaked, most engineers have quietly stopped opening their PKM systems. Here is what worked, where things collapsed, and what three habits actually survived real deadlines.
Model Context Protocol: what it actually standardises (and what you'll still have to build yourself)
MCP is becoming the standard interface for connecting AI agents to external tools. But most teams adopting it don't have a clear picture of what the protocol covers and what it deliberately leaves out.
The minimum viable security posture for a 10-person SaaS
Six controls close most of the risk surface for a 10-person SaaS: secrets out of code, MFA everywhere, dependency scanning, tenant isolation by design, access logs, and a single IdP. Most are free.