Deploying FIDO2 and passkeys across your enterprise requires more than vendor promises and pilot programs. You need a clear path from initial assessment to production rollout, considering authentication flows, legacy systems, and user populations that won't all migrate on day one.
This checklist guides you through what you need to verify before, during, and after FIDO2 deployment. It's designed for security teams managing authentication infrastructure in environments where "rip and replace" isn't feasible, and where phishing-resistant authentication needs to coexist with existing identity systems.
Prerequisites
Before you start, confirm these foundational elements:
Identity provider supports FIDO2 WebAuthn. Your IdP must implement the WebAuthn API for credential registration and authentication. Look for documented WebAuthn endpoints, published conformance test results, and clear guidance on supported authenticator types.
Browser and OS compatibility baseline documented. You need a matrix showing which browser versions, operating systems, and mobile platforms support WebAuthn in your environment. Ensure compatibility with Windows 10+, macOS 11+, iOS 14+, Android 9+, and current versions of Chrome, Edge, Safari, and Firefox.
Fallback authentication method defined. FIDO2 won't work for every scenario initially. Document a fallback path, likely TOTP or push notification, with clear criteria for its use and monitoring to track fallback usage rates.
Core Deployment Checklist
1. Authenticator attestation policy configured
□ Done when: Your FIDO2 server validates authenticator attestation statements and enforces your organization's authenticator trust policy.
Decide whether to accept any FIDO2-certified authenticator or restrict to specific models, such as those requiring FIPS 140-2 Level 2 certification for privileged access. Enable attestation validation, maintain an approved authenticator list, and reject blocked authenticators at registration with clear error messages.
2. User verification requirements enforced
□ Done when: Your authentication policy specifies when user verification (PIN, biometric, or other local authentication) is required versus when user presence (simple tap) is sufficient.
For high-value transactions or privileged access, require verification. Ensure user verification for admin consoles and sensitive data access, while user presence is acceptable for standard application login.
3. Credential backup and sync policy set
□ Done when: Decide whether to allow passkey sync across devices via platform providers (Apple iCloud Keychain, Google Password Manager) or restrict to device-bound credentials only.
Document your policy on syncable vs. device-bound credentials by user role, enforce the policy at registration, and communicate to users which credential types are permitted and why.
4. Registration ceremony secured
□ Done when: The credential registration flow requires the user to authenticate with an existing strong factor before binding a new FIDO2 credential.
Ensure registration requires a current session with 2FA, registration links expire within 15 minutes, and registration events generate audit logs with device and location context.
5. Relying party ID scoped correctly
□ Done when: Your WebAuthn relying party identifier matches your authentication domain, and all subdomains that need to share credentials are explicitly allowed.
Set the relying party ID to your root authentication domain, include only legitimate authentication endpoints in the allowed origins list, and block cross-origin credential use by browser policy.
6. Credential lifecycle management implemented
□ Done when: You can list all FIDO2 credentials per user, users can self-service revoke lost credentials, and admins can force revocation during offboarding.
Provide a self-service portal showing registered credentials with last-used timestamps, offer one-click revocation with a re-registration workflow, and automate credential purge on account termination.
7. Legacy system authentication paths documented
□ Done when: Map which systems can't support FIDO2 and define how users authenticate to those systems during and after migration.
Inventory systems by authentication protocol, document bridge solutions like SSH certificate authority or legacy app wrapper, and set a timeline for sunsetting non-FIDO2 paths.
8. Monitoring and alerting configured
□ Done when: Track FIDO2 adoption rate, fallback authentication usage, failed registration attempts, and anomalous credential usage patterns.
Use a dashboard to show daily active FIDO2 users vs. total population, set alerts for spikes in fallback auth usage, and integrate with your SIEM for correlation.
Common Mistakes
Treating FIDO2 as binary. Successful deployments phase by user population and application risk tier, starting with high-value targets.
Ignoring the recovery path. Secure recovery processes are essential. Consider recovery codes, admin-assisted verification, or identity proofing workflows instead of email-based password resets.
Skipping user communication. Educate users about passkeys, their security benefits, and what to do if their authenticator isn't available. Plan for training, FAQs, and helpdesk preparation.
Assuming platform passkeys are always better. Syncable passkeys offer convenience but may not suit privileged access and regulated environments. Device-bound security keys might be the right choice despite lower user satisfaction scores.
Next Steps
After completing this checklist, you should have FIDO2 authentication operational with clear policies, monitoring, and fallback paths. Now focus on:
- Measuring adoption velocity and identifying friction points
- Sunsetting legacy authentication methods on a published timeline
- Extending FIDO2 to SSH, VPN, and other non-web authentication surfaces
- Reviewing authenticator attestation logs to verify only approved hardware is in use
The goal isn't 100% FIDO2 coverage immediately. Aim for phishing-resistant authentication for your highest-risk access paths with a clear plan to expand coverage over time.
