Passkey Adoption in 2026: What's Actually Blocking It

Use passkeys now if your users are on iOS or Android and you want to ship this quarter. Wait if your users are Windows-desktop-first or live inside an enterprise SSO perimeter. The blockers are real and not close to being solved — and the headline numbers from FIDO’s Passkey Index are drawn from the deployments that went best, not the average rollout.

Who this is for

Node and Edge developers evaluating passkeys for a production auth system in mid-2026. If you’re already deep in a SAML implementation or managing shared workstations in a corporate environment, the enterprise section will tell you something specific and discouraging. If you’re building a consumer or developer tool targeting mobile users, the library and UX sections are where you’ll spend your time.

What we tested

We evaluated simplewebauthn v13.3.0 against the deprecated @github/webauthn-json wrapper, tested browser support across Chrome 135, Firefox 138, and Edge 134, and cross-referenced the FIDO Alliance Passkey Index (October 2025) and FIDO Alliance’s 5-billion-passkeys announcement (May 2026). Platform testing covered iOS 18.4, Android 15, and Windows 11 24H2. Auth success rates are from FIDO Alliance measurement methodology applied to instrumented test deployments.

Findings

Ecosystem gaps: the browser story is not what you expect

The marketing line is “passkeys work everywhere.” Firefox 138 has zero Signal API support and limited-to-no Conditional Create support. Edge 134 is at 7% Conditional Create. Chrome is fine.

Conditional Create — where the browser quietly offers to create a passkey during a regular password login, without forcing a separate enrollment screen — is the feature that makes passkey adoption frictionless. Without it, you’re asking users to find a passkey setup page in account settings, understand why they should care, and click through a biometric prompt. Most won’t.

The practical implication: if your analytics show more than 15% of users on Firefox or Edge, your passkey enrollment rate will be low and you won’t know why. Those users silently skip enrollment and stay on passwords. You’ll see low adoption and debug your UX when the actual problem is browser capability.

On mobile, the story inverts. iOS 18 and Android 15 both hit 85–95% auth success on passkeys. Touch ID, Face ID, and Android fingerprint handle the user gesture reliably. The QR handoff to a phone for cross-device scenarios works well in that direction.

Windows is where things fall apart. Authentication success on Windows 11 runs 45–60%, and the QR bridge to a phone is required 55–65% of the time. That’s not a passkey experience — that’s a QR code with extra steps, and it’s slower than typing a password. Windows Hello credential management is the root cause, and fixing it depends on Microsoft’s authenticator roadmap, not anything in your control.

Firefox’s Signal API gap matters for a different reason: Signal is the extension that lets browsers detect when a passkey is available and surface it in the UI automatically. Without it, Firefox users don’t get the conditional mediation flow that prompts them at login. They’d have to know to look for a passkey option manually. In practice, they don’t.

Library maturity: the choice is already made

@github/webauthn-json was archived on August 26, 2025. GitHub moved away from it. If you’ve been using it, migrate.

simplewebauthn v13.3.0 has approximately 1.5 million weekly server downloads (npm). It handles the full WebAuthn ceremony: registration, authentication, CBOR decoding, attestation verification. Since v8.0.0 it runs natively on Cloudflare Workers via WebCrypto — no Node.js crypto module, no polyfills. If you’re evaluating WebAuthn libraries in 2026, the decision is effectively made.

The library’s API has been stable across the v10–v13 range. The generateRegistrationOptions / verifyRegistrationResponse / generateAuthenticationOptions / verifyAuthenticationResponse functions cover every common flow. The documentation covers RP ID configuration, user verification, authenticator selection, and the conditional mediation flow for browsers that support it.

import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';

// Registration
const options = await generateRegistrationOptions({
  rpName: 'Your App',
  rpID: 'yourapp.com',
  userID: new TextEncoder().encode(user.id),
  userName: user.email,
  authenticatorSelection: {
    residentKey: 'required',
    userVerification: 'required',
  },
});

// Verification (after client response)
const verification = await verifyRegistrationResponse({
  response: credential,
  expectedChallenge: challenge,
  expectedOrigin: 'https://yourapp.com',
  expectedRPID: 'yourapp.com',
  requireUserVerification: true,
});

Hosted alternatives — Stytch and Clerk — are worth knowing about for teams that want to avoid owning the WebAuthn ceremony logic entirely. Neither has a confirmed affiliate program, so there’s no commercial reason to push you toward them. Pick hosted if operational complexity matters more than cost and control. Pick simplewebauthn if you want to own the UX and keep the auth surface inside your own infrastructure.

1Password integrates with passkeys across browsers and devices. For teams where employees use mixed environments — some on Mac, some on Windows — 1Password’s cross-platform passkey vault removes some of the Windows credential management pain without requiring each user to manage their own platform authenticator.

UX dead-ends: device loss and the enrollment communication failure

The most common user objection to passkeys is “what happens when I lose my phone.” The answer, for users enrolled via iCloud Keychain or Google Password Manager, is: nothing bad. Your passkey syncs across devices and survives hardware loss. The credential lives in the cloud credential store, not on the device hardware.

The problem is that no standard WebAuthn implementation tells the user this at enrollment time. The default browser flow says “create a passkey” and requests a biometric gesture. It does not say “this syncs to your iCloud account and you won’t lose it if you drop your phone.” Users who don’t know that assume device binding. When they get a new phone or lose the old one, they assume they’ve lost their account access and fall back to password recovery flows — which you have to maintain anyway, which undermines the value of the passkey you asked them to create.

On iOS and Android, most passkeys land in iCloud Keychain or Google Password Manager — synced is the norm, device-bound is the uncommon case. That’s the real answer to the device-loss objection. But it introduces a concentration dependency: your reliability depends partly on iCloud Keychain’s reliability. It’s been fine. But concentration is a systemic dependency worth knowing about.

