Overview
Passkeys replace passwords and phishable MFA with cryptographic key pairs, reducing credential phishing while making sign-in easier. But the passkey experience most people know from consumer accounts was not designed around workforce governance. Enterprise deployments also need policy for credential storage, recovery, device trust, offboarding, audit evidence, and regulated roles.
This guide covers what security architects and IAM leaders should evaluate when selecting and operating passkeys for the workforce.
Consumer vs. workforce passkeys: understanding the gap
- Synchronization outside enterprise control. Consumer passkeys may synchronize through a user's personal provider account. The relying party can revoke a registered credential, but IT may have limited visibility into the provider's synchronization, recovery, and device inventory.
- Limited device provenance. Standard synced passkeys expose useful properties such as backup eligibility and state, but they do not usually provide verifiable, device-specific proof that a credential was created on a managed corporate endpoint. See Trusted Authenticator Lineage for the signals an enterprise can evaluate.
- Different administrative boundaries. A workforce deployment needs server-side credential inventory and revocation plus clear policy for provider accounts, recovery, replacement, and offboarding. Administrators should not assume that managing the relying-party record also manages every copy held by a synchronization provider.
What to evaluate
- Device-bound vs. enterprise-controlled synced passkeys. Privileged users, administrators, and regulated roles may require device-bound passkeys whose private keys cannot be exported or synchronized. Other users may benefit from enterprise-controlled synchronization. Policy should determine which model applies to each risk tier.
- Attestation and lineage. When attestation is available and appropriate, validate the authenticator provenance and security properties the attestation actually conveys. Treat current device compliance as a separate input from MDM, endpoint security, platform attestation, or another posture source.
- Lifecycle management. Evaluate first enrollment, additional-device enrollment, lost-device recovery, credential replacement, server-side revocation, and offboarding. Recovery and bootstrap paths should not quietly fall back to phishable SMS, email links, or temporary passwords.
- Cross-platform interoperability. Test the actual workforce mix across Windows, macOS, iOS, Android, roaming security keys, shared devices, virtual desktops, and exception workflows. Avoid assuming that support for the WebAuthn API produces an identical operational experience everywhere.
- Open-standard compliance. Confirm that authentication uses FIDO2 and WebAuthn and that federation and provisioning use appropriate standards such as OIDC, SAML, and SCIM. Standards reduce lock-in, but each identity provider and application still requires capability validation and configuration.
Questions to ask vendors
- Can policy prevent registration or use of passkeys synchronized through personal provider accounts?
- What attestation and backup-state information is collected, validated, retained, and exposed to policy?
- Can we require device-bound passkeys for administrators while allowing enterprise-controlled synchronization for other teams?
- What happens when a passkey fails, and is every bootstrap and recovery path also phishing-resistant?
- What audit records are available for registration, authentication, replacement, revocation, backup-state changes, and recovery?
How to use this resource
Use these considerations to align security, IT, and procurement stakeholders, document current-state gaps against your existing MFA deployment, and define measurable acceptance criteria before a rollout.