Rolling Out Passkeys in the Enterprise: An Adoption Roadmap for Security Teams

If your security team has decided to move away from passwords, the harder question usually isn’t “why passkeys” — it’s “in what order.” A passkey rollout that starts broad, before the recovery process and device inventory are solid, tends to produce a helpdesk-ticket spike within the first two weeks that stalls the whole project. This roadmap walks through the prerequisites, a staged sequencing that has held up in practice, and the four operational problems — recovery, shared devices, audit trail, and credential type — that decide whether a rollout survives contact with a real workforce.

If your organization has already run an MFA rollout, some of this sequence will feel familiar — the pilot-then-wave structure, the tiering by account risk, the recovery-process buildout. What’s different with passkeys is that the recovery problem is harder, because a passkey doesn’t have the SMS-code fallback a phone-based MFA method can lean on when something goes wrong, and the audit story is stronger, because a properly scoped credential-type decision gives you a defensible answer to “which assurance level protects this account” that a generic “we have MFA” answer doesn’t.

Why Passwordless Is Worth the Migration Cost Now

Passwords fail in two predictable ways: they’re phishable, and they’re reused across services in ways no policy fully prevents. FIDO2/WebAuthn passkeys address both at the protocol level. The FIDO Alliance’s specification describes the mechanism directly: the relying party issues a cryptographic challenge that only the correct private key can answer, and every credential is bound to the specific service origin it was registered against — which is what makes the exchange resistant to phishing, credential relay, and the kind of large-scale credential-stuffing that plagues password-based logins¹. A biometric or PIN check is the local unlock gesture that releases that private key on the device; the biometric data itself never travels to the server, and the server only ever verifies the cryptographic proof.

That’s a materially different security property than “password plus a second factor,” and it’s why the FIDO Alliance’s Enterprise Deployment Working Group has published a dedicated series of white papers — moving from an introduction through moderate-assurance guidance to high-assurance enterprise deployment — aimed specifically at organizations replacing password-only or legacy MFA with passkeys¹. The existence of that series is itself a signal: enough enterprises have hit the same rollout problems that FIDO judged a shared playbook worth writing.

Prerequisites Before You Pilot

Three decisions need to be made before a single user is enrolled, and skipping any of them is the single most common cause of a rollout that has to be paused and redesigned mid-flight.

Device-bound versus synced passkeys. A device-bound passkey is generated on one piece of hardware — typically a security key — and never leaves it; a synced passkey replicates across a user’s devices through a platform sync fabric (an Apple, Google, or Microsoft account, or an enterprise-managed equivalent). NIST’s supplement to SP 800-63B treats these differently: synced passkeys can meet Authenticator Assurance Level 2 (AAL2) when the sync fabric enforces strong encryption and MFA-protected access to the private keys and the cryptographic operation stays local to the device, while device-bound passkeys — which by construction can’t be cloned off the original hardware — support AAL3, the level generally expected for administrators and other high-value accounts². In practice, this means most of the general workforce is a reasonable fit for synced passkeys tied to a managed identity provider, while your most privileged accounts need device-bound hardware keys as a deliberate exception, not an oversight.

Identity provider and MDM readiness. Enterprise passkey management depends on the identity provider being able to enforce passkey policy centrally — which users can register a passkey, whether registration requires a managed device, and how a credential gets revoked when an employee leaves or a device is reported lost. If your identity provider or MDM can’t attest device compliance at registration time, you’re deploying passkeys with no way to answer “which devices hold a valid credential for this account” later, which is exactly the visibility gap an auditor will ask about first.

Fallback authenticator inventory. Not every account can go passkey-only on day one. Shared workstations, some legacy line-of-business terminals, and users on devices that predate WebAuthn-capable browsers need a defined fallback — typically number-matched push MFA — tracked explicitly as interim, with a migration date, not left as the permanent answer for that segment.

A Staged Rollout Roadmap

1. Pilot with a small, technically fluent group first. IT and security teams themselves are the right first cohort — they can absorb rough edges in the enrollment flow and surface device-compatibility gaps before a wider audience hits them. Keep the pilot to two to four weeks; the goal is finding failure modes, not proving the concept works in principle.
2. Tier the rest of the organization by blast radius, not by department. Administrators, finance approvers, and anyone with standing production access should be the second wave, moving to device-bound passkeys specifically — this is the segment where an AAL3-grade credential matters most, and it’s also small enough that recovery-process gaps surface on a manageable scale before the general rollout.
3. Build and rehearse the recovery path before wave three, not after. Define who can re-provision a lost credential, what identity proofing that requires, and how the event is logged — and actually run a tabletop exercise of a lost-device scenario before extending passkeys to a population large enough that lost devices become a weekly occurrence.
4. Extend to the general workforce, provisioning synced passkeys through the managed identity provider for standard-issue hardware, and routing shared-device and legacy-hardware segments to the security-key or number-matched-push fallback defined in the prerequisites step.
5. Sunset the password fallback deliberately, department by department, once each segment’s passkey coverage is confirmed — rather than leaving a permanent password option “just in case,” which quietly reopens the exact phishing surface the migration was meant to close.

