MFA Method Assessment Script

Your organization's MFA rollout is complete, and every compliance report shows 100% coverage. But if an auditor asked you to produce a list of which accounts use push notifications versus hardware keys, could you generate it without logging into each system manually?

Most organizations can't answer that question without days of work. This is why phishing-resistant MFA migrations often stall. You can't prioritize what you can't measure, and you can't measure what you haven't inventoried.

This script gives you a starting point: a method-level MFA audit that maps each authentication mechanism to the accounts it protects. Use it to identify where your highest-risk accounts still rely on push notifications or OTPs, and build a migration roadmap that targets those gaps first.

What this script does

The template below structures an MFA method inventory across your identity providers, VPNs, and privileged access systems. It's not a technical scanner; it's a data collection framework you'll populate through API queries, admin console exports, and conditional access policy reviews. The output tells you three things:

1. Which MFA methods are configured for each system
2. Which user populations are assigned to each method
3. Where your highest-risk accounts (administrators, finance, help desk) still use phishable methods

You'll use this inventory to answer the question every risk officer should be asking: are the accounts attackers target first protected by methods attackers can't defeat?

Prerequisites

Before you start collecting data, confirm you have:

• Admin console access to your primary identity provider (Okta, Azure AD, Google Workspace, or equivalent)
• Read access to conditional access policies or equivalent authentication policy configurations
• A list of privileged account holders including domain admins, identity admins, and anyone with password reset capabilities
• Access to VPN and remote access logs to verify which MFA methods protect network entry points
• Spreadsheet software or a lightweight database to track findings

You don't need scripting knowledge to use this template, but if you have API access to your identity provider, you can automate the data pull instead of exporting manually.

The template

Copy this structure into a spreadsheet with one row per system-method combination:

System Name | System Type | MFA Method | User Count | User Group | Risk Tier | Fallback Method | Phishing-Resistant? | Migration Priority | Notes

Column definitions:

• System Name: The application or service (e.g., "Azure AD", "VPN Gateway", "AWS Console")
• System Type: Identity Provider / VPN / Privileged Access / SaaS Application / On-Premises System
• MFA Method: Push Notification / SMS OTP / Email OTP / TOTP App / FIDO2 Hardware Key / Passkey / Certificate-Based
• User Count: Number of accounts using this method on this system
• User Group: IT Admins / Finance / Engineering / General Workforce / Contractors
• Risk Tier: Critical / High / Medium / Low (based on what the account can access)
• Fallback Method: What happens if the primary method fails? (e.g., "SMS OTP", "Help desk reset", "None")
• Phishing-Resistant?: Yes / No / Partial (mark "Partial" if a phishing-resistant method has a phishable fallback enabled)
• Migration Priority: 1-5, where 1 is "migrate immediately" and 5 is "acceptable for now"
• Notes: Constraints, dependencies, or reasons a migration might be blocked

Example rows:

Azure AD | Identity Provider | Push Notification | 450 | General Workforce | Medium | SMS OTP | No | 3 | Plan to migrate after admin accounts
Azure AD | Identity Provider | FIDO2 Hardware Key | 12 | IT Admins | Critical | None | Yes | N/A | Migrated Q2
VPN Gateway | VPN | SMS OTP | 85 | Engineering | High | Help desk reset | No | 2 | Hardware keys ordered, rollout in 6 weeks
AWS Console | Privileged Access | TOTP App | 8 | IT Admins | Critical | SMS OTP | No | 1 | Fallback method undermines primary control

How to customize it

Start with your identity provider, because it's the control plane for everything downstream. If you're using Azure AD, export your authentication methods report from the Azure portal under "Protection > Authentication methods > Activity." If you're using Okta, pull the MFA enrollment report from Reports > Reports. Google Workspace admins can find similar data under Security > Authentication.

For each system, focus on three questions:

1. What's protecting administrator accounts?

Mark any admin account still using push notifications or OTPs as Migration Priority 1. These are the accounts attackers target first because compromising one unlocks lateral movement across your environment. The Uber breach happened because an attacker convinced a contractor to approve a push notification after bombarding them with requests. If your domain admins or identity admins are using the same method, you're one push fatigue attack away from the same outcome.

2. Where do fallback methods create a backdoor?

A hardware key is only phishing-resistant if there's no SMS fallback sitting behind it. Check your conditional access policies for exception rules that let users authenticate with a weaker method "just in case." Those exceptions are what attackers look for, because they're easier to exploit than the primary control. If you find a fallback OTP option enabled for administrator accounts, document it and eliminate it.

3. Which legacy systems can't support modern methods yet?

You'll find on-premises applications that don't support WebAuthn and SaaS platforms that haven't updated their authentication integrations. Don't ignore these; mark them clearly, assign a sunset date for the exception, and put a compensating control in place. That might mean restricting access to those systems from managed devices only, or requiring an additional approval step before access is granted.

Add a "Risk Tier" column based on what each account can access, not just job title. A finance analyst who can initiate wire transfers sits in a higher risk tier than an engineer who can't touch production systems. A help desk agent with password reset privileges is a critical account even if their org chart position doesn't suggest it.

Validation steps

Once you've populated the inventory, run these checks:

Verify your critical accounts are actually protected. Filter for Risk Tier = Critical and Phishing-Resistant? = No. That's your immediate action list. If you find more than a handful of rows here, your migration plan needs to start this quarter, not next year.

Check for inconsistent policies across systems. If your identity provider enforces hardware keys for admins but your VPN still accepts push notifications, an attacker only needs to compromise the weaker link. Look for mismatches between System Type = Identity Provider and System Type = VPN or Privileged Access.

Count how many users have fallback methods enabled. If more than 10% of your phishing-resistant deployments still have a phishable fallback, you haven't actually closed the gap. Attackers know to look for the fallback because it's easier than attacking the primary method.

Audit your Migration Priority 1 and 2 items. If you've marked accounts as high-priority but they've been sitting in that state for more than 90 days, something's blocking progress. Document the constraint, is it budget, vendor support, user resistance?, and escalate it. Phishing kits that intercept OTPs using reverse-proxy tools are already in active use. Waiting for a bigger incident to justify the budget isn't a strategy.

This inventory isn't a one-time exercise. Update it quarterly, especially after onboarding new systems or user groups. The goal isn't perfection on day one. It's knowing exactly where your gaps are, so you can close them in order of risk instead of hoping the next breach happens to someone else.