The passkey tipping point.

The threshold crossed

Every category has a year where the recommended-for-new-builds choice quietly becomes the expected choice, where buyers stop asking "should we" and start asking "why haven't we." For passkeys in CIAM, 2025 was that year.

The shift was visible in three places at once. New-deployment RFPs led with passkey questions rather than buried them on page four. Existing deployments accelerated migration timelines from "next-year roadmap" to "current quarter." And the vendor field stratified by whether passkeys were a first-class default or an opt-in retrofit. The category's leading products treated the answer as obvious; the laggard tier acted as if the question were still open.

What "passkey-first" actually means in 2026

The phrase has been overloaded. By the second half of 2025, the operating definition that mattered for procurement was specific:

1. Registration is passkey-first by default. A new user signing up sees a passkey prompt as the primary call-to-action, with password or email-link as a fallback, not the inverse. The default flow does not require a password at any step.
2. Authentication is passkey-first by default. A returning user with a registered passkey sees the passkey prompt first; password fallback is available but secondary.
3. Cross-device passkey transfer is supported. Users with passkeys on one device can authenticate from a second device through the platform's passkey-share flow (QR-code mediated, typically) without falling back to email recovery.
4. Account recovery has a credible non-passkey path. This is the subtle one, passkey-first is not passkey-only. The recovery flow needs to handle device loss, theft, and family-of-four account-shared-devices without degrading the security posture of the underlying account.

A vendor that ships #1 and #2 but skips #3 and #4 has a passkey demo, not a passkey product. The 2025 stratification was largely about which vendors crossed all four lines.

Who shipped against the full spec

Hanko and Corbado built their entire products around passkey orchestration and remained the cleanest reference implementations for buyers who want passkey-first as the entire identity stack rather than as a feature within a broader platform. Each shipped credible cross-device flows and meaningful fallback machinery during 2025.

Stytch generalized the same depth into a broader platform, passkey-first defaults inside a CIAM that also covers magic links, SSO, and SCIM. The 2025 product cadence here was unusually disciplined.

Descope continued to lead on the no-code-orchestration shape, the passkey flow is composable inside a visual flow builder, which matters disproportionately for product-and-design teams making the passkey UX decisions without engineering review.

Transmit Security and Beyond Identity continued to win the enterprise-shape passkey deployments, Transmit on the consumer side for scale orchestration and risk weighting, Beyond Identity on the workforce side for binding-to-device assertions.

Auth0 and WorkOS delivered platform-grade passkey support without making it the core story, both are credible picks for buyers who want passkeys plus a deeper standards stack rather than passkey-orchestration specialists.

Clerk shipped passkey-first defaults in the dev-first segment and made the migration UX (existing-password users prompted to add a passkey on next login) genuinely good.

Who didn't

The legacy B2C tier mostly did not.

The pattern was consistent: vendors whose product strategy preceded the passkey-default shift treated the 2025 transition as a feature add rather than a default-flow rewrite. The result was passkey support that technically existed but was not the recommended path, opt-in, buried in account settings, sometimes only available after a separate enablement step. For new deployments, this is a procurement signal: the platform's defaults reveal what the platform's product strategy expects you to use.

LoginRadius is the most explicit example in this index, no native WebAuthn support at the level required for a passkey-first deployment, a material gap relative to every modern competitor. Several other legacy B2C platforms (some not yet covered on CIAM Compass) sit in similar positions.

The remaining unsolved work

The 2025 transition mostly solved the happy-path passkey deployment. The unfinished work is everything that happens when the happy path breaks.

Account recovery without password reset. Once a deployment commits to passkey-first defaults, the password fallback is supposed to wither. But the recovery flows, "I lost my phone, I need to log in", still default to email or SMS reset, which means the password (or its equivalent) is still part of the security model. Several vendors made progress here in late 2025; none have a fully closed loop.

Device loss with binding assertions. For workforce-leaning deployments that use device-bound credentials (Beyond Identity, Transmit), the device-loss recovery flow needs to balance security and the help-desk ticket volume. The 2025 patterns are still emerging.

Cross-platform UX consistency. Passkey flows differ subtly between iOS, Android, Windows Hello, and 1Password / Bitwarden / Dashlane. CIAM vendors mostly cannot fix this; they can choose how aggressively to abstract over it. The current default is "expose the platform UX," which is correct, but produces visible inconsistency that confuses end users.

Audit trail of passkey provenance. Which device added which passkey, when, from where, attested by what authenticator, this matters disproportionately for regulated industries, and 2025's audit-log conventions are uneven across the field.

These four unfinished problems are the 2026 work. They're not category- defining the way the basic passkey-default question was in 2025, but they are the difference between a passkey deployment that survives the first year and one that gets reversed under help-desk pressure.

The procurement implication

For 2026 evaluations, the passkey-readiness checklist is straightforward:

1. Is passkey the default in registration? Not "supported", the default.
2. Is passkey the default in returning-user authentication?
3. Is cross-device passkey transfer supported without falling back to email?
4. What does account recovery look like for a user who has no password and no other registered device?
5. What audit trail exists for which passkey was added when, from which device, attested by which authenticator?

Vendors that answer all five with shipped, production-tested responses are the 2026 leader tier (see the passwordless-specialist segment award). Vendors that answer the first two but not the rest are challengers. Vendors that don't have passkey defaults at all are not on the table for new builds, passkeys crossed that threshold in 2025 and won't cross back.