Enterprise passkeys: choose who controls the credential lifecycle

A warehouse employee needs to sign into a shared terminal at the start of a shift. A privileged administrator needs to recover access after a managed laptop fails. In this hypothetical organisation, both are candidates for passkeys, but a single convenient demonstration cannot settle both deployment decisions.

For the identity lead, the choice is about custody and continuity: where credentials can exist, who controls their lifecycle and how the employee returns to work after a loss. The operational stakes include support capacity, access to critical applications and the temptation to restore a weaker fallback when the approved method fails.

Separate phishing resistance from custody

A synced passkey can be made available on multiple devices through a passkey provider’s synchronisation service. A device-bound passkey remains with a particular authenticator, which might be a security key or a supported device. Device-bound does not necessarily mean bound to the computer running the application: a portable security key can be used with different compatible computers.

The distinction changes the recovery problem. Synchronisation can make a credential available after a device replacement, but introduces the provider account and its recovery process into the trust boundary. With a device-bound credential, plan another approved authenticator or a controlled way to register a replacement. A broken device should not force an improvised identity decision at the help desk.

NIST SP 800-63B-4 allows syncable authenticators in suitable deployments up to Authentication Assurance Level 2. It excludes them from AAL3, which requires a non-exportable private key and additional protections. NIST also addresses the security of the sync service and its recovery path. This is a framework for assessing the complete deployment, not a certification supplied by the word “passkey”.

Specify the assurance needed for each account class before choosing the credential model. If a privileged workflow requires properties a proposed provider cannot demonstrate, convenience elsewhere does not close that gap. For ordinary workforce access, a well-controlled synced model may be a reasonable choice if the organisation can govern the accounts, devices and recovery on which it relies.

The policy needs to match the credential already registered

Microsoft Entra ID’s passkey profiles support group-based choices for passkey type, attestation and authenticator restrictions. The documented options include synced passkeys and device-bound credentials on security keys or in Microsoft Authenticator. This gives an identity team a way to configure different requirements for different groups.

One detail deserves attention before tightening a policy. Microsoft states that attestation is enforced at registration: enabling it later does not block sign-in with a passkey registered previously without attestation. Without attestation enforcement, Microsoft also says it cannot guarantee properties such as whether a credential is synced or device-bound. Authenticator restrictions have different effects on registration and sign-in.

The implication is practical: inventory existing registrations and test the intended transition. Do not assume that changing a setting has changed the evidence behind every credential already in use. Establish how nonconforming registrations will be replaced and how users will retain approved access while that happens.

Walk the two employees through a working day

For the warehouse worker, examine the terminal, browser, available ports and shift handover. If a personal security key is proposed, can the employee use it with the actual terminal and complete user verification? Can a replacement be issued during the working shift? If a phone-based method is proposed, is that phone available and permitted where the work happens?

Keep the employee’s identity distinct from the shared workstation. Test sign-out and the next user’s sign-in, including what happens to the application session. Successful authentication does not by itself establish that a previous session has been cleared.

For the administrator, test the management applications and native clients used during an incident, not just the web portal. Include the failure of the primary device and the recovery of the identity service itself. A spare authenticator is useful only if it remains available, registered and permitted when needed.

Microsoft’s Entra compatibility matrix distinguishes browser support, native-app support and authentication-broker requirements. For example, its Android table lists Chrome and Edge support but not Firefox; its Linux notes exclude Microsoft Authenticator passkey sign-in through Firefox. A supported operating system alone is therefore too broad an acceptance criterion.

Use the precise combination of authenticator, device, browser or native application, identity provider and policy in the pilot. Test registration separately from everyday authentication. Keep unsupported journeys visible, with a planned resolution and an approved interim route.

Make loss and departure ordinary operating cases

The support process needs to distinguish loss of one device from loss of control over the provider account. Decide how the team verifies the employee, revokes or removes the affected credential, registers a replacement and confirms access to the required applications. Establish what evidence the support agent needs before authorising that change.

Offboarding deserves the same attention. Test the identity account’s access termination and any separate application sessions or local credentials that the deployment relies on. Avoid treating deletion from one device as proof that every route to the business service has ended.

Choose a model for each workforce journey that the organisation can support throughout this lifecycle. Then use the phishing-resistant MFA rollout and recovery guide to test enrolment, enforcement and the lost-device route together. The deployment is ready to expand when the difficult day works as convincingly as the first sign-in.