MFA Coverage Measurement: Calculate Real Coverage Across Users, Admins and Exceptions

Most MFA coverage figures count who has registered a method, not who is actually forced to use one, so a dashboard showing 98% can sit on top of excluded accounts, legacy protocols and service accounts that sign in with a password alone. This guide gives a repeatable method for calculating MFA coverage that holds up in an audit: how to define the denominator, the five coverage levels to measure, how to treat exceptions, emergency access accounts and non-human identities, and which data sources supply each number. Examples use Amazon Web Services IAM and Microsoft Entra ID, listed alphabetically; the method applies to any identity provider. It is written for identity engineers, security architects and the people who report MFA metrics to auditors and boards. For industry adoption figures, see the MFA Adoption Statistics page; this guide is about measuring your own estate.

Key takeaways

• Registration is not coverage. A user who has registered an authenticator but is excluded from every policy that requires it is not protected; measure registration, enforcement and actual sign-ins separately.
• Fix the denominator first. Define which identities are in scope (enabled, interactive, human) and count admins, guests, user-type service accounts and emergency access accounts as their own populations.
• Exceptions belong in the number. Every excluded account lowers enforced coverage; report exceptions as a separate rate with owners and expiry dates, never silently remove them from the denominator.
• Non-human identities need a different control, not a lower bar. Workload identities cannot perform MFA, so measure them against compensating controls such as workload identity policies, federation and credential lifetime.
• Report a strict headline. The figure that matters is the share of in-scope human accounts that are registered, enforced, not excepted and seen completing MFA, with phishing-resistant coverage for administrators reported alongside.

Why simple MFA percentages mislead

Identity platforms report MFA in different ways, and each one answers a different question. A registration report says whether a method exists. A policy export says whether a rule would demand it. A sign-in log says what happened on a given day. A coverage figure built from only one of these is wrong in a predictable direction.

The fix is to measure each identity against a ladder of levels and report the share at each level, then a single strict headline.

Define the denominator

Start from an export of every identity from each identity source (identity provider, cloud provider IAM, directly managed SaaS admin consoles), then classify.

1. Remove disabled and deleted accounts: they are an account hygiene problem, not an MFA one. Report the count separately.
2. Separate humans from non-humans: accounts that a person signs in to interactively are in the MFA denominator. Service principals, managed identities and other workload identities are measured against workload controls (see below).
3. Flag user-type service accounts: user objects used by scripts, scanners or integrations are humans on paper and machines in practice. Keep them in the denominator until they are migrated, because they accept a password and are the most likely to be excluded.
4. Tag sub-populations: administrators (any privileged role, including eligible assignments), guests and external users, emergency access accounts, frontline or shared-device workers, and accounts in each cloud console that sit outside single sign-on.
5. Record activity: last successful sign-in per account. Accounts with no sign-in for 90 days stay in the denominator but are flagged, because dormant accounts with no method registered are an easy takeover target.

The five coverage levels

Measure every in-scope human account against each level. An account reaches a level only if it also meets all levels below it.

Microsoft defines isMfaRegistered as a strong method registered that "may not necessarily be allowed" by the authentication methods policy, and isMfaCapable as one that must be allowed. The difference is how you find accounts whose only method is one you have since disabled, such as SMS. Microsoft also notes that the registration figure does not reflect MFA registered outside Microsoft Entra ID, so federated or third-party MFA needs its own source.

The strict headline

Effective MFA coverage = in-scope human accounts at level 4 or above, with no active exception, divided by all in-scope human accounts. Report it alongside level 5 coverage for administrators. These two numbers are what an auditor or board should see; the other levels explain the gap.

Data sources and how to pull them

Amazon Web Services IAM

• Credential report: a CSV that lists every IAM user and the root user with password_enabled, password_last_used, mfa_active, access key status and last-used dates. IAM regenerates it at most once every four hours; it requires iam:GenerateCredentialReport and iam:GetCredentialReport.
• Denominator rule: IAM users with password_enabled = TRUE are console users and belong in the human denominator; users with access keys only are programmatic and belong in the workload population. The root user row always reports password_enabled as not_supported, so check root MFA separately. See How to Find AWS IAM Users With Console Access and No MFA.
• Federated access: people who reach AWS through an identity provider are measured in that provider; count them once.

Microsoft Entra ID

• Registration: the Authentication methods activity report (Registration tab) and the Microsoft Graph userRegistrationDetails resource, which returns isAdmin, isMfaCapable, isMfaRegistered, isPasswordlessCapable, methodsRegistered and userType per user. Microsoft states a Microsoft Entra ID P1 or P2 licence is required for Usage and insights.
• Enforcement: export Conditional Access policies and resolve every excluded group and role to accounts, as described in How to Find Accounts Excluded From MFA and Conditional Access.
• Exercise: sign-in logs record authenticationRequirement (the stage reached, which "doesn't account for previously satisfied claims"), conditionalAccessStatus (success, failure, notApplied), isInteractive and clientAppUsed, which shows legacy clients such as IMAP, POP and SMTP.

A read-only Log Analytics query for level 4 per account, run over a 30-day window:

SigninLogs
| where TimeGenerated > ago(30d) and ResultType == "0"
| summarize MfaSignIns = countif(AuthenticationRequirement == "multiFactorAuthentication"),
            SingleFactor = countif(AuthenticationRequirement == "singleFactorAuthentication"),
            LastSeen = max(TimeGenerated) by UserPrincipalName, UserType
