Passkey Rollout Guide: Moving Users Off Passwords

Most passkey programmes do not fail on cryptography, they stall on change management: low enrolment, legacy apps that still need passwords, and recovery paths that quietly bring phishable methods back. Passkeys are now well standardised, with W3C Web Authentication Level 3 published as a Recommendation and NIST SP 800-63B-4 setting out how syncable authenticators fit assurance levels. The hard part is moving thousands of people and hundreds of applications from passwords to passkeys without breaking sign-in or opening a help desk back door. This guide covers the rollout itself: phasing and pilot rings, the choice between synced and device-bound passkeys per population, enrolment and recovery design, enforcement and password removal, and the metrics that tell you it is working. It is for IAM programme leads, identity engineers and service desk managers. For how passkeys and WebAuthn work, read the Passwordless and Passkeys Guide first; this guide does not repeat it.

Key takeaways

• Add before you remove. The FIDO Alliance rollout guidance introduces passkeys alongside existing sign-in methods and phases out legacy options only once passkeys are delivering, which keeps disruption low.
• Choose the passkey type per population, not per organisation. Synced passkeys suit scale and convenience at up to AAL2; device-bound passkeys on security keys or managed hardware suit administrators, regulated roles and AAL3.
• Recovery is the real security boundary. If a phone call, emailed link or knowledge question can register a new passkey, attackers will use that path, as help desk impersonation incidents show.
• Enforce with dates and policy, not just encouragement. Organic opt-in plateaus; a published deadline, conditional access and blocking password-first sign-in where a passkey exists finish the job.
• Measure the passwords that remain. Track enrolment, the share of sign-ins made with a passkey, password resets and fallback use, and treat every app that still needs a password as a backlog item.

Before you start: baseline and success criteria

The FIDO Alliance workforce deployment guide (published on Passkey Central) begins with two prerequisites before any phase: assess the environment and define success. In practice that means:

• Authentication inventory: current methods per user group (password only, SMS, app codes, push, smart card), the identity provider's capabilities (conditional access, device trust, passkey policy controls) and every application that does not federate to the IdP.
• Device and platform inventory: managed versus personal devices, operating system and browser versions, shared workstations, kiosks and frontline devices, and whether users can carry a security key.
• Baseline metrics: the FIDO business metrics include first-try sign-in success, average time to sign in, password reset volume, contact centre inquiries due to lockout, sign-in abandonment, credential stuffing and phishing volumes, and SMS authentication costs. Capture them before launch so you can show change.
• Targets: set measurable goals for enrolment, the share of sign-ins made with passkeys, phishing incidents and authentication help desk tickets, as the FIDO guide recommends.
• Executive sponsor: the same guide puts sponsorship from the CISO, CIO and leadership, with budget, in phase 1. Enforcement deadlines in later phases depend on it.

Synced or device-bound: choosing per population

The choice between synced and device-bound passkeys is the main architectural decision in a rollout, and it rarely has one answer. FIDO's workforce considerations note that most organisations match credential type to user population and risk, and that a BYOD policy shapes the decision.

What the standards say, briefly:

• NIST SP 800-63B-4, Appendix B: syncable authenticators may be used up to AAL2 but not AAL3, because syncing exports the key. Access to the sync fabric must itself use AAL2-equivalent MFA. For federal enterprises the appendix expects devices that generate or sync keys to be managed by MDM or equivalent, sync fabric access through agency-managed accounts, and authenticators that support enterprise attestation.
• WebAuthn Level 3 flags: the Backup Eligibility (BE) flag is set at creation and is permanent for a credential, while Backup State (BS) shows whether it is currently backed up and can change. NIST notes that verifiers may use BE to restrict syncable authenticators and BS to restrict synced ones, but that public-facing applications should not base acceptance on BS.
• Attestation: attestation lets the relying party learn the authenticator make and model at registration. In Microsoft Entra ID, for example, Enforce attestation applies only at registration, and Microsoft notes that synced passkeys do not support attestation. If you need to know a credential is device-bound, you need attestation and an AAGUID allow list for that population.

Small organisations can usually start with synced passkeys for everyone plus two security keys per administrator. Large and regulated organisations typically run several policies side by side; Entra ID, for instance, allows up to three passkey profiles (including the default), each with its own passkey type (Device-bound or Synced), attestation and key restriction settings, targeted at groups.

Phasing the rollout

The FIDO workforce deployment guide describes six phases. The plan below follows that sequence and adds the controls that make each phase safe to run and to reverse.

