How to enforce multi-factor authentication on Microsoft 365 (Office 365) using Conditional Access
What is Conditional Access?
Conditional Access is about more than MFA. Conditional Access is, quite literally, a number of conditions you define to permit access. One of those conditions can be requiring MFA. But, it could also include where a user is logging in from, what the user is trying to access, the device they are using, group membership, or any combination you choose.
If your users have Azure AD Premium P1 licenses, we recommend you use Conditional Access. Although setting it up requires a few extra steps, it's quite straight forward to make a sensible baseline configuration and you'll have the flexibility to make exceptions and extensions as necessary.
This means you could build up very complex Conditional Access policies if you choose to. However it is commonly used to simply mandate MFA except in certain scenarios e.g. accessing a non-sensitive app, or using a break-glass accounts.
Microsoft continues to invest in Conditional Access and it is clearly their preferred route for you to take if you can. For more information, read a more in-depth overview of Conditional Access from the official source.
If you choose Conditional Access we will show you how to prepare the necessary parts of your environment and guide you to sensible starter policies, which you can initially set to audit mode. Whilst using our automations to encourage users to register for MFA, you can monitor audit logs to have complete assurance no one will be impacted when you switch to enforce mode.
Before you start
Get business buy-in
Big changes that people notice tend to benefit from an executive sponsor to lend weight behind the change - you'll know better than us whether that makes sense for your organisation. You can read this guide for some pointers.
Prepare your support team
When adopting MFA, some users may struggle with the process of enrolling for MFA, or need help if they lose their MFA token or device after setup. Users will have a much better experience of MFA, and work disruption kept to a minimum, if the IT support team (or person as the case may be) is prepared to support both enrolment and recovery, and can get them back on their feet quickly.
To make sure everything goes smoothly when something goes wrong, we recommend you make sure anyone responding to support requests tests or practices these processes using a test account.
Before using Conditional Access to enforce MFA, you'll need to do the following:
Block legacy authentication is one of the Conditional Access policies we recommend at a minimum. This is because, even if you are using MFA elsewhere, legacy authentication can't use MFA so, if it is still enabled, attackers will take aim at legacy protocols to bypass MFA.
Before you can block legacy authentication, you must make sure no one in your organisation is using it. For example, does anyone use Office 2010 or 2013 still? Office 2010 doesn't support modern authentication and Office 2013 doesn't use it by default. Blocking legacy authentication without first modernising any legitimate use will likely break things in your team.
Depending on the age of the your Azure AD tenant, you might need to also enable modern authentication.
Follow the official Microsoft documentation on blocking legacy authentication that includes steps to find accounts that still use legacy authentication, and instructions to enable modern authentication.
If you are curious about what legacy and modern authentication is and want more background, read this blog post by the Microsoft Identity team.
With the many options of Conditional Access, designing policies can be overwhelming.
However, to start, Microsoft has a number of "Common Conditional Access Policies" (see below) that we recommend you implement at a minimum.
Each policy should be put into "Report-only mode" initially, such that it isn't enforced, but only audited. This allows you to safely check the impact of a policy before moving to enforcing later in the process.
The Common Conditional Access Policies we recommend are:
Note the "User exclusions" section in this linked page discusses break-glass accounts - if you don't already have break-glass accounts setup, now is a good time!
Depending on your requirements, you could permit only certain MFA methods. Microsoft defaults to sensible and secure options: app notification, app code or hardware token. We recommend keeping these defaults unless you have a good reason.
If you do need to change these settings, you must do so via the legacy MFA portal, as described here.
Want to learn more about MFA methods and choosing the right option for you? Read more on our blog.
Get your users registered for MFA with minimal effort using the Push platform
Before enforcing MFA, you should aim to get most users registered for MFA to avoid disruption but figuring out who needs to register and engaging with each of them is a hugely time-consuming process.