You've spent years getting your team to adopt a password manager. Multi-Factor Cryptographic Devices protect privileged accounts. Your security awareness training finally mentions phishing. Now you're hearing that passkeys will make all of this obsolete.
Not quite. But the shift from password vaults to FIDO2-based authentication requires a deliberate transition plan. This checklist helps you evaluate whether your environment is ready to move beyond password managers, and what "ready" actually means in practice.
What This Checklist Covers
This is a readiness assessment for organizations considering a transition from password manager-dependent authentication to FIDO2 passkeys. You'll evaluate your current authentication architecture, identify gaps that would block adoption, and establish clear done/not-done criteria for each prerequisite.
This isn't about whether passkeys are "better", they resist phishing attacks that credential vaults can't stop. The question is whether your infrastructure, user base, and recovery processes can support them.
Prerequisites
Before you start the checklist, confirm:
- You have an inventory of applications currently authenticated through your password manager.
- You know which systems support FIDO2 (WebAuthn on the client side, FIDO2 Server on the backend).
- You've documented your current account recovery process.
- You have metrics on authentication friction points (help desk tickets, failed logins, lockouts).
If you're missing any of these, gather them first. You can't plan a migration without knowing what you're migrating from.
Readiness Checklist
1. Application Support Audit
Task: Document which applications in your environment support FIDO2 authentication.
How to verify: For each critical application, check vendor documentation for WebAuthn API support or contact your account team directly. Don't assume, SaaS providers often support passkeys in consumer products before adding them to enterprise SKUs.
Done looks like: A spreadsheet listing every application, its FIDO2 support status (supported/planned/unsupported), and the vendor contact if support is planned. Applications marked "unsupported" become your constraint list.
2. Identity Provider Compatibility
Task: Confirm your Identity Provider (IdP) supports FIDO2 as a primary authentication factor, not just as a second factor after password entry.
How to verify: Log into your IdP admin console and look for passwordless authentication options. Test the flow yourself, some vendors claim support but require passwords as a fallback, which defeats the purpose.
Done looks like: You can authenticate to your IdP using only a passkey, with no password prompt. Your session policies recognize this as Phishing-Resistant Authentication for conditional access rules.
3. Device Management Integration
Task: Determine how passkeys will interact with your Mobile Device Management (MDM) or endpoint management platform.
How to verify: Test passkey enrollment on a managed device. Can you enforce passkey creation? Can you remotely revoke a passkey if a device is lost? Does your MDM support platform authenticators (Windows Hello, Touch ID, Android biometrics)?
Done looks like: You have a documented process for passkey lifecycle management that integrates with device provisioning and deprovisioning workflows. Lost devices don't strand users.
4. Recovery Process Design
Task: Build an account recovery mechanism that doesn't rely on passwords or security questions.
How to verify: Map out what happens when a user loses access to all registered passkeys. Common approaches: backup passkeys stored separately, recovery codes generated at enrollment, or help desk verification with alternative authentication.
Done looks like: A written recovery procedure that your help desk has tested in a staging environment. Recovery doesn't require creating a temporary password.
5. Privileged Access Transition Plan
Task: Document how privileged accounts (admin consoles, infrastructure access, break-glass accounts) will authenticate without password managers.
How to verify: Identify every privileged account currently stored in your password manager. For each one, determine if the target system supports FIDO2. For systems that don't, document the interim solution (could be Multi-Factor Cryptographic Devices for SSH, certificate-based auth, or Just-in-Time Elevation).
Done looks like: No privileged account relies solely on a password manager credential. Every admin access path has a defined authentication method that doesn't degrade security during the transition.
6. Shared Account Remediation
Task: Eliminate or redesign workflows that depend on shared passwords.
How to verify: Search your password manager for credentials marked as shared or accessed by multiple users. For each one, determine if you can replace it with individual accounts, service accounts with proper access controls, or delegated authorization flows.
Done looks like: A list of shared credentials with a remediation plan for each. "Shared admin account for vendor portal" becomes "individual SSO accounts with Role-Based Access Control."
7. Compliance Mapping
Task: Verify that passkey-based authentication satisfies your compliance requirements for authentication strength.
How to verify: Review your audit frameworks (SOC 2, ISO 27001, PCI DSS, etc.) and map FIDO2 to the relevant controls. For PCI DSS, confirm that FIDO2 satisfies multi-factor requirements. For frameworks requiring "something you know," document that the authenticator's PIN or biometric satisfies this.
Done looks like: A compliance matrix showing which controls are met by FIDO2 authentication, with auditor-friendly language explaining how passkeys satisfy each requirement.
8. User Enrollment Capacity
Task: Estimate how long full enrollment will take given your support capacity.
How to verify: Run a pilot with 50-100 users. Track enrollment time, support tickets generated, and completion rate. Multiply by your total user count to project full rollout duration.
Done looks like: A realistic timeline that accounts for support load, with defined enrollment phases (IT first, then power users, then general population). You know how many users you can enroll per week without overwhelming your help desk.
9. Legacy System Inventory
Task: Identify systems that will never support FIDO2 and require a permanent alternative.
How to verify: Cross-reference your application inventory (item #1) with vendor roadmaps. Systems with no planned support and no active development are your legacy constraints.
Done looks like: A documented list of legacy systems with their authentication strategy (keep password manager for these specific apps, use a gateway/proxy with FIDO2 at the edge, or plan decommissioning timeline).
10. Monitoring and Metrics
Task: Establish baseline metrics before transition and define success criteria.
How to verify: Capture current stats: password reset tickets per month, average time to authenticate, phishing simulation click rates, account lockout frequency. Define target improvements (e.g., 80% reduction in password resets, zero successful phishing simulations).
Done looks like: A dashboard tracking authentication metrics with clear targets. You'll know if the transition is succeeding or creating new friction.
Common Mistakes
Assuming universal support: Not every application supports FIDO2 yet. Enterprises often discover critical line-of-business apps that will block full migration.
Ignoring recovery: Users will lose devices. If your only recovery path is "contact IT to reset your password," you've just reintroduced passwords through the back door.
Treating this as a tech swap: Moving to passkeys requires process changes in onboarding, offboarding, and support. The technology is the easy part.
Skipping the pilot: Enrollment issues you don't discover with 50 users become crises with 5,000.
Next Steps
If you've completed this checklist and identified gaps, prioritize them by risk and user impact. Applications with high phishing risk and FIDO2 support should move first. Legacy systems can maintain password manager access during a longer transition.
You don't need to retire your password manager tomorrow. But you do need to know which parts of your environment can move beyond it, and build the processes that make that transition viable.
