As cybersecurity insurance continues to evolve, I believe we are going to continue to see stricter requirements in reporting as it relates to common questionnaire topics such as organizations requiring MFA. Self-attestation will not be enough for most insurance providers out there in my opinion. As Microsoft MFA has evolved over the years, reporting has become very complex given the various ways it can be enabled. In this article, I am going to provide you with some of the top considerations with MFA in M365 and some helpful tips on enforcement and reporting.
Considerations
MFA Enforcement has evolved over time. Stop using per-user MFA.
The main reason for the FUBAR reporting in M365 is because it can still technically be enforced in 3 different ways. For the longest time, we all enforced MFA with something known as Per-User MFA where you simply had 3 options:
- Enabled => Required users to perform MFA immediately across all logins
- Enforced => Allowed users to defer registering for MFA for 14 days
- Disabled => MFA not enforced
In 2019, Microsoft came out Security Defaults which basically turned-on MFA into the “Enforced” mode across all users by default. Eventually, this was on by default in all net new tenants, but you do have the option to turn it off. With Security defaults, you also had a disjointed reporting system where Per-User MFA could show disabled but MFA was actually being enforced by that policy.
We also had Conditional Access that was introduced but it was gated behind an Entra ID P1 license (formally known as Azure AD P1). This license is only included in tenants that had licensing like Business Premium. Conditional access is the preferred option for enforcing MFA if you have the licensing as you get a lot more granular control vs the blanket protections of Security defaults. Same as with Security defaults, users could have MFA enforcement with Conditional access but the per-user MFA settings can show disabled which confuses people. As a note, per-user MFA settings will be deprecated in September 30, 2025. You should not still be using per-user settings to enforce MFA.
Conditional Access can quickly become swiss cheese. Ensure you have a blanket MFA policy for All Users.
As most of us know, within conditional access we can create exclusions to our policies such as excluding users, groups, networks, etc. Microsoft recommends excluding some break-glass accounts to ensure you do not lock yourself out of the tenant. Conditional Access has evolved greatly over time and we now have various policies that might enforce MFA. What I am starting to see more of is various exclusions in policies that occur over time that can lead to misconfigurations in enforcement. While a user might have MFA set up, the conditional access policy dictates whether or not it is enforced upon sign-in. Natural drift can occur over time in exclusions through things like:
- Temporarily adding users to overcome some operational constraint where MFA needs to be bypassed
- Users being excluded as they are going on international travel
- Inadvertent exclusions through group membership
We have also seen malicious tampering of Conditional access policies where attackers modify these policies after gaining initial access so that they can maintain persistence and bypass MFA. This has been seen so much so that MITRE has now included it in their list of techniques in the latest April 2024 update: Modify Authentication Process: Conditional Access Policies, Sub-technique T1556.009 – Enterprise | MITRE ATT&CK®
In my opinion, to overcome this constraint, you should always have a conditional access policy that enforces the following:
- Includes All Users, only excludes break glass accounts
- Includes All Applications
- Does not whitelist any Networks to exclude from enforcement
- Does not have any other filtering going on
- Requires MFA in the Grant controls
MFA methods and the evolving attack surface
The MFA methods a user can register for have evolved over time as well. Check out my previous article on MFA to see the various types of MFA and how they can be breached:The strongest form of MFA? | Why your MFA may need an upgrade – (tminus365.com)
TLDR, legacy methods like SMS, Phone, and even MFA push are more susceptible to attacks that can lead to a breach. It’s now important, you understand what MFA methods users are leveraging and at a minimum, make sure their default method is MFA on Authenticator with number matching to avoid attacks like MFA fatigue.
As an admin, you can alter the MFA methods available that a user can register for in the Authentication Methods policies. My recommendation has always been to:
- Disabled SMS, Voice Call, and Email OTP
- Disable OTP on Authenticator and make sure number matching has been enabled
- Try to enforce phishing-resistant forms of MFA for Admin accounts (ex. FIDO2 keys/Passkeys for Global Admins)
If you have an Entra ID P1 license, you can review the users primary authentication methods in this section as well under User Registration Details (Entra Admin Center>Protection>Authentication Methods>User registration details)
There is no central MFA report
As I mentioned earlier, due to the inconsistency of MFA registration translating between the legacy per-user enforcement and modern methods, MFA has become very hard to report on. The User registration details page that I showed in the previous section is the closest you get in my opinion but remember, it is gated by an Entra ID P1 license. This report also does not tell you where users might be excluded from being enforced MFA. You would need to review a combination of this report, your conditional access policies, and/or the sign-in logs to see this information to its fullest extent.
The column for “Multifactor authentication capable” is basically an indicator that:
- The user has signed-in at least once
- They have some type of enforcement being applied that would have them register for MFA
The problem I have with this report is that its not very clear what to do next if the user is not “capable” if you don’t know what you are doing within the tenant. There are also several other factors we typically take into consideration for a true representation of MFA adoption like:
- 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
Entra ID logs can help but are a lot of noise
If you try to go into the sign-in logs to see MFA enforcement, you can quickly get overwhelmed. Within the Conditional Access Policies section, you do have a “Coverage” area that allows you to see rollups of sign in information where conditional access is not being applied:
My problem with this report and evaluating sign ins overall is that there are so many factors at play here. In the above example, if I look at the logs where conditional access is not being applied, I actually can see that MFA was bypassed as it was previously fulfilled in the claim using my primary refresh token. This data then is a lot of noise and a “false positive”.
If I truly want to see successful sign in where MFA was not enforced, I’d have to filter to something more like this:
This log is interesting though as this user was evaluated for conditional access, they are just being excluded from the MFA enforced policy. This record does NOT show up if I filter for Conditional access not applied. Even this could produce some false positives depending on the application being accessed. Also, who has time to review logs in this much depth? There are thousands of logs that get generated and it would take a very long time to discern what’s going on.
Tools that can help with reporting
To summarize the recommendations I have that can help you with reporting so far:
- Stop using per-user MFA. Enforce a blanket conditional access policy for MFA.
- Disable legacy forms of MFA.
- User the User Registration Details and Activity report to review who is capable for MFA
- Periodically review your conditional access policy exclusions and the coverage report
The following are other tools I recommend that can help with the reporting and monitoring of MFA across your customers:
This is a tool I’ve created that you can leverage to view MFA data. This will detect users not being enforced MFA across all methods in the tenant:
I am filtering to find:
- 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 been registered for MFA
Additionally, I can quickly see users being excluded from MFA enforced CA policies either directly or through group membership.
Lastly there is direct reporting on the MFA registration methods leverage by user, with weaker forms of MFA being highlighted.
Run a free assessment on a tenant to see what this report looks like for you.
CIPP is an open-source project many MSPs leverage to manage their Microsoft environments across customers. This tool also has great reporting on MFA with the proper filters you would want to be looking at for a true representation of MFA adoption.
Lighthouse is Microsoft native solution for providers that also can provide you a better lens into adoption across the different types of enforcement. My only gripe here is that they do not natively allow you to filter for things like only users with a license. They do however allow you to create exclusions for reporting purposes which is a nice value-add.
Bonus: APIs that help with reporting:
Getting Users Default MFA Method: https://learn.microsoft.com/en-us/graph/api/authentication-get?view=graph-rest-beta&tabs=http
Getting Users Per-User MFA State (new): https://learn.microsoft.com/en-us/graph/api/authentication-get?view=graph-rest-beta&tabs=http#example-2-get-a-users-mfa-state
Getting Users Additional MFA detail: https://learn.microsoft.com/en-us/graph/api/authentication-list-methods?view=graph-rest-beta&tabs=http
Getting User MFA Registration Information: https://learn.microsoft.com/en-us/graph/api/reportroot-list-credentialuserregistrationdetails?view=graph-rest-beta&tabs=http