Where Rollouts Actually Get Stuck

Recovery operations. This is the problem every enterprise passkey deployment eventually runs into, and it’s the one the FIDO Alliance’s enterprise guidance calls out as needing to be solved before rollout, not retrofitted afterward¹. A lost device with the only bound passkey for an account is a helpdesk-mediated identity-proofing event. If that process isn’t designed and staffed in advance, it becomes the attack surface itself — a social-engineered helpdesk reset can bypass a phishing-resistant credential entirely. That’s a judgment call worth writing down explicitly as a documented risk-acceptance decision, not assumed to be covered by “the helpdesk will figure it out.”

Shared and legacy devices. Platform passkeys assume one user, one device with a secure enclave and biometric or PIN unlock. Shared kiosks, some point-of-sale terminals, and older machines without WebAuthn-capable browsers don’t fit that model. A portable, device-bound security key the user carries between machines is usually the more workable fit for this segment than trying to force platform passkeys onto shared hardware.

Audit trail and compliance mapping. For organizations that need to demonstrate control maturity — SOC 2, ISO 27001, or a customer security questionnaire — being able to state explicitly which account tier runs on which assurance level is often as valuable as the technical protection itself. Mapping your credential-type decision to NIST’s AAL tiers, as above, gives you that language for free, but only if the decision was made deliberately and documented, rather than left implicit.

Vendor selection coming before the sequencing decision. It’s common for a passkey initiative to start with a vendor comparison — which identity platform or hardware key issuer to standardize on — before the organization has settled its own rollout sequencing, credential-type policy for high-value accounts, and recovery design. Any credible vendor’s platform can implement the FIDO2/WebAuthn protocol; the roadmap decisions above are what determine whether a given deployment actually closes the phishing gap, largely independent of which vendor’s console the team is using. Vendor selection is a real decision, but it should follow the roadmap, not substitute for it.

Measuring Whether the Rollout Is Actually Working

A passkey rollout that’s tracked only by enrollment percentage will look successful right up until it isn’t. Enrollment counts how many users registered a credential; it says nothing about whether the fallback password path has actually been closed, or whether a large share of “enrolled” users are quietly still logging in with a password because their passkey enrollment stalled on a device-compatibility issue nobody followed up on. Three additional metrics catch that gap: the percentage of logins in a given week that actually used a passkey rather than the fallback, broken out by department so a stalled segment is visible rather than averaged away; the median and 90th-percentile time to resolve a recovery request, which is the number that tells you whether the recovery process from the prerequisites step is holding up under real volume rather than just the tabletop exercise; and the count of accounts still holding an active password credential past their scheduled migration wave, which is the metric that catches a “sunset the password” step that quietly never finished. None of these require new tooling beyond what the identity provider and helpdesk ticketing system already log — they require someone to actually pull the numbers on a cadence, which is the part that gets skipped when a rollout is judged complete at the enrollment milestone instead of the usage milestone.

A Judgment Call Worth Writing Down Explicitly

Two decisions in this roadmap don’t have a universally correct answer, and treating them as settled without documenting the reasoning is where audits and postmortems tend to find gaps later. The first is the recovery-process risk-acceptance decision noted above: whoever approves the helpdesk identity-proofing workflow is implicitly accepting a residual social-engineering risk on the recovery path, and that acceptance should be written down with an owner’s name attached, not left as an implicit assumption baked into a runbook nobody signed off on. The second is the fallback-authenticator sunset date for shared and legacy devices — it’s tempting to leave that segment on number-matched push indefinitely once the rest of the organization has migrated, because the remaining population is small and the pressure to finish is gone. Writing an explicit date, even a generous one, keeps that segment from becoming the permanent phishable gap in an otherwise phishing-resistant environment.

How This Connects to Broader Zero Trust Work

Passkey adoption is one piece of an identity-centric access model, not the whole of it — a strong authenticator on a compromised or unmanaged device still leaves a gap. Teams building out this roadmap alongside a broader zero trust architecture program should read it together with the zero trust architecture hub, which covers how identity, device posture, and network access policy fit together. For teams evaluating passkeys as one option among several MFA methods rather than a settled decision, the MFA and biometric authentication comparison guide lays out the phishing-resistance and recovery tradeoffs across the full method set. And for the identity-and-access-management domain knowledge that underpins both, the CISSP domains overview covers where authenticator assurance fits within a broader security body of knowledge.

Sources

• FIDO Alliance — Enterprise Deployment Resources and Working Group white paper series
• NIST — Incorporating Syncable Authenticators into SP 800-63B (supplement)