I.D.E.A #004 – MFA, you say?

It’s time for another I.D.E.A., and this time I am focusing on one of my true callings in life: MFA for everyone.

The MFA reporting that comes natively in your tenant is honestly sub-par, so this is a task I have been handing off to PowerShell for a long time. But now it’s time to present it in a more complete and cohesive way, wrapped up as a proper I.D.E.A. tool.

The issues with the built-in MFA reports

MFA is an absolute must-have in 2026. Alone, by itself, it is far from enough, but without it an attacker can much more easily breach your tenant. So when we’re talking security, something you need to know as a fact, and not guess at or say “it should be,” is your MFA coverage. Simply: How many accounts have MFA methods registered?

I always start here because if an account has no MFA method registered, that account is practically up for grabs for anyone who can find or guess the password. For all intents and purposes, it is completely unprotected and will be hijacked. It is only a question of when.

Today in Entra the best native overview is found at Authentication methods | Activity (under Monitoring). There you get simple statistics for has/has not MFA registered, and clicking through gives you a list with filter options to see each account’s status for MFA, password reset, registered methods, and so on. Screenshots below.

A few important details that may not be obvious:

• The report does not include disabled accounts. This is confirmed in Microsoft’s own documentation. The registration details report excludes disabled and soft-deleted users.
• The report treats voice and SMS as “no MFA” for the purposes of the MFA capable flag. I was honestly torn about this, because technically it is a second factor, so by definition the account has some protection. But in a general security context, that protection is close to zero. I suppose this is what happens when you try to present something that comes in shades of grey in pure black and white.

Beyond the Activity report above, you have Identity Secure Score, which in my experience is pretty unreliable and often fails to update, and it only tells you has/has not MFA without any nuance. There are also reporting options inside Conditional Access and the sign-in logs, but none of them give you a clean, actionable overview of MFA coverage across your tenant.

And yet, that is exactly what you need. You want to know, as an absolute bare minimum, specifically which accounts have MFA and which do not, and what those accounts actually look like.

Looking at the native list, I quickly find a few questions it simply cannot answer:

• When did these unprotected accounts last sign in, if they have signed in at all?
• Which of them have privileged roles assigned?
• Which of them are shared mailboxes, meeting rooms, and other resource accounts that should be disabled, but may have been enabled for some reason. (For example meeting rooms paired with 3rd party vendors)
• You can filter for passwordless capable, but passwordless is not the same as phishing-resistant.

So all in all, the native report gives you a starting point, but it is simply not enough.

What I.D.E.A #004 provides

Available at GitHub. (Link)

The script connects to Microsoft Graph (using the Beta API for authentication method data) and Exchange Online, then pulls every account in the tenant and analyses it. Exchange Online is used specifically for authoritative mailbox type detection: Shared mailboxes, room accounts, and equipment accounts are identified by their actual RecipientTypeDetails value, not guessed from display names or UPN patterns.

The script is menu-driven and also reminds you to clean up old logs and exports since the HTML and CSV exports contain personal data including names, email addresses, phone numbers, and sign-in activity.

For each account the script determines:

• Which MFA methods are registered, covering the full range: FIDO2 security keys, Windows Hello for Business, Microsoft Authenticator (including passwordless phone sign-in), software and hardware OATH tokens, SMS, voice call, email OTP, and Temporary Access Pass.
• Whether the account is enabled or disabled.
• What type of account it is: Regular user, shared mailbox, room, or equipment.
• Whether it holds any Entra directory or privileged roles (admin status).
• Licensing status.
• Last sign-in activity, pulled from the audit log.

Risk score

From those inputs it assigns every account a risk score, based on the combination of strongest and weakest methods registered:

One detail worth calling out: Good and Secure are meaningfully different. A user with a FIDO2 key registered but SMS still on their account can still be reached through that SMS by anyone who can SIM-swap them. The distinction matters and the report surfaces it explicitly.

MFA Strength

The script also classifies accounts into five MFA strength categories for the summary view:

