Introduction

In this blog I’ll go through the three different methods of implementing MFA protection for sign-ins to your Microsoft 365 tenant. I’ll summarise how those methods differ and which you should consider implementing. Lastly, I’ll demonstrate how to generate a report on which of your accounts have registered for MFA and the check which methods they’re using.

To enable MFA controls in, you essentially have three options:

• Security Defaults
• Per User MFA
• Conditional Access

(The focus of this blog is around the method of providing MFA protection using Entra ID and not via federated identity via ADFS or 3^rd parties)

Security defaults

This is a global setting. It’s fundamentally an on/off switch for providing MFA protection for all account on in your tenant. It provides MFA protection across the board to all your accounts and with no exceptions.

In practice, when signing into a new account, the user would have 14 days (from initial sign-in) to set up an MFA method. The user could choose to skip that if they wish, but after 14 days they would be forced to set up their MFA method. Subsequent logins would then be subject to an MFA claim to access the tenant.

Security defaults was introduced in October 2019 and was primarily aimed at providing a baseline protection for all newly provisioned M365 tenants. Prior to this, tenants were created without any MFA protection by default.

Key points to note about security defaults.

• It is free with no additional subscription required for MFA protection
• It’s enabled by default on newly provisioned tenants
• There are no exceptions in MFA protection – this is important to note if you require an account login which cannot complete an MFA prompt.
• You cannot use SMS as a verification method – although this is generally discouraged now
• User are required to register for and use the Microsoft Authenticator app

Per-User MFA

As its name suggests, it’s enabled on a per account basis. In comparison to security default, this does give you the flexibility to make exceptions to accounts. However, it’s benefit is also it’s Achilles’ heel. You must proactively enable per-user MFA on an account, either via script or via the admin console. If you don’t enable per-user MFA on that account, it will not have MFA protection.

Key points to note about per-user MFA defaults

• It is free with no additional subscription required for MFA protection
• You control which accounts have MFA protection
• There are no exceptions in MFA protection – this is important to note if you require an account login which cannot complete an MFA prompt

Conditional Access

By using conditional access to implement MFA protection you have far greater flexibility in the scenarios where MFA is required. For example, you could require MFA for all users, but make exclusions for accounts connecting from a particular location.

By using conditional access policies, you can also go much further in your ruleset around MFA controls. For example, conditional access policies can used to require that only managed organisational devices can access certain M365 resources. The level of access can also be controlled to those resources. For example, restricting the ability to sync or download attachments in Exchange Online and Sharepoint (in combination with EXO and SPO settings).

Unlike security defaults and per-user MFA, conditional access requires an Entra ID premium P1 license. This comes bundled in with Microsoft 365 E3 plans and above (a plan commonly in use for medium sizes businesses). It also comes bundled with Microsoft 365 business premium plans too.

Key points to note about per-user MFA defaults:

• Requires an Entra ID Premium P1 or above license for each user logging into the service
• Can provide MFA for all accounts by default and allow exceptions in specific conditions
• Provides greater flexibility in your conditions required
• Can provide much more than just controls around MFA verification

Which Method Takes Precedence?

You would only use 1 of these 3 methods of providing MFA protection. The way they’re implemented is basically in order of three, so be aware if you’ve enabled more than 1 way to provide MFA protection.

1. The method which takes precedence (if enabled) is security defaults. This is a broad brush on/off settings; so, if you have that enabled, then per-user MFA or a conditional access policy will not function as expected for a user’s login.
   
2. If you want to use per-user MFA, you will need to switch off security defaults. You will then be using MFA on a per account basis.
   
3. If you want to use conditional access for providing MFA protection, then the users scoped to your conditional access policies shouldn’t be enabled with per -user MFA. Although possible, I wouldn’t recommend using a mixture of per-user MFA protection for some accounts and conditional access MFA protection for others. This can be confusing for troubleshooting and will likely results in security gaps.

Which Type To Use?

For a new tenant, you would initially use security defaults. It’s turned on by default and you would use that protection at the start before deciding.

If you tenant will have a relatively small number of users, and you didn’t have a license plan which included Entra ID Premium P1 or above, then security defaults is good option.

If you want to get more flexibility, or if you want to have exceptions, then per user MFA is a better fit. But obvious negative is that you need to make sure that users are enabled for MFA as soon as you provision them.

If you have you users licensed for Entra ID premium P1, then looking to adopt conditional access policies would make sense. This way you can have a policy that affects all users by default requires no manual tasks. Users would be enabled by MFA by default, but also gives you the flexibility of implementing exceptions for those as well.