Cyber Insurers Want Proof of MFA. Microsoft 365 Makes That Surprisingly Hard
TL;DR
- Self-attestation on cyber insurance questionnaires is unlikely to satisfy insurers much longer, and Microsoft 365 has no single report that proves MFA coverage.
- MFA in Microsoft 365 can still be enforced three different ways, and per-user MFA settings can show disabled while Security Defaults or Conditional Access are actively enforcing it.
- Per-user MFA is deprecated as of September 30, 2025, so any tenant still relying on it needs to migrate to Conditional Access or Security Defaults.
- Every tenant with Conditional Access needs one blanket MFA policy covering all users and all applications, excluding only break glass accounts, because exclusion drift quietly erodes coverage.
- A defensible MFA report has to account for licensing, shared mailboxes, service accounts, break glass accounts, and disabled users, none of which Microsoft's native reports filter for.
"Does your organization require MFA?" is a checkbox on every cyber insurance questionnaire, and as of July 2024 most providers still accept a self-attested yes. We do not expect that to last. As requirements tighten, insurers will want evidence, and that is where Microsoft 365 has a real problem: MFA enforcement has evolved through so many overlapping mechanisms that proving coverage is harder than achieving it. This post covers the considerations that make MFA reporting complex, how to enforce it cleanly, and how to produce numbers you can stand behind.
Why is MFA so hard to report on in Microsoft 365?
Three enforcement systems still coexist
The root cause of the chaotic reporting is that MFA can still technically be enforced three different ways. For years, everyone used per-user MFA, with three simple states:
- Enabled: the user is prompted to register for MFA but can defer registration for 14 days
- Enforced: MFA is required across all sign-ins
- Disabled: MFA is not enforced
In 2019, Microsoft introduced Security Defaults, which effectively turned MFA on across all users by default. Eventually it shipped on by default in all net new tenants, though it can be turned off. Security Defaults also created the first reporting disconnect: per-user MFA can show disabled while the policy is actively enforcing MFA.
Conditional Access arrived as the third mechanism, gated behind an Entra ID P1 license, which is included in plans like Business Premium. Where licensing allows, Conditional Access is the preferred option, trading the blanket protection of Security Defaults for granular control. It carries the same reporting quirk: users can be fully enforced through Conditional Access while their per-user MFA state reads disabled.
One deadline to plan around: per-user MFA settings are deprecated on September 30, 2025. If any tenant still enforces MFA per-user, migrate it.
Conditional Access exclusions are where coverage quietly dies
Conditional Access policies support exclusions for users, groups, networks, and more. Microsoft itself recommends excluding break glass accounts so you cannot lock yourself out of the tenant. The trouble is what accumulates after that. A user might have MFA registered, but the Conditional Access policy decides whether it is enforced at sign-in, and exclusions drift over time through things like:
- Temporarily adding users to bypass MFA for some operational constraint, then never removing them
- Excluding users ahead of international travel
- Inadvertent exclusions through group membership
There is also a malicious version of this drift. Attackers who gain initial access have been observed modifying Conditional Access policies to maintain persistence and bypass MFA, frequently enough that MITRE added it as a technique in the April 2024 ATT&CK update: Modify Authentication Process: Conditional Access Policies, T1556.009 (opens in new tab).
Our recommendation: every tenant gets one blanket Conditional Access policy that:
- Includes all users, excluding only break glass accounts
- Includes all applications
- Whitelists no networks
- Applies no other filtering
- Requires MFA in the grant controls
Not all registered methods deserve to count
The methods users can register have evolved too, and the weaker ones change what your MFA numbers actually mean. Our earlier breakdown of the strongest forms of MFA and how each gets breached covers the detail; the short version is that legacy methods like SMS, voice, and even MFA push are more exposed to attacks that end in a breach. At minimum, users' default method should be Authenticator with number matching to shut down MFA fatigue attacks.
Admins control what users can register through the Authentication Methods policies. Our standing recommendations:
- Disable SMS, voice call, and email OTP
- Disable OTP on Authenticator and confirm number matching is enabled
- Enforce phishing-resistant MFA for admin accounts, for example FIDO2 keys or passkeys for Global Admins
With an Entra ID P1 license, you can review users' primary authentication methods under User registration details (Entra admin center > Protection > Authentication Methods > User registration details).
What is missing from Microsoft's native reports?
There is no central MFA report
Because registration data does not translate cleanly between legacy per-user enforcement and the modern methods, no single Microsoft report answers "who is covered." User registration details is the closest thing, and it is gated behind Entra ID P1. It also says nothing about where users are excluded from enforcement; for the full picture you are cross-referencing that report, your Conditional Access policies, and the sign-in logs.
The "Multifactor authentication capable" column is really two facts in a trench coat:
- The user has signed in at least once
- Some type of enforcement applies that would have them register for MFA
Our problem with the report is that "not capable" comes with no obvious next step unless you already know the tenant well. And a true representation of MFA adoption needs context the report does not carry:
- Is this a licensed user?
- Is this a shared mailbox?
- Is this a service account?
- Is this a break glass account?
- Is the account enabled?
Sign-in logs are evidence buried in noise
Going to the sign-in logs to verify enforcement gets overwhelming fast. The Conditional Access policies section does include a Coverage area with rollups of sign-ins where Conditional Access is not being applied:
The catch is how many factors feed each log line. In the example above, the sign-ins where Conditional Access was "not applied" turn out to include MFA being bypassed because the claim was previously fulfilled through a primary refresh token. That is noise, a false positive for the question being asked.
To genuinely find successful sign-ins where MFA was not enforced, the filter has to look more like this:
That filtered view surfaces the interesting case: a user who was evaluated for Conditional Access but is excluded from the MFA policy. That record never appears when filtering for Conditional Access not applied, and even this view can produce false positives depending on the application being accessed. More practically: nobody has time to review logs at this depth. Thousands of entries generate daily, and discerning what is going on by hand takes longer than anyone has.
What should you actually do?
The recommendations so far, condensed:
- Stop using per-user MFA. Enforce a blanket Conditional Access policy for MFA.
- Disable legacy MFA methods.
- Use the User registration details and activity report to review who is MFA capable.
- Periodically review your Conditional Access exclusions and the coverage report.
Beyond the native consoles, three tools help with reporting and monitoring MFA across customers.
CloudCapsule
CloudCapsule detects users not being enforced MFA across all methods in the tenant:
The filtering does the work the native reports will not, finding licensed users that:
- Are enabled
- Have a mailbox
- Are not a shared mailbox
- Are not covered by Conditional Access
- Are not covered by Security Defaults
- Have not registered for MFA
It also surfaces users excluded from MFA-enforced Conditional Access policies, whether directly or through group membership:
And it reports registered MFA methods per user, with weaker forms highlighted:
You can run a free assessment on a tenant to see the report for your own environment.
CIPP
CIPP is the open-source project many MSPs use to manage Microsoft environments across customers, and its MFA reporting ships with the filters you want for a true representation of adoption.
Documentation: docs.cipp.app (opens in new tab)
Microsoft 365 Lighthouse
Lighthouse (opens in new tab) is Microsoft's native multi-tenant solution for providers and gives a better lens into adoption across the different enforcement types. Our one gripe: it does not natively filter for things like licensed users only. It does support reporting exclusions, which is a genuine value-add.
Bonus: Graph APIs for building your own reporting
Frequently asked questions
Why can a user show MFA disabled but still be prompted for MFA?
The per-user MFA portal only reflects legacy per-user enforcement. Security Defaults or a Conditional Access policy can enforce MFA on that same user while the per-user state reads disabled, which is the core reason MFA reporting in Microsoft 365 confuses people.
What does the Multifactor authentication capable column actually mean?
It indicates the user has signed in at least once and has some type of enforcement applied that would have them register for MFA. It does not tell you whether the user is excluded from enforcement somewhere, or what to fix if they are not capable.
Which MFA methods should be disabled in the Authentication Methods policy?
Disable SMS, voice call, and email OTP, and disable OTP on Microsoft Authenticator in favor of number matching. For admin accounts, push toward phishing-resistant methods like FIDO2 keys or passkeys.
MFA evidence for every tenant, without the log archaeology
CloudCapsule detects users not enforced for MFA across every method in the tenant, flags Conditional Access exclusions direct or inherited, and highlights weak registered methods. The report your insurance renewal needs, in 60 seconds.
Run a free assessment
Written by
Nick Ross
CEO · Microsoft MVP · Founder, T-Minus 365
Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.
Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.
Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.
