Passkey adoption roadmap — workforce and customer

Passkeys (FIDO2 + WebAuthn, synced through platform credential providers) are the strongest deliverable upgrade to authentication that has shipped in a decade. They are phishing-resistant by construction, friction-light at the point of use, and increasingly familiar to end users. Every IDP we work with — Okta, Entra, Auth0, ForgeRock — has shipped passkey support. The platform side is largely a solved problem.

The hard part is adoption. For workforce populations, you are asking a help desk to support a credential model fundamentally different from password-and-second-factor. For customer populations, you are asking users to trust the auth surface enough to enroll in something new. Neither is a feature-flag exercise. This piece covers the rollout pattern we use.

Workforce — the four-phase pattern

For workforce passkey rollouts, we sequence in four phases over roughly six months:

Phase 1 — Opt-in for technical populations (weeks 1-4) Engineering, security, and IT users get passkey enrollment offered as an opt-in alongside the existing MFA factor. No fallback removed. Goal: surface platform issues, browser-version edge cases, and helpdesk escalation patterns at low blast radius.

Phase 2 — Opt-in expanded (weeks 5-10) Roll the opt-in to the broader workforce with executive sponsorship and a written FAQ. Track enrollment percentage as a weekly metric. Most healthy programs will see 30-45% workforce adoption by end of phase 2 just from opt-in offering.

Phase 3 — Recommended for new factor enrollments (weeks 11-16) Make passkey the default offered factor on any new device enrollment or any factor reset. Existing users with a working factor are not forced to migrate. By end of phase 3 most organizations are at 60-75% workforce adoption.

Phase 4 — Required for high-risk paths (weeks 17-24) Make passkey required for Conditional Access policies on high-risk paths — privileged access elevation, executive access to financial systems, or production engineering paths. The remaining password+OTP population continues working for low-risk paths but is steered toward enrollment by usage friction.

The pattern hits 80%+ workforce adoption with ~ $0 in helpdesk-load increase if the communications and fallback design is right. The communications and fallback design is where most rollouts fail.

Customer — the three-tier offering

For customer populations, the passkey decision is more nuanced. Customer users have less context, less appetite for new authentication ceremonies, and often more device variability than workforce users. The pattern we use is a three-tier offering:

Tier 1 — Login accelerator Passkey is offered as a faster way to sign in alongside the existing username/password flow. The user is not asked to "secure" or "upgrade" — they are offered "sign in faster on this device." This tier is appropriate for any consumer-facing application.

Tier 2 — Recovery anchor Passkey enrollment is presented as an account-recovery option — useful even if the user prefers password-based primary login. This tier surfaces value for users who hit forgot-password flows.

Tier 3 — Required for sensitive actions For specific high-stakes actions — wire transfers, account changes, fraud-flagged transactions — passkey verification is required. The user does not need a passkey to log in, but they need one for the action.

This tiered model lets passkey adoption grow organically through utility rather than forcing a full credential migration that customers may resist.

The fallback question

The single most important design decision in any passkey rollout is the fallback. What happens when the user's device is lost, the credential provider has issues, or the user wants to access from a device without their passkey synced?

For workforce, the canonical fallback is helpdesk-mediated identity verification followed by re-enrollment. The helpdesk runbook has to be written before passkeys reach beyond opt-in phase 1. Passkey rollouts where the helpdesk runbook is an afterthought generate disproportionate ticket volume and adoption resistance.

For customer, the canonical fallback is a one-time-code via email or SMS that re-enrolls a passkey on a new device. The recovery flow has to be designed against the same threat model as primary login — otherwise the passkey itself becomes a security theater. We engineer the recovery surface explicitly and stress-test it before customer rollout.

Platform-specific notes

Okta: Strong passkey support across Workforce and CIC. The Verify mobile app supports synced passkeys; security-key-bound passkeys also work natively. Configuration is well-documented; the rollout work is communications and helpdesk readiness.

Microsoft Entra ID: Native support via Authenticator app and security keys. Microsoft's enterprise-side passkey synchronization (via Authenticator) is differentiated for organizations standardized on the Microsoft stack.

Auth0 (Okta CIC): Passkey is now the recommended customer-identity factor. The migration from a passwords-only flow is well-supported via Universal Login templates.

ForgeRock / Ping: Passkey support is mature. The differentiation is in DaVinci flow orchestration — passkey enrollment and recovery flows fit naturally into the journey-builder model.

The bottom line

Passkey rollout is not a feature flag. It is a sequenced communications, fallback, and recovery program — with the platform configuration as the smallest part of the delivery. Plan the helpdesk readiness and the recovery flow before the technical rollout. Adoption follows.