| extend Exercised = MfaSignIns > 0 and SingleFactor == 0

Treat any account with single-factor successful sign-ins as not exercised, even if it also has MFA sign-ins: it means some path does not demand MFA.

Exceptions, emergency access and the exception rate

Exceptions are part of coverage, not outside it. Report an exception rate (excluded in-scope human accounts divided by all in-scope human accounts) and require every exception to have an owner, a reason, a compensating control and an expiry date. The MFA Exception Register Template gives the fields.

Emergency access accounts are the only exception that should be permanent, and even they should have a phishing-resistant method registered. Report them by name count, not percentage.

Where non-human identities fit

Service principals, managed identities, IAM users with access keys only and API tokens cannot answer an MFA prompt. Leaving them out of an MFA figure is correct; leaving them out of all reporting is not. Report them as a separate population with their own coverage measures:

• Policy coverage: Conditional Access for workload identities applies to single-tenant service principals registered in your tenant; Microsoft states that multitenant and third-party SaaS applications and managed identities are not covered, that service principals in a group are not enforced through group assignment, and that Workload Identities Premium licences are required to create or modify these policies. Count which service principals are directly assigned to a location or risk policy.
• Credential type: share of workloads using federation or managed identity rather than long-lived secrets or keys.
• Credential age: share of secrets and access keys older than your rotation limit, from the AWS credential report access key fields and Entra application credential expiry.

See the MFA Guide for the human side and the How to Find Accounts Excluded From MFA and Conditional Access guide for migrating user-type service accounts.

Choosing what to report, by organisation size

Deduplicate by person where one employee has accounts in several sources: report coverage per account (the attack surface) and per person (the user experience), and say which one each figure is.

How to implement

1. Inventory identity sources: list every place an account can sign in with a password: identity providers, cloud IAM, SaaS admin consoles outside SSO, VPN and network device local accounts.
2. Build the population table: one row per account with source, type, sub-population tags, enabled state and last sign-in.
3. Join registration data: add levels 1, 2 and 5 indicators from registration reports.
4. Join enforcement data: resolve every policy scope and exclusion to accounts; include report-only policies as a separate "intended" column.
5. Join sign-in data: add level 4 from a 30-day window, flagging single-factor successful sign-ins.
6. Validate on a sample: pick 20 accounts across populations and check the result by hand against the portal before publishing the first figure.
7. Publish the baseline: headline, per-level, per-population and exception rate, with definitions written on the report.
8. Automate and trend: schedule the pipeline; keep definitions fixed between reports, and when a definition changes, restate the previous figure so trends stay comparable.

Detection and measurement

• Effective MFA coverage: the strict headline, per population. Target 100% for administrators and a documented target for everyone else.
• Admin phishing-resistant coverage: share of privileged accounts that can only satisfy policy with a phishing-resistant method.
• Exception rate and exception age: excluded accounts as a share of the denominator, and the number past their expiry date.
• Single-factor success count: successful sign-ins with singleFactorAuthentication or conditionalAccessStatus notApplied per week; investigate each new account that appears.
• Registration gap on dormant accounts: enabled accounts with no method registered and no sign-in for 90 days.
• Workload credential age: share of non-human credentials past the rotation limit.

Alert, not just report, on new MFA method registration after a password reset and on sign-in by emergency access accounts. See How to Detect MFA Method Registration Abuse.

Common failure patterns

• Registration reported as coverage: the board sees the registration figure while a policy excludes a whole department. In the Change Healthcare Breach 2024, a remote access login without MFA was the reported entry point: an estate-wide figure does not help if one internet-facing portal is outside it.
• Denominator shrinkage: removing excluded or "special" accounts from the denominator so the percentage rises while risk does not change.
• Ignoring identity sources outside the provider: cloud console local users, SaaS admin accounts and VPN local accounts never appear in the identity provider's report.
• Report-only treated as enforced: policies in report-only state counted as coverage.
• Legacy protocols left open: IMAP, POP and SMTP authentication bypass the MFA prompt; sign-in logs show it through clientAppUsed.
• Stale definitions: methods that are disabled in policy (for example SMS) still counted as registered coverage.

Framework mapping

Practitioner checklist

• List every identity source where an account can sign in with a password.
• Define the denominator in writing: enabled, interactive, human, with sub-population tags.
• Measure all five levels per account and report the share at each level.
• Resolve every policy exclusion (users, groups, roles, apps, client types) to accounts.
• Count single-factor successful sign-ins and treat those accounts as not exercised.
• Keep an exception register with owner, reason, compensating control and expiry.
• Report emergency access accounts by count with their phishing-resistant methods.
• Report non-human identities as a separate population with workload controls.
• Publish the strict headline and admin phishing-resistant coverage every month.
• Restate prior figures whenever a definition changes.

Standards and references

• NIST: SP 800-53 Rev. 5
• Microsoft Learn: userRegistrationDetails resource type
• Microsoft Learn: Authentication methods activity
• Microsoft Learn: Conditional Access authentication strengths
• Microsoft Learn: Manage emergency access accounts
• Microsoft Learn: Conditional Access for workload identities
• AWS Documentation: Getting credential reports for your AWS account
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: MFA Guide · MFA Adoption Statistics · MFA Exception Register Template · Phishing-Resistant MFA Guide · How to Find Accounts Excluded From MFA and Conditional Access