MFA in M365 (for MSPs) – Some Common Misconceptions

‍

I speak with many MSPs online, in demos, at events, over email, and chat. They must cover multiple areas of knowledge. Maintaining specialist knowledge in each area is a constant battle.

But when MSPs search for answers, they're often met with a sea of information from others trying to make sense of things too. True expertise can get lost amongst the speculations and partial confusions. Microsoft 365, being ubiquitous, adds to their challenges. So, whenM365 gets complex, MSPs naturally find it tough to navigate and simplify  

Damn Microsoft MFA

Mastering MFA in Microsoft 365 is challenging. Not because Microsoft can't simplify it (although this is a thing),but because there are multiple mechanisms for implementing MFA, each with strengths and weaknesses. Microsoft aims for a balance between security and ease of use. Additionally, MS juggle offering adequate security-for-all while upselling higher license plans with better security. This leaves us with three MFA mechanisms in M365, each with their own complexities.  For a refresher on MFA mechanisms see my other blog article in the series

I have found multiple misconceptions about MFA perpetuated by echo chambers of IT professionals trying their best to make sense of it all.

Misconception 1

Security Defaults is strict about MFA

Security Defaults isn’t strict about MFA.  Some know this, however many that do, might not grasp the extent to how soft Microsoft can be on prompting MFA.  Security Defaults applies MFA always only for administrators and, when it deems necessary, for all other users.  The logic behind when it challenges normal users for MFA (which appears reasonable on paper) has considerable complexities and nuances rendering it potentially weaker than I would like to see. On paper users are prompted for MFA primarily when they appear on a new device or app, or when performing critical roles and tasks.

In writing this blog, and creating the Octiga MFA analyzer, I had multiple conversations with one of our partners GlobalNet and their MD Robert Burdett. He has contacted Microsoft trying to get to the bottom of when it was applied and how to gain confidence in rolling it out.  Robert has considerable experience yet was challenged by what he had observed.  In one instance security defaults had failed to prompt for MFA leading to a breached account.  The device and location used were new and so on the face of it MFA should have been prompted.  On another instance Roberts team tested security defaults prompting by changing locations (using VPNs) and devices and found the prompting to be underwhelming. While the latter example might be Microsoft anticipating the VPN (we cannot be sure), the former is quite worrying

If any of you readers have more examples feel free to contact me.  Needless to say whether you have an organization that demands strict adherence to MFA then security defaults are in this writers opinion, underwhelming.

Misconception 2

Security Defaults requires per user MFA to function properly

Some MSPs that I have spoken with recently, after encountering the aforementioned lax prompting from Security Defaults, have turned to Per User MFA to “enforce” its application.  This is leading to a belief among some MSPs that this is best practice.  However both mechanisms are designed to work independently and necessarily require the other.  Yes, coupling them adds belts to the braces, however it then can leave MSPs wondering how they can achieve exceptions; which are naturally supported by Per-User MFA but not by security defaults.  For me, as I outlined in my previous article.  Choose Per-User MFA if you need exceptions and proper enforcement. Then ensure it is managed.  Octiga can help with managing the latter 😉

Misconception 3

Per User MFA is deprecated/legacy (and a bit sh1t)

This appears to be an false echo chamber.  For the past year at least I was, like many, under the firm impression that Per-User was soon to be removed, and we would all soon have do something else that was not clear.  This has been propagated, in my opinion by the convergence of two somewhat unrelated confusing factors/stories. The first is the referral to Per-User MFA as legacy. I’m not sure where this came from, but it seems to be propagated simply because Microsoft want folks to update to Conditional Access Policies.  The second is the reporting that  multifactor authentication (MFA) and self-service password reset (SSPR) policies are migrating away to a new authentication methods policy  https://o365info.com/migrate-legacy-mfa-authentication-methods/

This does not mean Per-User MFA is going away but rather the policies controlling auth methods and self service password reset (SSPR) is migrating to something new.

IMHO Per-User MFA is here to stay

https://learn.microsoft.com/en-us/answers/questions/1289935/per-user-mfa-after-september-2024

https://answers.microsoft.com/en-us/msoffice/forum/all/per-user-mfa-deprecated/b05f2dcf-186e-4d34-852a-60fbc3fcd5ce

Misconception 4

Per User MFA “Enabled” always automatically switches to “Enforced”

Normally enabled means they should enroll and enforced means they have enrolled.

However, there is a gotcha here.  Normally when you set Per-User MFA to Enabled, it prompts the user to set up an auth method.  However, after enrolment, If you were to set the user back to enabled after being in enforced, then the user will not automatically be transitioned back to enforced unless they re-register of their own volition.  In practice this can happen inadvertently, after disabling MFA temporarily for some legitimate reason (like the user lost their device) and then wishing to re-enable them.  

The solution of course is to always skip the enabled state.  Instant enforcement(and forced enrolment where required)

Misconception 5

MFA Policy = enrolment

After reading Misconceptions 1 and 2 it should be clear that this does not hold, however it is technically true for all MFA policies (Mechanisms) to differing degrees. Octigas’ usage data shows that there is a high rate of MFA non-enrolment were policies exist.  This could be because the user is in a constant state of deferral (possible in the case of Per-User MFA) or because an admin has switched Per-User MFA back to enabled from enforced (this is a strange quirk outlined here) for the user.  Even for conditional access policies (when demanding strict MFA), the user may have been created and never used leaving their account open to an attacker adding their own MFA method.  Finally shared mailboxes can have direct sign-in enabled making them vulnerable.  

Octiga have an MFA roll-out tool which identifies all these risky accounts and advises accordingly, guiding you to full MFA adoption. It takes exceptions into account.  What’s more it backs the detection with baselines so that user drift can be kept under wraps

Misconception 6

MFA enrolled = safety

We hear about breaches constantly from prospective clients.  These days there is an alarming number of breached WITH MFA enrolled.  It is done usually through man in the middle token theft, usually arising from phishing. It is hard to prevent without education and phishing/safe links detection, however finding the breach afterwards is easier through comprehensive geo-aware monitoring. (Did I mention Octiga do this too 😉)  

‍

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5

Heading 6

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

Block quote

Ordered list

1. Item 1
2. Item 2
3. Item 3

Unordered list

• Item A
• Item B
• Item C

Text link

Bold text

Emphasis

^Superscript

_Subscript