• No MFA: Enabled account, nothing registered.
• Weak only: Has SMS, voice, or email OTP, but no Authenticator and no phishing-resistant method.
• Authenticator only: Has Microsoft Authenticator registered, but no phishing-resistant method.
• Phishing-resistant: Has at least one of FIDO2, Windows Hello for Business, or Passkey.
• Other MFA: Has a method registered that does not fit the categories above, or unable to determine because the account resides in a Restricted Management AU.

The script output

The script generates a self-contained HTML dashboard that should open automatically in your default browser when the report is complete. Optionally, it can also export two CSV files: A detailed per-user export and a summary report.

The HTML dashboard has four main sections:

⬆️MFA method distribution bar: A full-width stacked bar showing all enabled accounts distributed across the five MFA strength tiers, left to right from weakest to strongest, colour-coded red through green. At a glance you can see the shape of your tenant’s MFA posture. “Other MFA” will also apply to accounts residing in an RMAU (like breakglass accounts).

⬆️Admin and member stat cards: Two columns of three cards each, one column for accounts with Entra directory roles and one for regular member accounts. Each card shows a count as X / N (accounts in that state out of the total in that group). The cards are red when counts are above zero for the bad categories, green when clean. A footer line summarises guest account status underneath.

⬆️Risk score pie chart: Distribution of accounts across the five risk levels (Critical, High, Medium, Good, Secure), plus N/A for disabled accounts. This is the view that tells you where to focus first.There is also a phone number country distribution pie chart, which shows where registered phone MFA numbers are geographically distributed. Useful for spotting unexpected countries in your tenant’s phone MFA registrations.

⬆️Below the dashboard, the report includes a sortable, filterable table covering every account in the tenant, with columns for account type, admin status, licensing, last sign-in, risk score, and the specific MFA methods registered. Filters include risk level, MFA status, user type, account category, sign-in activity, licensing, admin status, and MFA method presence, with AND/OR logic.

🚨 Data privacy note: The HTML and CSV exports contain personal data including names, email addresses, phone numbers, and sign-in activity. Handle them in accordance with your organisation’s data protection policy and applicable regulations. Store in a secure, access-controlled location, share only with authorised recipients, and dispose of securely when no longer needed.

Required permissions

The script requires the following Microsoft Graph app scopes, plus an Exchange Online connection:

• User.Read.All
• Directory.Read.All
• UserAuthenticationMethod.Read.All
• AuditLog.Read.All (for last sign-in data)

A couple of issues

If you hit a 403 Authorization_RequestDenied error when connecting after consenting to the permissions above, the most likely cause is a stale WAM (Windows Account Manager) token cache. WAM caches tokens aggressively and will silently hand back a minimal token without prompting for new scopes. The fix is straightforward: Clear the cache with the command below, then reconnect through the script menu.

Remove-Item "$env:LOCALAPPDATA\.IdentityService" -Recurse -Force -ErrorAction SilentlyContinue

If the issue persists, run the script with -DiagnosticMode to capture a full transcript including the granted scopes on the token.

⚠️ ExchangeOnlineManagement version note: At the time of writing, version 3.9.2 of the ExchangeOnlineManagement module fails to connect if you are already connected to Microsoft Graph. Either connect to Exchange Online first and then connect to Graph, or uninstall ExchangeOnlineManagement and then install version 3.9.0.

Uninstall-Module Exchangeonlinemanagement
Install-Module ExchangeOnlineManagement -RequiredVersion 3.9.0 -scope Currentuser

That’s it for this time

If you decide to try this tool, I’d appreciate it if you shared it with others who might benefit from it.

💡Here’s the thing the native reports keep getting wrong: MFA coverage is not a yes/no question. The Activity report will tell you an SMS-only account has “no MFA” while a FIDO2 account has MFA, as if one is protected and the other isn’t. But both have a method registered, they are just worlds apart in actual strength. The whole point of this tool is to surface that grey area instead of flattening it, so you can see exactly where you stand and where to focus first.

My opinion is that MFA coverage is one of those things that should never be a guess. But as always, no automated approach catches every edge case, so pair the information from the report with your own tenant knowledge and keep asking the uncomfortable questions.

Thank you all for reading our blog!