The Microsoft 365 MFA Gap Report: What an Audit Deliverable Shows About Users Without MFA in Entra

The short version: A Microsoft 365 MFA gap report is a dated, per-user statement of who can still sign in without a second factor, which methods each person has, which accounts are excluded from the policy and why, and whether Conditional Access actually enforces any of it. It is the document an insurer or auditor asks for when "we have MFA" is not enough. This article shows what a good one contains and how to read it.

Most tenants that say they have multi-factor authentication do have it, for most people, most of the time. The trouble is the remainder: the break-glass account nobody has touched since 2023, the printer's scan-to-email mailbox sitting in an exclusion group, the three users who registered SMS as a fallback and never set up anything stronger. A Microsoft 365 MFA gap report exists to find that remainder and write it down in a form someone else can check.

This is not a guide to switching MFA on. If you need that, the step-by-step post on how to enable MFA in Microsoft 365 covers security defaults, Conditional Access and exporting the list of users who have not registered. This article is about the deliverable: what an audit-grade gap report looks like, what it tends to find, and what to do with it in the thirty days afterwards.

What is an MFA gap report, and why is "MFA is on" not an answer?

An MFA gap report is a point-in-time record of MFA coverage across every account in a Microsoft Entra tenant, with the exceptions explained. The word that matters is "every". Entra makes it easy to require MFA for a group of users and surprisingly easy to leave a handful outside that group without noticing, because exclusions are configured in a different place from the policy that creates them.

"MFA is on" usually means one of three things, and each one leaves a different gap:

• Security defaults are enabled. Everyone is asked to register, and administrators are always prompted. But security defaults cannot exclude accounts, so tenants that needed one exception often switched them off and never finished the replacement.
• A Conditional Access policy requires MFA for all users. This is the right design, but a policy is only as complete as its exclusions. Every exclusion group is a list of accounts that can sign in with a password alone.
• Per-user MFA was enabled years ago. The legacy per-user setting still exists in some tenants. It applies to the accounts someone ticked at the time, and nobody has reconciled that list against the current staff directory.

A gap report cuts across all three. It does not ask what the policy says. It asks, account by account, what would happen if this password were stolen tonight.

What does a Microsoft 365 MFA gap report contain?

The gap section of a Brocent Microsoft 365 security audit has a fixed shape, and it is worth knowing the shape so you can judge any provider's report, including ours. The sample Microsoft 365 security audit report shows the full layout for a fictitious client. The MFA part contains the following.

Registration state for every account

One row per account, not per licensed user. The difference matters because the accounts that cause trouble are often unlicensed, shared or service accounts that a licence-based export never shows. Each row records whether MFA is registered, whether it is enforced by a policy, and the last sign-in date. An account that has not signed in for six months and has no MFA is a different problem from an active one, and the report says which is which.

Methods per user, and which are phishing-resistant

Having "a method" is not the same as having a strong one. The report lists the registered methods for each person and marks the ones that resist adversary-in-the-middle phishing: passkeys, FIDO2 security keys and Windows Hello for Business. Microsoft Authenticator push with number matching is listed as a strong second factor but not as phishing-resistant. SMS and voice are flagged wherever they are still enabled in the Authentication Methods policy, because a method that is enabled can be registered as a fallback and then used.

In the sample report, 12 of 14 staff rely on Authenticator push, 2 have passkeys, all three Global Administrators use push, and SMS is still enabled with four users holding it as a fallback. That is a typical picture for a small professional-services firm, and it is a High finding rather than a Critical one, because the second factor exists but the strongest form is not required for the accounts that matter most.

Exclusions: administrators, guests, service accounts and shared mailboxes

This is the section that earns the report its name. For each account that is excluded from the MFA requirement, it records which policy excludes it, through which group, who owns it, and whether the exclusion has a stated reason. The common categories are:

• Break-glass or emergency access accounts. Legitimate to exclude from ordinary MFA, provided they have a dedicated policy, phishing-resistant methods registered, and sign-in alerting. Excluded with none of those is a Critical finding.
• Service and device accounts. The scan-to-email account for a multifunction printer is the classic case. It is a licensed user account, it holds a password that was set once, and it sits in an exclusion group because the printer cannot do MFA. The fix is not to add MFA to the printer but to move it to an SMTP relay or connector so the account can be covered or removed.
• Shared mailboxes with sign-in enabled. A shared mailbox should not be able to sign in at all. If it can, and it is not covered by MFA, it is an account.
• Guest users. Guests from partner organisations are often outside the "all users" scope by design, which is fine as long as a separate policy requires MFA for guests. The report checks that it exists.
• Users excluded "temporarily". Someone who was travelling, someone whose phone broke, someone who was onboarded in a hurry. Temporary exclusions have a habit of becoming permanent.