1. Plan and design (FIDO phase 1): decide passkey types per population, IdP integration, policy enforcement and, above all, onboarding and recovery workflows. Write down which fallback methods remain during the transition and when each will be removed.
2. Build rollout infrastructure (phase 2): enrolment guides that branch by operating system and browser, communications and an internal FAQ page that explains biometric data stays on the device and is never sent to the organisation, and the technical configuration in the IdP. Configure registration policy first, enforcement later.
3. Pilot and iterate (phase 3): start with IT, security and a group with high sign-in pain such as frontline workers. Use the pilot to find applications without passkey support and to create time-limited conditional access exceptions for them before wider rollout. Collect feedback and fix issues between each ring.
4. Organic opt-in (phase 4): offer passkeys as an alternative to existing MFA, prompt users to create one straight after a successful traditional sign-in, and let passkey users skip further MFA prompts so the new method is visibly easier.
5. Mandatory enforcement (phase 5): announce a firm deadline well in advance with executive backing. The FIDO guide gives the example of requiring users who miss the deadline to re-authenticate every four hours until they register, and, as a final control, blocking SSO where a password is the first factor and a passkey is available.
6. Post-rollout and maintenance (phase 6): run live office hours for the first 24 to 48 hours of enforcement, watch for repeated authentication failure loops caused by unsupported legacy apps, prepare guidance for device refresh and lost devices, and build passkeys into joiner, mover and leaver workflows.

Testing and rollback: run each enforcement change in report-only or audit mode first where your IdP supports it, then enforce for one ring at a time. Keep the previous policy version and a break-glass group excluded from the new policy (with its own phishing-resistant method and monitoring) so you can revert a ring within minutes if sign-in failures spike. Rolling back should mean re-allowing a fallback for a defined group and period, never removing the passkey policy for everyone.

Gradual or rapid: for customer-facing services, FIDO describes a gradual path, where users discover passkeys in account settings (lowest cost and change risk, slower benefit), and a rapid path, where you actively promote them (higher initial cost, faster benefit). Workforce programmes usually blend both: organic opt-in followed by a deadline.

Enrolment that does not create a new weak link

The first passkey is registered with whatever method the user has today, so enrolment is only as strong as that method. Tighten it:

• Bootstrap with a short-lived, admin-issued code on day one: new joiners should not need a password at all. In Entra ID a Temporary Access Pass serves this purpose; the documented defaults are a 1 hour default lifetime, a 1 hour minimum and an 8 hour maximum, length 8, and one-time use off. For new joiners, shorten the lifetime and turn on one-time use, and issue the code only after identity proofing.
• Drive enrolment centrally: FIDO recommends enrolment through MDM or employee onboarding rather than leaving it to individuals, and immediate, centrally enforced revocation for departures and compromised devices.
• Register two authenticators: NIST's syncable appendix recommends binding multiple authenticators to support recovery. For device-bound populations, issue a primary and a backup security key and record both.
• Require strong authentication to add a passkey: adding a new authenticator should need an existing phishing-resistant method or a fresh proofing event, never just a password and SMS code.
• Notify on change: tell the user, through a channel the attacker does not control, whenever a passkey is added or removed, as NIST recommends for recovery activity.
• Restrict models where it matters: for device-bound populations, use attestation with an AAGUID allow list. Microsoft notes that removing a previously allowed AAGUID stops existing users of that key from signing in, so treat list changes as changes with their own rollout.

Customer-facing services have extra levers in WebAuthn Level 3: conditional mediation lets passkeys appear in browser autofill, getClientCapabilities reports features such as conditionalCreate, conditional create lets a passkey be offered automatically after a password sign-in, and the Signal API methods (signalUnknownCredential, signalAllAcceptedCredentials and signalCurrentUserDetails) help keep the user's credential manager in step with the server, for example after an account deletes a credential.

Recovery and the help desk

FIDO's workforce guidance says recovery needs the same rigour as primary enrolment, that emailed links and knowledge-based questions reintroduce the weaknesses passkeys remove, and that attackers increasingly target enrolment and recovery. Two incidents in the NHIMG breach database show why: in the MGM Resorts breach attackers reportedly called the IT help desk posing as an employee they had found on LinkedIn, and in the Co-op cyber attack attackers reportedly posed as an employee to get that employee's password reset. A passkey programme that keeps those reset paths open has moved the attack, not stopped it.

Write the help desk procedure down, train it, and audit a sample of recoveries every month. Privileged users should never be recovered by the same desk that serves everyone else without a second approver. See the Account Recovery and Help Desk Security Guide and the Scattered Spider Threat Actor Profile.

