The M365 MFA Reporting Gap: What Cyber Insurers Ask vs. What You Can Actually Prove

Every cyber insurer now asks some version of the MFA question.

Coalition splits it into four separate vectors: email, VPN, remote access, and privileged accounts.[1] Travelers asks whether the applicant has multi-factor authentication for remote access to email and other systems that contain private or sensitive data in bulk.[2] The Hartford’s current underwriting application asks, separately, whether MFA is required for all remote access to the network and whether MFA is required for access to email.[3]

The answer feels simple. “Yes, we have MFA.”

In Microsoft 365, though, that sentence can hide three very different realities:

• users are registered for MFA but not consistently required to use it,
• Conditional Access requires MFA for most users but excludes a quietly growing exception group,
• Security Defaults are enabled, which is a strong baseline, but remote access paths outside Microsoft are not actually covered.

That is the reporting gap.

There is no single Microsoft 365 report that gives you the exact carrier-grade answer insurers want: “MFA is enforced for every relevant user, on every relevant access path, with no unexplained holes.”

Microsoft gives you pieces of evidence. It does not give you a clean attestation sentence.

That distinction matters because cyber-insurance forms are not asking whether MFA exists as a technology. They are asking whether the relevant people and systems are actually protected.

Why this is now an insurance problem, not just a security problem

Carrier forms have converged around MFA because credential-based intrusion is still one of the most common ways attackers get in.

Microsoft says Security Defaults are built to stop common identity-based attacks, and its documentation notes that more than 99.9% of common identity-related attacks are stopped by using MFA and blocking legacy authentication.[4] Carriers have taken the same lesson, but they express it in legal language rather than security language. They do not ask whether MFA is “rolled out.” They ask whether it is “required” or “enforced.”

That difference becomes material the moment someone signs an application.

Travelers’ short-form renewal application says the authorized representative signs after reasonable inquiry and that Travelers may rely on those statements as the basis for providing insurance.[2] Coalition’s form says the application becomes part of the policy and reserves the insurer’s right to disclaim claims or rescind the policy for material misstatement or misrepresentation.[1]

So when an MSP says, “we have MFA everywhere,” what the insurer hears is closer to: “we can defend that answer if challenged.”

Why there is no single MFA report in Microsoft 365

This is not because Microsoft forgot to add a button. It is because Microsoft Entra evolved over time, and MFA control now lives across multiple mechanisms and reporting surfaces.

At minimum, you have to understand four separate pieces:

1. Security Defaults
2. Conditional Access
3. Per-user MFA
4. Sign-in evidence and user registration data

Those surfaces answer different questions.

1. Security Defaults

Security Defaults are Microsoft’s baseline, preconfigured identity security settings. Microsoft says they require all users to register for MFA, require administrators to do MFA every time they sign in, require users to do MFA when necessary, block legacy authentication, and protect privileged activities such as access to Azure management surfaces.[4]

That is a strong starting point, especially for small tenants on free licensing. But it is not the same thing as a carrier-ready proof statement for every possible access path.

Why not?

Because Microsoft also explains that end users under Security Defaults are prompted “when necessary,” and that Microsoft decides when MFA is required based on factors such as location, device, role, and task.[4] That is good security design. It is not the same thing as a bespoke, reviewable policy that says “all users, all cloud apps, no exclusions, require MFA.”

There is another source of confusion here: Microsoft explicitly notes that if you look at the legacy per-user MFA status page, users protected by Security Defaults or Conditional Access will show up as Disabled.[4] That means the admin who opens the old MFA page is often looking at a screen that implies the opposite of what is really happening.

2. Conditional Access

Conditional Access is the modern, customizable way to require MFA in Entra. Microsoft recommends moving from per-user MFA to Conditional Access MFA and says organizations that need more complex requirements should use Conditional Access rather than Security Defaults.[5][4]

Conditional Access is powerful because it can target:

• all users or selected users,
• all apps or selected apps,
• different risk conditions,
• different client and device conditions,
• different access controls, including MFA.[6]

From an insurance-attestation perspective, Conditional Access is where the real work starts.

A good MFA policy may look airtight from the policy name alone: “Require MFA for all users.” But that does not tell you the full truth. Microsoft’s policy structure includes includeUsers, excludeUsers, includeGroups, and excludeGroups, and the Graph API exposes all of those fields directly.[6]

Microsoft’s own guidance is also clear that exclusions override includes.[7] It even recommends exclusions for emergency or break-glass accounts in many deployment scenarios.[7][8]

That is not a flaw. It is normal administration. But it means a tenant can have a policy that appears universal while still excluding real identities.

That is the single biggest reason there is no clean “carrier-ready MFA report” in Microsoft 365. You have to inspect both the policy logic and the exception logic.

3. Per-user MFA

Per-user MFA is the legacy mechanism. Microsoft now explicitly recommends switching from per-user MFA to Conditional Access MFA.[5]

Per-user MFA still shows up in smaller and older tenants, and it introduces two practical problems:

First, it lives in an older admin surface that many teams still use as a source of truth even though it no longer tells the whole story.

Second, the statuses it shows are easy to misread. Microsoft describes per-user MFA as a tenant state worth migrating away from and advises administrators to require MFA via Conditional Access and then turn the per-user configuration off.[5]

If you are using Security Defaults or Conditional Access, the per-user MFA status page can show Disabled even though MFA protection exists elsewhere.[4] If you are still using per-user MFA on some accounts while Conditional Access covers others, you now have a mixed-control environment that almost guarantees confusion.

4. User registration data and sign-in evidence

The Graph userRegistrationDetails report is useful, but it answers a different question than most insurance forms.

Microsoft’s documentation says the report returns information about the authentication methods registered for a user and properties such as isMfaRegistered, isMfaCapable, and methodsRegistered.[9] That is extremely valuable for enrollment hygiene. It is not a universal enforcement verdict.

A user can be isMfaRegistered = true and still not be forced through MFA on a path that matters to the insurer.

Sign-in logs are the other half of the picture. Microsoft says sign-in logs show authentication details for events when a user is prompted for MFA and whether Conditional Access policies were in use.[10] That is stronger evidence because it shows real runtime behavior. But even here, Microsoft warns against simplistic interpretation. It notes that some sign-ins may appear as single-factor because the MFA requirement was already satisfied by an earlier claim in the token flow, and it specifically tells admins not to rely only on the authenticationRequirement field.[10]

So again: useful evidence, but not one attestation-ready answer.

Security Defaults: when the simple answer mostly works

If Security Defaults are enabled, you have a significantly cleaner starting point than a messy mixed-mode tenant.

Microsoft says Security Defaults:

• require all users to register for MFA,
• require administrators to perform MFA every time they sign in,
• require users to perform MFA when necessary,
• block legacy authentication,
• and protect privileged activities like Azure portal access.[4]

That can support a strong “Yes” to many carrier questions about Microsoft-controlled access, especially for smaller tenants without custom access paths.

But it is important not to overstate what Security Defaults prove.

If the insurance question is specifically about email access in Microsoft 365, Security Defaults are relevant. If the question is about all remote access, Security Defaults are not a full answer if the client also uses:

• a standalone VPN appliance,
• third-party remote support tooling,
• on-prem RDP outside Entra,
• non-Microsoft identity paths.

Security Defaults are a baseline identity control. They are not a universal attestation engine.

Conditional Access: where the exclusions hide

This is the part most MSPs and internal IT teams underestimate.

A tenant can have a beautifully named MFA policy and still have meaningful holes.

Microsoft’s Conditional Access documentation makes two things clear:

• you can include and exclude users and groups, and
• when a user or group is both included and excluded, the exclusion wins.[7]

Microsoft also provides separate guidance on managing users excluded from Conditional Access policies, precisely because real organizations end up with those exceptions over time.[8]

Here is the classic failure path:

1. An MSP builds a broad “require MFA” policy.
2. A small exception group is created for emergency accounts or hard-to-migrate service accounts.
3. A real user gets added temporarily during troubleshooting.
4. Nobody removes them.
5. Months later, the tenant still looks “MFA protected” at a glance, but that user is outside the policy.

Now multiply that by:

• multiple Conditional Access policies,
• overlapping scopes,
• role-based policies for administrators,
• app-specific targeting,
• emergency-access accounts,
• legacy exceptions kept around “just for now.”

From an underwriting perspective, this is exactly why “we use Conditional Access” is not enough.

What a real CA audit looks like

If you want to answer an insurance form honestly, you need to do more than confirm a policy exists.

A serious review means:

1. list all enabled Conditional Access policies,
2. identify which policies actually require MFA,
3. inspect which users, groups, or roles are included,
4. inspect which users and groups are excluded,
5. expand those groups to actual identities,
6. confirm the relevant applications are in scope,
7. separately review any access path not controlled by Entra.

That is not hard because the logic is impossible. It is hard because it is time-consuming and easy to skip.

Per-user MFA: the legacy trap

Per-user MFA remains common enough in small-business tenants to keep causing insurance mistakes.