The sample report's first Critical finding is exactly this pattern: the "All users, require MFA" policy excludes a group called CA-Exclude, which contains a Global Administrator break-glass account with no MFA method registered and a password last set in March 2023, together with the printer's scanner account.

Conditional Access coverage and the exclusion groups behind it

A list of policies is not coverage. The report reads each MFA-related Conditional Access policy and records its state (On, Report-only or Off), its user scope, its application scope, and every exclusion group with that group's membership. A policy that has sat in Report-only mode since February is reported as not enforcing anything, because it is not. The post on a Conditional Access baseline for a small tenant explains what the six core policies should look like; the gap report shows whether yours match.

Per-department summary and the headline percentage

Decision-makers need one number, and the report gives one: the percentage of active accounts with MFA enforced, with the phishing-resistant share alongside it. It then breaks the number down by department or business unit, because "94 per cent coverage" reads very differently when the missing six per cent is the finance team.

Date of extraction and the evidence form

Every figure carries the date and time it was read from the tenant, the method used (a read-only Microsoft Graph application), and a reference to the exported file in the evidence appendix. The sample report records a read-only scan on one date and a re-check two days later. That detail is what lets someone else rely on the report. A screenshot of the admin centre with no date is an opinion; a dated export with the query that produced it is evidence.

How do you read an MFA gap report?

Read it in this order, and resist starting with the percentage.

1. Go to the exclusions first. Every account in an exclusion group is a password-only account until proven otherwise. Ask whether each one has a reason written down and an owner.
2. Then read the administrator rows. An administrator without phishing-resistant MFA is a bigger risk than a dozen ordinary users without any, because one compromise of that account is a compromise of the tenant.
3. Then check the policy states. A Report-only policy counts as Off for the purpose of the report.
4. Only then look at the coverage percentage, and compare it with the number of accounts, not the number of licensed users.
5. Finally, check the dates. If the extraction was more than thirty days before the day you are reading it, the picture has probably changed.

A report that makes you hunt for the exclusions, or buries the policy state in an appendix, is organised for the author rather than the reader.

What gaps does the report usually find?

Brocent does not publish client figures, so the examples below are the sample report's findings and a description of the pattern, not statistics.

• The break-glass account with no second factor. Created correctly years ago, excluded from MFA as the guidance says, and then never given a security key, a sign-in alert or a password rotation. In the sample it is a Critical finding with a 14-day target.
• The device account in the exclusion group. Printers, door controllers, line-of-business apps that send mail. Each one is a licensed account that cannot do MFA and therefore gets excluded, which quietly turns a hardware limitation into an identity gap.
• Strong MFA that is not strong enough for administrators. All three Global Administrators in the sample use push notifications. Push is a good second factor for staff; for administrators, the report recommends a phishing-resistant authentication strength enforced through Conditional Access.
• Everyday accounts holding Global Administrator permanently. Not an MFA gap in the strict sense, but the report records it in the same section because the risk is identical: the account most likely to open a phishing attachment is also the account that can change every setting.
• Legacy authentication still allowed. MFA cannot protect a protocol that does not support it. If IMAP, POP or SMTP AUTH sign-ins appear in the logs, the MFA policy has a hole regardless of coverage. The sample report found 214 such sign-ins in thirty days, from the scanner account and one Thunderbird user.
• SMS still enabled as a method. Not registered by most people, but enabled tenant-wide, which means anyone can register it as a fallback and an attacker who has the password can use it.

The case story of an MFA rollout at a Hong Kong accounting firm shows how these gaps appear in a real-shaped organisation and what the staff experience of closing them is like.

What do insurers and auditors look for in MFA coverage evidence?

Cyber insurance questionnaires have become specific. The question is rarely "do you use MFA" any more; it is "is MFA enforced for all users, all administrators, all remote access and all email access, and can you evidence it". Supplier security questionnaires from larger clients ask the same thing in different words. Cyber Essentials, for UK-facing businesses, treats MFA that is available on a cloud service but not enabled as a failing condition, as the post on Cyber Essentials with Microsoft 365 explains.

What those reviewers can use is a document that:

• Is dated, so it can be matched to the renewal or assessment period.
• Covers every account, with the exclusions listed and explained rather than hidden.
• Distinguishes enforced from registered. Registered means the user set a method up; enforced means a policy requires it. Only the second one answers the question.
• Names the methods, so the reviewer can see whether "MFA" means passkeys or text messages.
• Shows the policy evidence, with the Conditional Access export and the group memberships behind it.

Brocent's report and the accompanying workbook are designed to be used as evidence in exactly these conversations. They do not make any insurer, auditor or certification body accept anything; that decision is theirs. What the report does is put the facts in a form that can be checked. The companion post on answering a cyber insurance questionnaire with Microsoft 365 evidence walks through the specific questions.

Three ways to get a picture of MFA coverage