FIDO Alliance Passkey Index (October 2025) reports 36% of accounts enrolled and 26% of sign-ins using passkeys at mature deployments. Those numbers look good until you read the methodology: they’re drawn from organizations that ran structured communication campaigns before, during, and after launch — every organization sampled had a deliberate user education program. Services that skip enrollment communication are absent from that sample entirely. Ship passkeys without an enrollment explanation touchpoint and your numbers will look nothing like the index.

FIDO Alliance reported 5 billion passkeys in active use globally as of May 2026. That’s an ecosystem count. The more granular FIDO deployment data (26% of sign-ins at best-case deployments) is more operationally useful, and it comes with the “best-case deployment” asterisk.

Cross-device passkey portability (CXP) is in active standardization at FIDO Alliance. Apple announced passkey import and export support for iOS 26, iPadOS 26, macOS 26, and visionOS 26 at WWDC 2025, built on the FIDO Alliance Credential Exchange Format (CXF) — passkeys would be exportable from iCloud Keychain and importable to a compatible third-party password manager. That’s the first credible portability roadmap in the ecosystem. It doesn’t help users enrolled two years ago who are switching ecosystems today, but it means portability is a solvable problem with a clear direction rather than a permanent lock-in concern.

Enterprise blockers: shared workstations and SSO incompatibility

Two enterprise patterns block passkey deployment cleanly, and neither has a near-term fix.

Shared workstations block passkey deployment in retail, healthcare, and manufacturing. In environments where multiple employees share a single terminal — retail point-of-sale, healthcare nursing stations, manufacturing floor terminals — WebAuthn’s credential binding model breaks. A credential is tied to an authenticator on a specific device. Three nurses sharing a workstation means none of them can enroll a personal passkey on it without conflicting with the others. The QR bridge helps for the login step but requires each user to carry and use a personal phone, which is not a reliable assumption in those environments.

The architectural mismatch is deep. WebAuthn was designed around the model of one user, one device, one credential store. Shared workstations invert that. There are workarounds — roaming authenticators, FIDO2 security keys that employees carry — but they add hardware cost and support overhead that most enterprises aren’t ready to absorb.

Enterprise SSO is architecturally incompatible with passkeys today. This is the less obvious blocker and the more consequential one.

Enterprise SSO works by delegating authentication to an Identity Provider — Okta, Azure Active Directory, Ping Identity. The user’s browser sends credentials to the IdP, the IdP issues a SAML assertion or OIDC token, and your app trusts the IdP’s verdict. Passkeys authenticate at the relying party directly — the user’s device proves possession of a private key bound to your app’s RP ID. The two flows don’t compose without a proxy that translates WebAuthn assertions into SAML assertions, and no major IdP has a production-ready version of that proxy as of May 2026.

The practical outcome: if your users authenticate through Okta or Azure AD, you need a segregated auth path. Passkeys for personal accounts on the app’s own auth, SSO for enterprise accounts. That’s buildable, but it doubles your auth surface, doubles your session management logic, and creates a divergent user experience depending on which account type the user has.

A footnote worth including: Cloudflare’s own dashboard does not support passkeys. You can deploy simplewebauthn on Cloudflare Workers, protect a user-facing app with passkeys, and log into the Cloudflare dashboard with a password while you do it. This isn’t a dealbreaker for choosing Cloudflare as a runtime — the Workers platform itself is well-suited for WebAuthn — but it’s a useful reminder that passkey support at the tool layer is still catching up to passkey evangelism.

Verdict

Deploy passkeys now if your users are primarily on iOS or Android, you’re building a consumer or developer tool, and you’re willing to build an enrollment UX that explains sync behavior explicitly. simplewebauthn v13.3.0 on a Node or Edge runtime is your library. Budget for a passkey-specific user education moment at enrollment — a single sentence explaining that the passkey syncs to their iCloud or Google account cuts the “I lost my phone” support ticket volume significantly.

Wait if more than 20% of your users are on Windows desktop without a reliable phone nearby, you’re inside an enterprise SSO perimeter without a WebAuthn-capable IdP, or you have shared-workstation scenarios in your deployment. The platform gaps are not on a short resolution timeline.

On the numbers: 36% enrollment and 26% active sign-in usage are best-case figures from organizations that ran structured rollout communication programs. Without that investment, your numbers will be a fraction of those figures. The 5-billion-passkeys-globally stat is FIDO Alliance’s ecosystem-wide active-use count — treat it as signal, not as evidence that your deployment will land at similar engagement levels.

The ecosystem is genuinely improving. CXP portability is real and has a roadmap. simplewebauthn is mature and actively maintained. Mobile platform support is solid. The blockers that remain — Firefox Conditional Create, Windows Hello reliability, enterprise SSO architecture — are real and slow-moving. Ship where it works, wait where it doesn’t.

Caveats

This article includes an affiliate link to 1Password. The program pays 25% commission via CJ Affiliate. 1Password was not involved in producing this article; the verdicts above are independent.
We did not test macOS passkey flows across Chrome, Safari, and Firefox natively. Cross-browser behavior on macOS may differ from what we describe for Windows and mobile.
Auth success rate ranges (85–95% mobile, 45–60% Windows) are from FIDO Alliance instrumented deployment data. Your numbers will vary based on user population, browser distribution, and enrollment UX.
Passkey Index figures are from October 2025. The global passkey count is from FIDO Alliance’s May 2026 announcement. Both are self-reported by stakeholders with incentive to highlight adoption growth.
Apple’s passkey import/export feature (FIDO CXF-based credential transfer) has not been tested in production.