In the world of Microsoft 365, there are many ways to accomplish Security & Compliance goals for an organization. Until recently, submitting a username and password was considered the standard and secure approach for User sign-ins.  This approach is also known as Basic Authentication.  It requires just one authentication factor – password – which can be easily compromised.  To achieve a more robust identity strategy, most organizations today leverage Multi-Factor Authentication (“MFA”) for securing User sign-in. When considering deployment of MFA for your End Users, there are three main approaches to consider: Legacy MFA, Security Defaults and Conditional Access Policies.

Legacy MFA

Legacy MFA is probably one of the most common ways to deploy MFA to your User base. This simple “on/off switch” can enforce strong authentication for your End Users quickly and easily. But don’t let that fool you – Legacy MFA is the least secure approach to implementing MFA for M365. With Legacy MFA, your tenant is still open to attacks and exploits, since Basic Authentication is still available. Plain and simple, having Basic Authentication enabled puts your tenant at risk. Using Legacy MFA is great for testing Azure AD MFA, the registration process and sign in experience.  However, outside of testing scenarios, don’t rely on Legacy MFA to be your silver bullet for securing your M365 tenant.

Security Defaults

Security Defaults are the most practical and easiest approach to implement MFA for End User sign in for many small and midsize organizations. The focus of Security Defaults is to change the behavior of End User sign-in and completely do away with Basic Authentication in favor of Microsoft’s Modern Authentication.

Security Defaults applies the following configuration changes to your tenant:

• Implements MFA for all Users, including privileged accounts such as Global Administrators as well as End Users.
• Block all Basic Authentication such as IMAP, POP3, SMTP, and other clients that do not use Modern Authentication.
  • This will impact older clients and applications that traditionally rely on Basic Authentication.
• Require MFA for all administrators, controlling actions to administrator portals such as Microsoft 365 and Azure, and accessing PowerShell as well as Azure CLI.

Security Defaults are Microsoft’s current standard for bare minimum-security configuration of an M365 tenant, with Security Defaults being enabled with all net-new tenants after October 2019.

Security Defaults remove the pain of managing MFA on a per individual User basis as seen with Legacy MFA.  It requires Modern Authentication for all Users in a tenant and disallows the use of Basic Authentication. With Security Defaults enabled, all authentication attempts must be made with MFA. But with this ease of management comes with some limitations, such as not being able to configure MFA locations, session controls, application restrictions and many other configurations that make Modern Authentication based MFA more convenient for End Users. In addition, with the basic Azure AD plans, using Security Defaults removes the ability to support SMS sign-in, which is only available via Conditional Access Policies or with Legacy MFA. Security Defaults is an easy and free way to ensure that Basic Authentication attempts are blocked and End Users are signing into both M365 services and data in a more secure fashion.

Conditional Access Policies

Azure AD Conditional Access Policies introduces the highest level of secure identity, while providing the most amount of flexibility and configurability for authentication to you M365 tenant. Conditional Access is often used in conjunction with other policies such as User Risk Policies and Device Policies to help determine whether to block or grant an authentication request. Conditional Access Policies are simple – you set a series of “IF” statements, and then apply “Grant Controls” to dictate how authentication requests are handled. If a User wants to authenticate to M365 to access a service, application or data, the Conditional Access will challenge the End User with an action that needs to be completed. These actions can be:

• require MFA for authentication
• be physically present at a specific location (ex: corporate office)
• block an authentication request

An example of this would be a Sales Manager that wants to access Microsoft Teams and is required to use MFA to authenticate into the Teams service.

Conditional Access Policies are made up of a combination of Signals and Decisions:

1. Defining the scope of the Conditional Access Policy, also referred to as “Signals” (these are the “IF” statements):
   1. Users or Group memberships
      1. Target specific Users or Groups in your tenant to apply Conditional Access Policies.
   2. Role
      1. Create Conditional Access Policies specifically for Administrator Users.
   3. IP Location
      1. Leverage Trusted Locations to drive a certain authentication behavior based on the End User’s IP location.
   4. Devices
      1. Using Intune or Azure AD devices can drive certain authentication behaviors based on potential device related risks.
   5. Applications
      1. Microsoft first party applications like Exchange, Teams, SharePoint etc.
      2. Enterprise Applications such as any applications registered in your Azure AD Tenant for Single Sign-On.
   6. Risk Detection
      1. Leveraging Sign-Risk and User-Risk Policies.
   7. Microsoft Defender for Cloud Applications
      1. Enables User access and monitored sessions along with other “real-time” Cloud Application Controls.
2. Grant Controls – also referred to as “Decisions”
   1. Grant Access – this is mostly used in Trusted Location scenarios where access is granted based on the IP of the User, such as at a corporate office.
   2. Grant Access but…
      1. Require MFA.
      2. Require that a Device is marked as Compliant (using Intune or Azure AD Device Management).
      3. Require a Hybrid Azure AD joined device.
      4. Require approved Client Application.
   3. Block Access

Conditional Access Policies use a combination of Signals and Decisions to help you deploy a fine-grained authentication methodology that balances an easy User experience with securing M365 services and data. Conditional Access Policies are Microsoft’s recommended best practice, due the infinite scalability and flexibility of Conditional Access Policies.

But all this customization and ease of use comes at a cost. Conditional Access Policies are only available to tenants who have Azure AD P1 licenses or are included in bundle SKUs such as M365-E SKUs. If you are managing a large-scale tenant with requirements around compliance, Conditional Access Policies should be your first stop.

Conditional Access Policies were built to address the ever-changing climate of Enterprise cloud Application usage.  They do an excellent job at providing the needed security and authentication controls to limit unauthorized access by bad actors, or by an End User who has been misconfigured.

If you’re reading this, you’ve already taken a step in the right direction by exploring MFA deployment for your User base.  How you deploy MFA is entirely dependent on how you manage, who you manage, and the needs of your End Users. Considering the three different approaches listed above, find the best path that provides your End Users with access to the M365 resources without significant administrative burden.

Additional Reading:

• https://docs.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/multi-factor-authentication-microsoft-365?view=o365-worldwide
• https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
• https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview