M365 MFA for MSPs

Our tests show that, even when an MFA policy is in place, 20% of applicable accounts have no MFA enrolment.  Why?  We'll get to that.  

This article is designed to help MSPs deliver MFA by helping them understand the choices, pointing out the pitfalls in the mechanisms and rollout

Introduction to MFA and the challenges

Multi-Factor Authentication (MFA) is an authentication double check that requires users to present two or more verification factors to access a resource. It couples the traditional "what you know" (such as a password or PIN) with "what you have" (like a a smartphone, token or security device).  

If you were to only do one security thing, then enforcing MFA everywhere possible should be it.

Challenges in choosing the right MFA mechanism

When rolling out and maintaining MFA for their clients, MSPs encounter several challenges and decision points.  

1.     Different Licenses and MFA Mechanisms

Different clients have various Microsoft365 licenses, giving them access to different MFA mechanisms. Some might use Conditional Access policies, while others must rely on per-user MFA or security defaults. MSPs need to grasp these differences to effectively set up and manage MFA.

2.     Exceptions

Some user accounts, such as service accounts or accounts used for automated processes, may not be suitable for MFA. Scenarios where MFA might not be appropriate include:

• Service Accounts: These accounts are often used by applications or services and may not support MFA.
• Shared Accounts: Accounts shared among multiple users can complicate MFA implementation.
• Legacy Systems: Older systems or applications that do not support modern authentication methods may require exceptions.
• Stubborn Individuals: Lets face we all know one person who will go without MFA to reduce complexity in their lives

3.     Adoption and Maintenance

MSPs need to continuously monitor and adjust MFA settings to accommodate these scenarios while maintaining overall security in face of changes to users, onboarding and offboarding.  Some of the mechanisms are more difficult than others to rollout, and maintain. More over Octiga find that an alarming amount of users are left unenrolled even when a mechanism is in place.  

Fortunately automation like Octiga can close the gaps in analysis, delivery, maintenance, alerting and remediation.  More on that later…

4.      Understanding Each Mechanism

Each MFA mechanism has its own set of pros and cons. For example, Conditional Access policies offer granular control and flexibility but require higher-tier licenses. Per-user MFA is simpler to implement but easy to mismanage without automation. Security Defaults are simple but inflexible and don’t allow for exceptions.  MSPs need to thoroughly understand these mechanisms to choose the best option for each client.

‍

Mechanism 1 – Security Defaults

Security Defaults enforce a set of pre-configured security settings that include MFA registration and conditional MFA prompts.  They provide a baseline level of security by requiring (among other things) all users to register for Multi-Factor Authentication (MFA) and challenging them when necessary. They are simple; Either on or off

But Here’s the Rub

MFA prompts are not triggered for every sign-in attempt. According to Microsoft's documentation, with Security Defaults enabled, users are prompted for MFA primarily when they appear on a new device or app, or when performing critical roles and tasks. This means that admins are always asked however regular user accounts may not be prompted for MFA during every sign-in, especially if they are using familiar devices and applications.  

The uncertainty around when they are applied may not suit orgs with stricter compliance requirements.  It is likely the reason why the CIS M365standard recommends that security defaults be turned off.  

Furthermore you cannot configure exceptions, which won’t suit everyone.  Organizations with legacy systems, certain integrations, break glass accounts, or other specific requirements that need exceptions to MFA enforcement may find Security Defaults too restrictive.

Limitations of Security Defaults

• MFA is not always applied in every scenario
• No granular control of conditions
• No user/account exceptions

When to Choose Security Defaults

• M365 business basic or similar licenses that do not include Azure AD Premium P1/P2
• Very straightforward security needs with no exceptions or legacy systems
• Prefer a simplified, out-of-the-box security solution without the need for extensive customization.
• Are willing to let Microsoft determine when MFA is applied

Security Defaults Summary

Security Defaults are a straightforward way to get MFA up and running in Microsoft 365, perfect for smaller organizations with basic security needs. For those needing more control and flexibility, other MFA options in Microsoft 365 should be considered.

Mechanism 2 – Conditional Access Policies

Conditional Access policies (CA Policies) are often ideal(if available in the license ) as they provide a powerful and flexible way to enforce MFA in an array of optional conditions.

Happily the conditions can be blunt if you want simplicity, such as always requiring MFA for all users, or alternatively be based on various smart rules, such as user location, device compliance, application being accessed, and risk level of the sign-in attempt. For example, a policy might require MFA for all users accessing sensitive applications, block access from untrusted locations, or only allow access from compliant devices.

Licenses

CA policies require Azure AD Premium P1/P2 which is in MS365business premium or higher.  M365 Business Basic and Standard don’t include it by default.  

Some orgs will overcome the extra cost by using a loophole in MS licensing, where they buy 1 x Business Premium License but if Microsoft do an audit, they may penalize.  Be clear do not advocate this.  

Multiple Policies - Don’t go Nuts

Be aware that CA policies cover many areas of access and you can make as many of them as you like, they have no priority order and are evaluated in parallel.  

The effect of multiple similar polices, each adding different restrictions, will be the sum of those restrictions.  So for example if one policy restricts the user in one way and the other restricts them in another way then the result will be the sum of those restrictions. Put another way, adding more conditional access policies can never loosen restrictions  

Limitations of Conditional Access Policies

• License.  Requires Business Premium or Higher
• Maintenance:     Regular reviews and possibly updates to ensure alignment
• Complexity:     But only if you need nuanced policies.

When to Choose CA Polices

• Business Premium or Higher
• Need for granular control (blunt or tailored) over MFA enforcement  
• Needs exceptions.

CA Polices Summary

If the organization has the license then they are usually ideal because, in their basic form, offer a quick and comprehensive way to achieve MFA. Further they are particularly well-suited for organizations with advanced security requirements and the need for granular control over access conditions. But keep them as simple as you can for your own sake.

‍

Mechanism 3 – Per User MFA

Per User MFA is a simple method for enforcing MFA across an organization at a user level. In this approach, MFA is enabled individually foreach user, rather than relying on broader policies or conditions. It is available for all M365 licenses so its flexibility coupled with its availability can make it ideal for organizations who don’t have the license for Conditional Access Policies but need more flexibility or control than than offered by Security Defaults.  

No it isn’t deprecated

There is an apparently common misconception that per user MFA is legacy and/or deprecated and going away. I speak with hundreds of MSPs. Many believe this. I too believed this, and while I keep an open mind, now find this to be an echo chamber based on some mis-interpreted headlines.  

See here and here

The problem is exacerbated by Microsoft referring to it as Legacy MFA.  In my humble opinion this is to encourage the users to either use security defaults or upgrade to Conditional Access Policies.  

 But here’s the Rub(s)

Rub #1 – The Three Body Problem

Per User MFA is like a wall of switches, each for an account, but with 3 positions.  Wait 3 positions Ihear you say.  Yes there is disabled,enabled and enforced.  Simply put enabledgets users to enrol, but can defer indefinitely and still login without it.  When they do it switches to enforced.  

Rub #2 Avoid the Enabled State

There are some corner cases where deferral can be prevented but these require either security defaults or Azure AD premium license, and if you were using these you likely wouldn’t be here  in the first place.  The other corner cases is around an admin manually putting an already enrolled user from enforced back to enabled.  Even though they are enrolled they will again get the option to not use MFA

Switching them directly to enforced manually is the best option as it prevents deferral.

Rub #3 – Its hard to manage

Given the fact that switching is manual and rub #1 can add complexity, then careful management is required.  Use Octiga’s per user MFA baseline to enforce, monitor, alert and relax 😉

Limitations of Per-User MFA

• Harder to Manage/Maintain
• Enabled State can be misleading
• It always requires MFA – There is no device/location based relaxation

When to Choose Per-User MFA

• Has M365 business basic/standard or similar licenses that do not include Azure AD Premium P1/P2
• Needs exceptions
• Need MFA to always be enforced(irrespective of device/location)

Per-User Summary

Per-user MFA provides a robust security mechanism by ensuring that multi-factor authentication is always enforced, regardless of device or location. However, it is harder to manage and maintain due to its rigid enforcement and can sometimes present misleading enabled states. Per-user MFA is particularly suitable for organizations with M365 business basic or similar licenses and where exceptions are needed or there is a requirement for MFA to be consistently enforced without any relaxation based on device or location.

Rolling Out & Maintaining MFA

For existing tenants without MFA then start by liaising with the client about the license benefits, and desired outcome and exceptions if applicable.  Then choose the mechanism based on the above sections.  Once chosen it is a good idea to give clear instructions to the client about the date(s) of rollout and some simple education on how to set up MFA, choosing an authentication method (app) or hardware solution.  It can be a good idea to deliver the MFA to users in batches (not suitable for security defaults) so as to manage and improve roll out procedure.  

MFA maintenance is straightforward for security defaults and conditional access policies.  All that is required is to monitor the policies to ensure they are always on, and in the case of conditional access policies that only desired exceptions are in place.  It is common for exceptions to be added when a sudden need arises, but common for these never to be removed.  

Per User MFA requires careful maintenance to ensure that each user is enabled or better still, enforced upon onboarding.  

20% of Users have No MFA.

Octiga monitors settings across thousands of M365 tenants globally.  Our data shows an alarming trend.  On average 20% of users do not have an MFA authentication device even when an MFA policy is in place on the tenant.  

This can be for many reasons including

1. users who perpetually differ enrolment,
2. temporary users that remained in place,
3. employee accounts that were never used,
4. shared mailboxes with direct sign-in enabled(yes this is a thing and its very common),
5. and user accounts that are being shared for whatever reason.  
6. Un enrolment of authentication devices

Octiga closes the gaps in deployment, analysis, maintenance and remediation

Whether using security defaults, conditional access policies or per user MFA Octiga can assist in multiple ways with setup, roll-out, maintenance, alerting and remediation. You can run a report to find unenrolled users.  Leveraging this report, the end result can always be zero gaps, through subsequent encouraged enrolment, sign-in blocking, adding exceptions, or unenrollment.  

Only then will you have rolled out MFA

‍