Legacy applications and removing passwords

Passwords survive in the applications that cannot use the IdP. Plan for them explicitly, as FIDO's workforce guidance advises for apps that cannot federate:

• Federate first: move every application that supports SAML or OpenID Connect behind the IdP, so the passkey policy covers it automatically.
• Front the rest: put web applications that cannot federate behind an identity-aware proxy, and move desktop and server access to platform sign-in with passkeys or certificates where the OS supports it.
• Time-box exceptions: every conditional access exception created in the pilot needs an owner and an expiry date. An exception list that only grows is the failure mode.
• Remove the password as a usable factor: once a user has a passkey, stop accepting password-first sign-in for SSO, then remove SMS and voice codes as fallbacks. Leaving them active means attackers simply choose the weaker path, using techniques such as T1621 Multi-Factor Authentication Request Generation or T1111 Multi-Factor Authentication Interception.
• Do not forget sessions: passkeys protect the sign-in, not the session cookie that follows it. Keep session lifetimes and token binding controls in scope, since T1539 Steal Web Session Cookie bypasses any sign-in method. See the Session Hijacking and Cookie Theft Guide.
• Keep non-human identities out of scope correctly: service accounts and API integrations cannot use passkeys. Move them to managed identities, workload federation or vaulted credentials rather than leaving them with exempted passwords. See the Service Account Security Guide.

Measuring progress

What to log and alert on: passkey registration and deletion events (especially several in a short time, or from a new location), recovery and bootstrap code issuance, changes to passkey and conditional access policies, sign-ins by users excluded from the passkey policy, and repeated failures that indicate a user stuck in a loop. Correlate help desk tickets with subsequent registrations: a new passkey registered minutes after a phone-based reset deserves a second look.

Common failure patterns

• Passkeys added, nothing removed: passwords and SMS stay valid indefinitely, so phishing and adversary-in-the-middle kits (T1557) keep working against the fallback.
• Help desk recovery unchanged: the reset script still accepts knowledge questions or caller ID, which is the path used in the MGM and Co-op incidents described above.
• One passkey type for everyone: administrators on consumer-synced passkeys outside IT control, or customers forced onto security keys, either weakens tier 0 or kills adoption.
• Attestation switched on late: enforcing attestation after broad registration does not affect passkeys already registered, so the population you meant to restrict is still mixed.
• Unowned exceptions: conditional access exclusions created for a pilot become permanent, and attackers find the excluded accounts.
• No plan for device refresh: device-bound users lose access on laptop replacement and the desk falls back to temporary passwords.

Framework mapping

In CIS Controls v8.1, passkeys support Control 6 (Access Control Management), including MFA for externally exposed applications, remote network access and administrative access. In ISO/IEC 27001:2022 Annex A they support A.5.17 Authentication information and A.8.5 Secure authentication.

Practitioner checklist

• Capture baseline sign-in, reset and phishing metrics before launch, and set enrolment and passkey sign-in targets.
• Decide passkey type, attestation and AAGUID policy per population, with device-bound keys and two authenticators for administrators.
• Redesign recovery and help desk procedures before enforcement, removing knowledge questions, emailed links and SMS as ways to add a passkey.
• Bootstrap new joiners with a short-lived, one-time code issued after identity proofing.
• Pilot with IT and security, record every unsupported app, and give each exception an owner and expiry date.
• Publish an enforcement deadline with executive sponsorship, and test each policy change in report-only mode before enforcing it ring by ring.
• Block password-first SSO for users with a passkey, then retire SMS, voice and push fallbacks.
• Alert on passkey registration bursts, recovery events and policy changes, and audit a sample of recoveries monthly.
• Build passkey registration and revocation into joiner, mover, leaver and device refresh processes.

Standards and references

• W3C: Web Authentication: An API for accessing Public Key Credentials Level 3
• NIST: SP 800-63B-4 Appendix B, Syncable Authenticators
• FIDO Alliance (Passkey Central): Workforce Passkey Deployment Guide
• FIDO Alliance (Passkey Central): Considerations for Workforce
• FIDO Alliance (Passkey Central): Plan Your Rollout
• FIDO Alliance (Passkey Central): Business Metrics
• Microsoft Learn: Enable passkeys (FIDO2) in Microsoft Entra ID
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Phishing-Resistant MFA Guide · Workforce Identity Security Guide · Passwordless and MFA Buyer's Guide