The trap is not only that it is legacy. The trap is that it still looks authoritative.

An admin opens the page, sees that some users are “Enabled” or “Enforced,” and concludes the tenant is covered.

That is not necessarily wrong, but it is incomplete.

Microsoft’s recommendation is to move away from per-user MFA and use Conditional Access instead.[5] Once you do that, the older per-user screen is even more confusing, because users protected by Conditional Access or Security Defaults can show up as Disabled on that page.[4]

So you end up with the worst possible reporting experience:

• a legacy view that looks simple,
• a modern policy engine that actually controls access,
• and no built-in report that reconciles the two into a carrier question like “Is MFA enforced for all users who can access email?”

The reconciliation problem

This is the real technical task behind the insurance answer.

If you want to answer, “Is MFA enforced for all users?” in a way that survives scrutiny, you have to reconcile multiple control planes and evidence sources.

A practical workflow looks like this:

Step 1: check whether Security Defaults are enabled

If yes, document that clearly. It is meaningful baseline evidence.[4]

Step 2: enumerate Conditional Access policies requiring MFA

Use the Entra portal or Graph. Look for enabled policies with MFA in grant controls and review their scope.[6]

Step 3: inspect all exclusions

Do not stop at the policy name. Expand excluded groups to actual members. Remember that exclusions override includes.[7]

Step 4: review user registration data

Use userRegistrationDetails to find users who are registered, capable, and method-equipped for MFA.[9] But do not confuse registration with enforcement.

Step 5: review sign-in evidence where necessary

For disputed or high-risk identities, use sign-in logs to see whether MFA was actually challenged, how it was satisfied, and which Conditional Access policy applied.[10]

Step 6: account for access paths outside Microsoft

This is where many insurance answers quietly fail. If VPN, RDP, or vendor remote access happen outside Entra, Microsoft 365 cannot prove those paths for you. Those systems need their own evidence.

Once you do all of that, you finally have something close to a carrier-grade answer.

That is why there is a market for this category. The answer is not conceptually difficult. It is operationally fragmented.

What this means for a cyber insurance application

Coalition asks four separate MFA questions because insurers know that “email MFA” and “admin MFA” are not identical.[1] Travelers compresses the concept into one extremely consequential question about remote access to email and systems holding sensitive data.[2] Hartford splits the concept again into remote access and email.[3]

Across all three, the underlying question is the same:

Can you prove that the people who matter are actually protected on the access paths that matter?

Not “do you own an MFA product.” Not “have users registered an authenticator app.” Not “is there a Conditional Access policy named Require MFA.” Not “did I see green checkmarks in the portal.”

The insurer is asking whether the control is true in the environment.

What a defensible MFA evidence pack should include

If you are preparing for renewal, the best evidence package usually includes:

• tenant-level Security Defaults status,
• list of enabled Conditional Access MFA policies,
• documented user and group exclusions,
• export or summary of MFA registration coverage,
• sign-in evidence for sampled or high-risk users,
• separate verification for non-Microsoft remote access,
• privileged-account review showing MFA coverage for admins.

That may sound heavy. It is still lighter than defending a bad attestation later.

The practical lesson

Microsoft 365 is not missing MFA. It is missing a carrier-ready, single-sentence proof layer.

The platform has:

• strong baseline controls,
• modern policy controls,
• legacy compatibility controls,
• and detailed runtime evidence.

What it does not have is a clean report that says:

“Here is every relevant identity. Here is the control path that protects it. Here are the exclusions. Here are the uncovered users. Here is the answer you can defend.”

That is the gap BindLedger is built to close.

BindLedger connects to the tenant, checks Security Defaults, enumerates Conditional Access policies and exclusions, pulls registration data, reviews admin coverage, and turns the result into a carrier-mapped answer instead of a portal scavenger hunt.

If you want a fast first pass, start with the public email-security scan. If you want the hard part solved, start with M365 MFA verification before your next renewal is signed.

A better workflow for the next renewal

If your team is about to answer a carrier’s MFA question, do not rely on the Entra page you happen to know best. Reconcile the control first.

BindLedger is built to do that work automatically: check Security Defaults, enumerate Conditional Access policies, inspect exclusions, review registration coverage, and turn the result into a carrier-mapped answer instead of a manual scavenger hunt. Start with the free scan for public email-security posture, then use M365 verification for the control that insurers care about most.

If you want the broader Microsoft service map around that problem, read Cyber Insurance for Microsoft 365 Tenants: The 2026 Attestation Checklist for the full M365 attestation picture.