Microsoft 365 MFA coverage reports for MSPs: finding every account without it

A useful Microsoft 365 MFA report answers two questions per account, not one: has the user registered an MFA method, and is MFA actually required when they sign in. Registration lives in the Authentication methods activity report and the Microsoft Graph userRegistrationDetails data; enforcement comes from security defaults, conditional access or legacy per-user MFA. A report that shows only one of these will tell you a tenant is covered when it is not. Here is how to build one that does not lie.

Registered is not the same as enforced

The most common mistake in MFA reporting is treating a green tick in one column as proof of protection. It is not. A user can have the Authenticator app registered and never be prompted, because no policy requires it. Another user can be covered by a policy that demands MFA but have no method registered, which means the first sign-in after a password leak lets the attacker register their own method.

So every row in your report needs both facts, plus the exceptions that undo them. Think of it as three columns: method registered, policy requires MFA, excluded or bypassed. Only an account that is yes, yes, no is genuinely covered.

Where MFA registration status lives

In the Entra admin centre, the Authentication methods area has a User registration details view showing, per user, whether they are MFA capable, which methods they hold and their default method. The same data sits behind Microsoft Graph at reports/authenticationMethods/userRegistrationDetails, which is the version you want for scripting across many tenants.

Useful fields include isMfaRegistered, isMfaCapable, methodsRegistered and isAdmin. Two cautions apply. First, this report needs Entra ID P1 or higher licensing in many tenants, so smaller clients on Business Basic may show limited data. Second, the old MSOnline module and its StrongAuthenticationMethods property are retired, which is why so many older scripts online now fail quietly or not at all. Use the Microsoft Graph PowerShell SDK instead.

Where enforcement status lives

Enforcement can come from three places, and a tenant may have more than one of them configured, sometimes in conflict.

Security defaults

Security defaults are a single switch under Entra ID properties. When on, they require all users to register MFA and prompt them when Microsoft judges it necessary, with admins prompted more often. They are blunt but reasonable for a small client with no P1 licensing. Your report should record whether they are on, because that one value changes how every other row is read.

Conditional access

Conditional access policies require Entra ID P1 and replace security defaults; you cannot run both. Here the work is in the detail. For each policy, check:

• State: enabled, disabled or report-only. Report-only policies enforce nothing, which surprises people more often than it should.
• Users and exclusions: which groups are included, and who has been excluded. Exclusions are where coverage leaks.
• Target resources: all cloud apps, or a selection that leaves something out.
• Client apps: whether legacy authentication is blocked, since legacy protocols cannot answer an MFA prompt at all.

Skip the exclusion check and your report will happily mark a finance director as covered because they sit in an "MFA exempt" group created during a migration three years ago.

Legacy per-user MFA

Per-user MFA, the old enabled and enforced states, still exists in some tenants and is being phased out in favour of policy-based enforcement. Record it where you find it, because it sometimes masks a gap in conditional access, and plan to migrate away from it.

Building the report across many tenants

For an MSP the hard part is not one tenant. It is forty, done the same way, every month. A practical pattern:

1. Authenticate once through GDAP. Use a multi-tenant app or your partner relationship with granular delegated admin roles, so you are not juggling a login per client.
2. Pull three datasets per tenant: userRegistrationDetails, the conditional access policy list (identity/conditionalAccess/policies) and the security defaults setting.
3. Filter to accounts that matter: enabled, licensed or privileged users. Disabled accounts and shared mailboxes with sign-in blocked are noise, though shared mailboxes with sign-in still allowed are not.
4. Resolve each user against each enabled policy, including group membership and exclusions, and mark the result.
5. Check sign-in logs for proof. Where licensing allows, sign-in logs show whether MFA was actually satisfied, which settles arguments the configuration cannot.

If you have not yet standardised what a healthy tenant looks like, start with the Microsoft 365 security audit settings to check at onboarding, then use the MFA report to keep it that way. For tooling options beyond scripts, there is a comparison of Microsoft 365 management tools for MSPs.

Reporting MFA gaps to clients without losing them

Clients do not read user tables. They read risk. Lead with the count of uncovered accounts, then name the ones that matter most: admins, finance, directors, and any account that can approve payments.

The one-page test: if a client cannot tell from the first page which accounts are exposed and what you propose to do, the report has failed, however correct the appendix is.

Separate the gaps into types, because each needs a different fix:

Every exclusion should have a named owner and a reason. Break-glass accounts are legitimate exclusions; "the CEO found it annoying" is not, and saying so in writing is how you stop being blamed later.

Where this fits with Helios

Most of an MFA report is method, not tooling: knowing that registration and enforcement are different and checking exclusions every time. Helios includes Microsoft 365 and Defender monitoring alongside its RMM and PSA, so tenant posture sits in the same place as the rest of a client's estate, whether that client is a customer of yours or your own organisation. Gaps can be raised as tickets in the helpdesk rather than living in a spreadsheet, and the daily Cyber Essentials readiness checks give MFA a recurring home in client conversations. The judgement about which exclusions to accept still belongs to you. Details of what is included are on the Helios pricing page, where every feature is on every plan.

Common questions about Microsoft 365 MFA reports

Why does the MFA registration report show no data for some tenants?

The Microsoft 365 user registration details report, and its Graph endpoint, generally requires Entra ID P1 or higher licensing. Tenants on Business Basic or Standard without P1 may return errors or partial data. In those tenants, check whether security defaults are on and inspect individual users' authentication methods through Graph instead.

Can security defaults and conditional access both be on?

No. Microsoft makes security defaults and conditional access mutually exclusive, so enabling conditional access policies requires switching security defaults off. Before doing that, make sure a policy requiring MFA for all users is already enabled, not in report-only mode, or the tenant will be left without enforcement during the changeover.

Should shared mailboxes appear in an MFA report?

Shared mailboxes belong in a Microsoft 365 MFA report only if direct sign-in is allowed. A shared mailbox with sign-in blocked cannot be used to log in, so it is noise. One with sign-in enabled has a password and no individual owner registering MFA, which makes it a genuine and often overlooked gap.

Related: Microsoft 365 licence audit for MSP clients: finding waste and turning it into a QBR win

Researched and written with Helio SEO, our AI writer for business blogs.