The comparison most people need is between the three sources of MFA information that already exist or can be bought, because they answer different questions.

• The authentication methods registration and activity report in Entra. Built into Entra at no extra cost, and accurate about registration. It does not know about Conditional Access exclusions, cannot tell you which accounts are excluded from enforcement, and does not record policy state. Good for chasing unregistered users; weak as evidence.
• The Secure Score MFA improvement actions. Also built in. Secure Score gives a percentage and a recommended action, which is useful as a trend line. It reads only what the API exposes, it does not list the exceptions, and no insurer or auditor treats a Secure Score screenshot as an assessment of coverage. The post comparing Secure Score, the CIS Benchmark and ScubaGear goes into why.
• An audit gap report. Paid, dated, account-level, exclusions explained, policy states recorded, evidence files attached, and reviewed by a person who checks the manual controls a script cannot read. This is the one you hand to someone else.

The first two tell you what to fix. The third tells someone else that you did.

What should happen in the thirty days after the report?

The sample report's own roadmap is a reasonable template, and it puts the MFA items first.

1. Days 0 to 14: close the Critical items. Register phishing-resistant methods for the break-glass account and give it its own policy and alert. Move the scan-to-email account to a relay or connector. Switch the "block legacy authentication" policy from Report-only to On and disable SMTP AUTH at organisation level.
2. Days 15 to 30: raise the bar for administrators. Enable passkeys in the Authentication Methods policy, require phishing-resistant authentication strength for all admin roles through Conditional Access, and move everyday users out of permanently assigned Global Administrator roles into dedicated admin accounts.
3. Days 15 to 60: extend to everyone. Run a short guided session so staff register a passkey, then disable SMS and voice as methods once registration is complete.
4. Re-check. Re-run the extraction and compare the coverage numbers. A report that showed gaps on the first read and none on the re-check is the evidence most reviewers actually want: not that there were no gaps, but that they were found and closed.

If the organisation has no one to do this work, that is what a managed MFA rollout is for. Brocent's MFA solutions page describes the implementation service, which covers the policy design, the staff sessions and the follow-up check, and the audit is where that work usually starts.

Frequently asked questions

What is an MFA gap report in Microsoft 365?

A dated, account-by-account record of which accounts in a Microsoft Entra tenant are enforced to use multi-factor authentication, which methods each has registered, which accounts are excluded from the requirement and why, and what state the Conditional Access policies that enforce it are in. It is one section of a Microsoft 365 security audit, and it is the section insurers and auditors ask about most.

How do I find users without MFA in Entra myself?

The Entra admin centre's authentication methods registration report lists who has and has not registered, and a short PowerShell query exports the same list to CSV. The how-to post linked above has the steps. What that export will not show you is the exclusion groups, so pair it with a review of each Conditional Access policy's exclusions.

Is the authentication methods registration report enough for an insurer?

Usually not on its own. It shows registration, not enforcement, and it says nothing about exclusions or policy state. Reviewers tend to ask for the policy evidence as well. An audit report assembles both, with dates, into one document that is designed to be used as evidence.

Does Brocent's MFA gap report change anything in my tenant?

No. The audit uses a read-only Microsoft Graph application that one of your Global Administrators consents to once. It reads configuration and sign-in metadata; it does not read email or documents and it does not change any setting. The consent can be withdrawn at any time by removing the application.

How much does the audit cost and how long does it take?

The Microsoft 365 security audit is a fixed price set by headcount: US$450 for 1 to 10 users, US$990 for 11 to 25, US$1,800 for 26 to 75 and US$2,900 for 76 to 150, with larger tenants quoted. The report arrives 5 to 7 business days after read-only access is granted. The MFA gap section is included; it is not sold separately. Full details are on the Microsoft 365 security audit pricing page.

What counts as phishing-resistant MFA?

Methods that bind the sign-in to the legitimate site so that a proxy page cannot replay it: passkeys, FIDO2 security keys and Windows Hello for Business. Authenticator push with number matching is a strong second factor but can be defeated by adversary-in-the-middle kits. SMS and voice are the weakest and are flagged in the report wherever they remain enabled.

Will the report say we are compliant?

No. The report records facts about your tenant against the CIS Microsoft 365 Benchmark and notes where a finding is relevant to Cyber Essentials or a typical insurance question. It does not certify compliance with any scheme or regulation, and it does not guarantee that any insurer or auditor will accept it. It is designed to be used as evidence; the judgement remains theirs.

Next steps

If you already know your tenant has exclusions nobody can explain, start with the built-in registration report and the how-to post, and close the obvious gaps this week. If you need a document that someone outside the organisation can rely on, the audit produces the gap report described here as part of a full review of the tenant. The scope, the price bands and the 5 to 7 business day timeline are on the pricing page, the sample report is on the Report Central page, and if you would rather talk it through first, contact a consultant.