How to Audit MFA Enrollment Coverage and Close the Gaps

Every major IdP ships a report that answers this, and they do not look alike. Pull all of them if you run more than one, and keep the raw exports. You will want them again after remediation to prove what changed.

For Okta, the admin console has a report under Reports, in the Multifactor Authentication section, called MFA enrollment by user. It shows every user and their enrollments by default, can be filtered on authenticator type (for example, users with a phone enrollment), and exports to CSV Okta's MFA enrollment report article. That filter is the single most useful one in the article: it turns the report into a list of people whose only factor is telephony.

Okta also supports using its MFA to satisfy Microsoft Entra ID MFA requirements for a federated Office 365 app, and its documentation notes that if a sign-in request requires a level the user cannot meet with their single enrolled authenticator, Okta prompts them to enroll another Okta's documentation on Okta MFA for Entra ID. If you federate, pull from both sides. A user who is "enrolled" in Okta may still be unenrolled from the lens of the Microsoft tenant, and your audit should report the stricter of the two.

For Microsoft Entra ID, the enrollment picture comes from the authentication methods registration report and the per-user methods view, and the policy side comes from Conditional Access. Microsoft's risk policy documentation carries a warning worth pasting into your test plan: users must be registered for MFA before they face a situation requiring remediation, and unregistered users are blocked and require administrator intervention Microsoft's Entra ID Protection risk policy guide. In plain terms, if you switch on a risk-based policy before the population is enrolled, the first risky sign-in becomes a help desk ticket.

For Google Workspace, the equivalent evidence is the security dashboard's 2-step verification enrollment view and the user-level 2SV status in the admin console export. The questions to answer are identical: who has zero factors, who has one, and which of those accounts hold admin roles.

A worked example for sizing. Suppose the export returns 1,200 active accounts. Of those, 41 have no registered factor and 190 have exactly one factor that is telephony. Forty-one is your hard gap. Of the 190, you need to know how many sit in privileged directory roles or groups that grant remote access; a realistic result is 12. Your remediation queue is therefore 53 accounts, not 231, and the 12 go first. That triage, not the raw percentage, is what you report upward.

Reports from different IdPs use different column names, and one export may include deactivated accounts, shared mailboxes and guests. Normalize before you analyze:

Columns to keep, one row per identity:
  user_principal_name
  display_name
  account_enabled          (true/false)
  account_type             (employee, contractor, guest, service)
  privileged_role          (list of admin role names, or blank)
  remote_access_group      (true/false)
  factor_count             (integer)
  methods                  (comma-separated: passkey, fido2, totp, push, sms, voice)
  last_sign_in             (date)
  manager_email            (for the chase)

Then apply four filters in this order.

First, drop disabled accounts. They are not a coverage gap, and leaving them in inflates your gap count and makes the report look worse than reality.

Second, separate non-human identities. Service accounts and workload identities cannot answer a push prompt, and Microsoft's own guidance for phishing-resistant MFA is to identify user-based automation and migrate it to workload identities or certificate-based authentication instead of trying to give it an interactive factor Microsoft's Secure Future Initiative guidance on phishing-resistant MFA. Move those rows to a separate tab with their own remediation path. Mixing them into the human list is the most common way an audit stalls.

Third, mark dormant accounts. An account with no sign-in activity in the last 90 days should be reviewed for deletion, not chased for enrollment.

Fourth, join privileged roles and remote access. This join is the whole point of the exercise, and it is the step most homegrown audits skip.

Not all unenrolled accounts carry the same exposure. A tiered queue keeps the work moving and lets you defend the order to an auditor or an insurer.

The method column follows CISA's ordering of strength, and the tier 1 requirement follows its recommendation that high-value targets implement or plan migration to phishing-resistant MFA the CISA fact sheet. It also matches Microsoft's stated goal of protecting 100% of user accounts with securely managed, phishing-resistant MFA, rolled out in phases with Conditional Access enforcement Microsoft's SFI guidance.

