You've checked the box. MFA is enabled across your organization, Compliance Reporting show green, and your cyber insurance renewal went through smoothly. But here's the uncomfortable question: if an attacker phished your finance director tomorrow, would your current MFA method actually stop them?
This checklist guides you through what deploying phishing-resistant MFA truly requires. It's not just about having MFA "on." It's about ensuring your method can withstand attackers who exploit push fatigue and OTP interception.
What This Checklist Covers
This is a technical readiness assessment for organizations transitioning from legacy MFA methods (push notifications, SMS codes, email-based OTPs) to phishing-resistant authentication using FIDO2 or passkeys. You'll inventory your current setup, identify exposure gaps, and create a phased rollout plan starting with your highest-risk accounts.
If you're still using push-based MFA for privileged accounts or have SMS fallback available for credential resets, you need this audit.
Prerequisites
Before you start, ensure you have:
- Administrative access to your identity provider and any federated authentication systems
- Current inventory of all applications requiring authentication, including legacy on-premises systems
- Access to your user directory with role and group assignments
- Budget authority or a realistic cost model for hardware security keys at scale
- Stakeholder alignment from IT support, as this will generate tickets
You don't need executive buy-in to start the audit, but you will need it before announcing the rollout.
Checklist Items
1. Inventory every MFA method currently in production.
Don't rely on what your dashboard says is "enabled." Log into your identity provider and document every authentication method available to every user tier: administrators, standard users, service accounts, break-glass accounts. Include fallback options.
Good looks like: A spreadsheet showing user role, primary MFA method, fallback methods, and application coverage. You know exactly how many users can still authenticate via SMS if they claim their phone is dead.
2. Identify which accounts can reset credentials or modify group membership.
These are your Tier 0 targets. Anyone with the ability to reset another user's password, approve access requests, or change security group assignments sits at the top of your risk stack. Push fatigue attacks work because help desk staff and IT admins approve requests all day; one more approval doesn't look suspicious until it's too late.
Good looks like: A named list of accounts with privileged access to your identity provider, Active Directory Domain Controllers, or PAM systems. You know who they are, and you know they're your first migration cohort.
3. Verify whether your identity provider supports WebAuthn and FIDO2.
Not all SaaS platforms and on-premises systems were built with origin-binding in mind. Check your vendor documentation and test a passkey registration flow in a sandbox environment. If your primary IdP supports it but a critical legacy application doesn't, document that gap now.
Good looks like: Confirmation that your identity provider supports FIDO2 natively, and a list of exceptions where you'll need compensating controls or a migration timeline.
4. Disable SMS-based OTP as a primary authentication method.
SMS codes can be intercepted via SIM swapping or real-time phishing proxies. If SMS is still available as a primary option for any user population, it needs a sunset date. If it's a fallback for account recovery, lock it behind conditional access policies that require device compliance or network location checks.
Good looks like: SMS removed from standard authentication flows, with a documented exception process for account recovery that includes manual verification and audit logging.
5. Test whether push notification MFA allows unlimited retry attempts.
Send yourself 20 approval prompts in a row and see what happens. If your system doesn't rate-limit or require additional verification after repeated denials, you're vulnerable to push fatigue. Attackers don't need to be clever; they just need to be persistent.
Good looks like: Rate limiting after three failed attempts, or a policy requiring re-authentication via a different method after repeated denials. Your users can't approve a login by accident at 2 a.m. because they're tired of the notifications.
6. Map which applications can't support phishing-resistant authentication yet.
Legacy VPNs, older database management tools, and some on-premises applications weren't designed for WebAuthn. Document these gaps, but don't let them block progress. Apply conditional access policies in the meantime: require managed devices, restrict by IP range, or add session time limits.
Good looks like: A risk-ranked list of legacy systems with compensating controls in place and a realistic timeline for when each will support FIDO2 or be retired.
7. Calculate the Multi-Factor Cryptographic Device cost and support burden.
Multiply the cost of a FIDO2 security key by your target user population. Add the cost of replacements for lost or damaged keys. Factor in the support tickets this will generate, users will lose keys, forget them at home, or plug them in wrong. If you're planning a 5,000-user rollout, budget for at least 10% replacement inventory in year one.
Good looks like: A cost model that includes hardware, shipping, spares, and support labor. You've accounted for the reality that physical devices create physical problems.
8. Define your phased rollout cohorts.
Start with privileged accounts: identity administrators, Domain Controller access, anyone who can approve access requests. Move to finance, engineering, and any team with access to sensitive systems. Standard users come last, and only after you've worked through the support issues with a smaller, more technical population.
Good looks like: A rollout schedule with named cohorts, start dates, and success criteria. You're not flipping a switch for everyone at once.
9. Remove OTP fallback options from administrator accounts.
If an admin account can fall back to an email-based OTP or SMS code, an attacker can too. Once you've migrated privileged accounts to FIDO2, disable every legacy method. No exceptions, no "just in case" fallbacks.
Good looks like: Administrator accounts locked to phishing-resistant methods only. Your break-glass accounts use hardware keys stored in a physical safe, not OTP codes sent to an email inbox.
10. Audit your conditional access policies for gaps.
Phishing-resistant MFA only works if an attacker can't bypass it by triggering a different authentication flow. Check whether legacy authentication protocols are still enabled, whether app-specific passwords are allowed, and whether any service accounts authenticate without MFA at all.
Good looks like: Legacy authentication protocols disabled unless explicitly required and documented. App-specific passwords removed. Service accounts moved to certificate-based authentication or managed identities.
Common Mistakes
Treating all MFA as equivalent. A push notification and a FIDO2 key both satisfy the "MFA enabled" checkbox on a compliance report, but they don't provide the same protection. Attackers already know how to defeat push and OTP. Origin-binding is what makes phishing-resistant methods actually resistant.
Leaving SMS as a permanent fallback. SMS-based OTP is the weakest link in your authentication chain. If it's available as a fallback indefinitely, that's the path an attacker will take. Treat it as a temporary bridge, not a safety net.
Rolling out hardware keys without a support plan. Physical devices get lost, forgotten, and broken. If your help desk isn't prepared for the support volume this creates, your rollout will stall when users can't log in and can't get a replacement key quickly.
Ignoring legacy application gaps. Not every system will support FIDO2 on day one. Pretending those gaps don't exist won't make them go away. Document them, apply compensating controls, and set real deadlines for when the exceptions close.
Next Steps
Run this audit, then prioritize the gaps by risk. Accounts with credential reset privileges and access to your identity provider should move to phishing-resistant methods first. Legacy applications that can't support FIDO2 need compensating controls and a migration plan, not a permanent exception.
Attackers have already adapted to the MFA most organizations deployed years ago. The question isn't whether you'll migrate to phishing-resistant authentication. It's whether you'll do it before or after the next credential-based breach.
