3 ways to implement Multi-Factor Authentication (MFA) protection controls for Microsoft 365

In this blog I’ll go through the 3 different methods of implementing Multi-Factor Authentication (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 to show which of your accounts have registered for MFA and how to check which methods they’re using.  

How to enable MFA controls

Security defaults

Per-User MFA 

Conditional Access 

Which Type To Use? 

Checking Your Configuration – download your free PowerShell script

Author: Ben Owens, Technical Architect at Cloud Business

Ben Owens, Technical Architect at Cloud Business

An experienced Technical Architect, Ben supports customers with Professional Services. He takes a truly consultative approach by encouraging open and creative conversations about technology during the discovery phase, helping businesses to uncover the best solutions for their users.

Ben’s specialisms include Microsoft 365, Exchange, Identity and Modern Desktop with Microsoft Endpoint Manager.

How to enable Multi-Factor Authentication (MFA) controls

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

  • Security Defaults 
  • Per User MFA 
  • Conditional Access 
Multi-factor authentication protection options

The focus of this blog is around the method of providing MFA protection using Azure AD and not via federated identity using ADFS or 3rd party solutions.

Security defaults  

This is a global setting. It’s fundamentally an on/off switch for providing MFA protection for all accounts on your tenant. It provides MFA protection across the board to all your accounts 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 process, 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. This 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 about security defaults

  • It’s 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 
  • Users are required to register and use the Microsoft Authenticator app 

Per-user Multi-Factor Authentication

As its name suggests, it’s enabled on a per account basis. In comparison to security defaults, this does give you the flexibility to make exceptions to accounts. However, its benefit is also its 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 won’t have MFA protection. 

Key points about per-user Multi-Factor Authentication

  • It’s 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 than the ruleset around MFA control. For example, you can implement a conditional access policy which only allows access to M365 resources from an organisational device, or from a user connecting from a trusted external IP address. The level of access can also be controlled to those resources, for example, restricting the ability to download attachments from M365 on non-organisational devices. 

Unlike security defaults and per-user MFA, conditional access requires an Azure AD premium P1 licence or above. This comes bundled in with Microsoft 365 E3 plans and above (a plan we typically see in use). It also comes bundled with Microsoft 365 business premium plans too. 

Key points about Conditional Access

  • It requires an Azure AD Premium licence P1 or above 
  • You can provide MFA for all accounts by default whilst allowing exceptions in specific conditions 
  • It provides greater flexibility in your conditions required 
  • It can provide much more than just controls around MFA verification 

How are they invoked and what should you use?

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

Multi-factor authentication protection options security defaults, per-user MFA, Conditional Access

The method which takes precedence, if enabled, is security defaults. This is a broad brush on/off setting for all accounts; so, if you have that enabled, then per-user MFA or a conditional access policy will not function as expected for that user’s login.  

If you want to use per-user MFA, you will need to firstly switch off security defaults. You will then need to administer MFA on a per account basis.  

If you want to use conditional access for providing MFA protection, you will also need to firstly disable security defaults. The users scoped to your conditional access policies shouldn’t be enabled with per -user MFA either. Although it’s 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 result in some security gaps. 

Which Type To Use? 

For a new tenant, you would initially use security defaults. It’s turned on from the get-go and you would use that protection before deciding on the most appropriate method for your organisation.  

If your tenant will home a relatively small number of users, and you don’t have a license plan which includes Azure AD premium P1 or above, then security defaults is probably a good option to consider.   

If you want to get more flexibility or to allow exceptions, but don’t want to purchase Azure AD Premium P1 licenses, then per-user MFA maybe a better fit. The obvious negative is that you need to make sure that users are enabled for per-user MFA as soon as you provision their account.   

If you have your users licensed for Azure AD premium P1 or above, then looking to adopt conditional access policies would make sense. This way you can have a policy that protects all users by default which requires no additional manual tasks by an administrator to enable MFA. This also gives you the flexibility of adding exceptions to your policies on a more granular basis.   

Checking Your Configuration

You can use the following PowerShell script below to determine which of your users have registered for MFA and if so, whether they’re using Per-User MFA. You can download it from – https://github.com/Cloud-Business/MFATypeReport/blob/main/MFATypeReport.ps1 .  

The script requires that you connect to your tenant using the Microsoft Online Module. If you don’t have this, see the following link: https://docs.microsoft.com/en-us/microsoft-365/enterprise/connect-to-microsoft-365-powershell?view=o365-worldwide#step-1-install-the-required-software-1 .  

Once you have connected to your tenant using the MSOL module, run the script. This will provide an output CSV file like the below:  

Multi-factor authentication MFA Protection report summary


The above provides direction of how to review and plan the correct MFA protection method for your organisation.  

If you’re looking for assistance in these areas, please get in contact and we’ll be happy to help. 

How secure is Azure?

Author: Russell McKee, Senior Consultant & Azure Architect Covering this ‘how secure is Azure’ blog, is Russell McKee. An experienced Azure Architect and Senior M365 Consultant with

Cloud Business logo white
Microsoft Gold Partner Logo - Cloud Business

Cloud Business Limited
8 North Street

2023 © Cloud Business Limited
Registered Company in England and Wales 06798438