One more signal to sort by: whether the account holds a role that can reset other people's credentials. An unenrolled help desk admin is a lateral movement path into every account they support, and belongs in tier 1 regardless of how rarely they sign in.

The lockout risk is real and it is self-inflicted. It comes from three mistakes: enforcement before communication, no exception process, and no recovery path for people who lose a device.

Sequence each tier as follows.

Announce, then enforce. Send one message per tier with the deadline, the self-service enrollment link, the two minutes it takes, and what happens on the deadline date. Microsoft's passkey data suggests the user experience argument is strong: its learnings from consumer accounts report that 99% of users successfully register synced passkeys, and that signing in with a synced passkey was 14 times faster than password plus traditional MFA, 3 seconds instead of 69 seconds Microsoft's passkey documentation for Entra ID. Use those numbers when someone asks why they have to bother.

Ship hardware where it matters. For tier 1, hand out two security keys per person and have both registered before enforcement. A single hardware key is a single point of failure, and the cost of a spare is trivial next to an administrator locked out during an incident.

Use time-bound onboarding credentials. Microsoft's guidance for secure onboarding uses temporary access passes: time-bound credentials issued for enrollment and recovery, with registration and deactivation handled at each stage of the user lifecycle Microsoft's SFI guidance. Enable the equivalent in your IdP so a new hire can register a factor before they have one.

Require enrollment at next sign-in rather than blocking outright. A Conditional Access grant that requires the user to register a method, combined with a grace period for the tier, produces far fewer tickets than a hard block. This is also the right shape for a temporary exception: the user is not exempt from MFA, they are required to complete enrollment before they get a session.

Document every exception. A sound exception program specifies the business justification, owner, scope, compensating controls, expiry date and review cadence, and without those attributes an exception stops being a controlled risk decision and becomes an unaudited bypass the NHI glossary entry on MFA exceptions. Put an expiry date on every row of your exception tab, defaulting to 30 days, and review the tab monthly.

Watch for the push fatigue conversation. If users push back on prompts, number matching reduces the chance a user approves an unexpected prompt, and CISA describes it as one of the best interim mitigations for organizations that cannot move to phishing-resistant methods immediately CISA's alert on number matching guidance.

A practical cadence for a 1,200-account tenant: tier 1 announced on day 1, enforced on day 8; tier 2 announced day 8, enforced day 22; tier 3 announced day 15, enforced day 45. Leave at least five business days between the announcement and the deadline for any tier above 100 people, and align tier 1 with a change freeze so an admin lockout never lands during a release.

Enrollment coverage is not a project with an end date. It decays: people replace phones, contractors roll off, and new hires arrive after the rollout. Treat the export as a recurring report.

Verification steps after each tier closes:

1. Re-run the same export and compare against the saved baseline. Report three numbers: accounts with zero factors, accounts with one factor, and tier 1 accounts below the required method strength.
2. Test the locked-out path yourself. Have someone in tier 1 attempt sign-in from a device with no registered factor and confirm the enrollment prompt appears rather than a dead end.
3. Confirm the recovery path. If a user with a password has a risky sign-in, Microsoft's recommended configuration prompts a secure password change after a successful MFA prompt, and unregistered users are blocked and need administrator intervention Microsoft's risk policy guide. Walk that flow once with a test account so the help desk knows what it looks like.
4. Check the bypass surface. Legacy protocols and stored credentials on service accounts can route around interactive MFA entirely, so an audit that only reads the enrollment column will miss them. List them explicitly and assign an owner.

For ongoing monitoring, schedule the export weekly for tier 1 and monthly for everyone else, and alert when any privileged role holder drops below two registered factors. That single alert catches the phone-replacement case before it becomes an incident.

If your team would rather spend the effort on the policy design than the reporting plumbing, a short conversation can scope which tiers to enforce first and which methods to standardize on: book a free 30-minute AI discovery call. For teams building internal tooling around this, a shared credit pool and one API key per person makes it easier to let several engineers query identity and model data without sharing credentials; that is what Quanta for Teams provides.