Rolling out passkeys in the enterprise means moving employees from passwords and phishable codes to phishing-resistant FIDO credentials, one user group and one system at a time. CISA recommends doing this in phases, starting with high-value resources and users rather than switching the whole organization at once. This article is the companion to Passkeys and FIDO2 explained, which covers the concepts, and if the wider picture is new to you, read what Zero Trust is first.

Before you start: scope and goals

CISA offers two questions that IT leaders can use to prioritize phases. First, which resources need protecting, such as email, file servers, remote access, and identity systems like Active Directory. Second, which users are high-value targets, such as system administrators or staff with access to sensitive data like legal and HR. CISA also suggests starting with services that already support FIDO, since most hosted email and SSO systems do.

Set measurable goals before you begin, such as the share of administrator accounts already on passkeys and the number of systems where password sign-in can be switched off.

Match the passkey type to each user group

The FIDO Alliance advises starting from your own legal, regulatory and security requirements, then judging whether synced, device-bound or a mix fits, and expects most enterprises to need several solutions for different use cases. These pairings follow FIDO's guidance.

  • General employees: synced passkeys are easy to use and easy to recover. FIDO sees them as a good fit for users with a small number of regularly used devices
  • Administrators and critical systems: consider device-bound passkeys on hardware security keys, and for high-assurance work FIDO advises requesting attestation at every registration
  • Shared computers: platform passkeys are a poor fit, because other users of the machine can reach the credential. Use hardware keys instead, or register a passkey on a phone and sign in cross-device
  • NIST AAL3 requirements: syncable passkeys cannot be used. A non-exportable key is required

You do not need one type for the whole organization. FIDO notes that enterprises can apply stricter rules to specific applications or user groups while allowing synced passkeys elsewhere. For high-privilege accounts, see privileged access management.

The rollout in six steps

  • Step 1, survey your systems: list the apps, SSO systems and services that support passkeys or FIDO2. If SSO supports them, federated apps benefit at the same time. For systems with no MFA support at all, CISA advises planning an upgrade or migration and escalating the risk to senior leadership
  • Step 2, group users and devices: note whether devices are personal or company-provided, single-user or shared, and whether USB, Bluetooth or NFC is limited, then pair an authenticator type with each group
  • Step 3, design enrollment and recovery: decide before the pilot how users will register and how accounts will be recovered when a device is lost. Details are in the next section
  • Step 4, pilot with a varied group: mix user types and levels across the organization, and test registration, sign-in and recovery with real users. CISA gives help desk staff and system administrators as examples of suitable first groups
  • Step 5, expand in waves: start with high-value groups, widen using lessons from the previous wave, and track metrics before and after each change
  • Step 6, close the phishable shortcuts: once a group is ready, switch off or restrict passwords and OTP for that group. For systems still on older MFA, CISA recommends extra controls such as number matching for push notifications, an interim measure that is weaker than phishing-resistant MFA
INFOGRAPHIC
The six steps and what done looks like
1
Survey systems
done when you know which apps support it
2
Group and choose types
done when each group has a fitting type
3
Design enrollment and recovery
done when the procedure is written down
4
Pilot
done when enroll and recover tests pass
5
Expand in waves
done when high-value groups are covered
6
Close shortcuts
done when passwords stop working for the group

Legacy systems should not stall the program. CISA notes that MFA for many business applications can be added through integration with the enterprise identity and SSO system, and that technology exists to connect a wide variety of legacy systems to modern MFA and SSO.

Enrollment and recovery

Enrollment and recovery are common targets for attackers. FIDO states that recovery should never rely on a weaker factor than the credential being recovered, and should follow a risk-based approach. FIDO's papers describe three ways to enroll.

  • Self-service with existing credentials: the user creates a new passkey using the old password. This is the most convenient, but exposes the process to phishing of those original credentials
  • Supervised: IT or the help desk performs the registration, which lowers that risk
  • Pre-provisioned: the credential is prepared in advance. High effort and high assurance, and it needs a secure way to deliver it to the user, including a PIN for remote users
INFOGRAPHIC
Enrollment methods: more oversight, fewer gaps
Self-service with old password
easiest, but old password can be phished
Supervised by help desk
a person verifies identity, more effort
Pre-provisioned
issued in advance, high assurance, needs secure delivery
Larger enrollment gapSmaller enrollment gap

Recovery must be designed around the passkey type and must cover the employee lifecycle.

  • Device-bound: register more than one per person, such as a backup security key, because the key cannot be backed up or recovered on its own. Without a backup you need an organization-defined recovery path. FIDO suggests issuing two hardware keys per user
  • Synced: users can restore through the passkey provider, but the organization still needs to document how a new device is bootstrapped and use a risk-averse process, including identity proofing, for full provider-account recovery
  • Lost device or departing employee: remove the related passkeys immediately, and on re-registration make sure passkeys no longer tied to the user cannot be used. Let users name credentials so a specific one can be revoked
INFOGRAPHIC
When an employee loses a device
01
Report the loss
its passkeys are at risk
02
Verify identity
no weaker than passkey
03
Re-enroll
issue a new passkey
04
Revoke the old
remove old passkeys now

Measure and maintain after launch

  • Time to enroll the first device: shows where the registration process gets stuck
  • Authentication success rate and changes in usage patterns after migration
  • Passkeys per user: FIDO expects roughly one per device, so five or six may warrant a look
  • Security events at onboarding: where users registered, which identity proofing was used, and unusual times or locations
  • Account separation: use separate passkeys for administrative, service and break-glass accounts
  • Compatibility after upgrades: confirm every sign-in method still works after browser, operating system or app updates

Common mistakes

  • Switching on the whole organization at once: CISA points out that training, enrolling and supporting every user at the same time may be impractical. Use phases
  • Leaving passwords as a permanent recovery path: FIDO notes that depending on an active password reduces the benefit during transition. Set a clear shutoff date per group
  • No backup authenticator: losing a single hardware key means a recovery event every time
  • Loose identity checks at the help desk: if support will reset for anyone who claims an identity, attackers use that door instead of phishing. Write down a verification procedure
  • Using platform passkeys on shared computers: other people using that machine can reach the credential
  • Forgetting non-human accounts: passkeys are designed for users who can unlock a device themselves, while service accounts need other approaches. See non-human identity and service accounts
  • Ignoring user resistance: CISA advises security leaders to present the risks to top leadership for approval, since leadership is best placed to manage culture and communication
INFOGRAPHIC
Risky transition versus controlled transition

Risky transition

  • Everyone at onceoverwhelms support
  • Password stays as backupattackers still phish that path
  • One authenticator eachevery loss is a recovery

Controlled transition

  • Wavesstart with admins and help desk
  • Shutoff date per groupretire passwords group by group
  • Backup authenticatora spare security key

Start today

  • List your core systems and check whether SSO or your identity platform supports FIDO2
  • Pick a small pilot group that includes the IT team, help desk and general users
  • Give administrators and executives two hardware keys each, one for daily use and one kept as a backup
  • Write the account recovery procedure down and have IT leadership approve it before the pilot starts
  • If you still use push notifications, turn on number matching as an interim measure during the transition

To see where your authentication and identity management stand against good practice, try the self-assessment.

References and further reading