Getty Images/iStockphoto


Comparing enabled and enforced MFA in Microsoft 365

When managing Microsoft 365 authentication, IT admins may encounter the distinction between enabled and enforced MFA. Find out what those terms mean.

Many organizations opt for multifactor authentication, or MFA, to bolster security across all of an organization's systems, but it can be difficult for organizations to know all the different authentication options for IT departments to deploy.

There are numerous puzzle pieces that IT can put together to create an effective policy, including authentication methods, such as passcodes, authenticator apps and verification via a secondary trusted device. However, a major part of authentication is determining how to deploy it across an organization's entire environment.

Organizations that manage users and Microsoft services via Azure Active Directory (Azure AD) have the option to push out MFA via the Microsoft 365 admin center, but even within this process, there are numerous approaches that IT teams can take.

For enterprise organizations with assets in a Microsoft environment, deploying MFA via Azure AD is a strong approach. IT administrators can apply MFA via configuring the user state, leaving security defaults in place or using advanced conditional access definitions.

These options vary based on the Azure AD license used as well. Microsoft offers several unique license options for Azure AD, per its website.

Steps to keep you cyber safe

What's the difference between enabled and enforced MFA for Microsoft 365?

Enabling MFA via user state configuration is available for all Azure license levels and provides specific exceptions to the conditional access policy or security defaults for privileged users. The user state definition trumps both of these policies. Admins can set user states individually or in groups.

User states may be set as disabled, enabled or enforced:

  • Disabled. This is the default state for users who are not enrolled in Azure AD MFA.
  • Enabled. The user is enrolled in MFA but can still use a password for legacy access. They receive a prompt to register in MFA on the next login to a modern authentication app or website.
  • Enforced. The user is enrolled in MFA, but if they have not registered authentication methods, they are prompted to do so the next time they log in using modern authentication. Users who are in the enabled state and complete registration are moved to the enforced state.
The two most common approaches IT administrators use to deploy MFA across a Microsoft environment are via security defaults and conditional access.

Enabling MFA within Azure AD

The two most common approaches IT administrators use to deploy MFA across a Microsoft environment are via security defaults and conditional access.

Security defaults

Security defaults are provided automatically for Azure AD tenants without AD Premium licenses. This initiative in Azure AD is one that Microsoft has been working on since 2014. Despite Microsoft giving organizations tools for MFA implementation, adoption was slow. To mitigate this, Microsoft gathered input from partners and customers and combined that knowledge and experience into security defaults.

These are basic, essential settings that Microsoft manages to provide what it feels keeps their customers safe while they develop a security strategy. Thus, security defaults are a safety net to use until organizations develop a fully fledged security plan that fits their specific needs.

Security defaults were implemented in approximately 2019 and have the following characteristics:

  • Nonconfigurable.
  • Designed for Azure AD tenants without Azure AD Premium licenses.
  • Require MFA at first sign-in.
  • Require MFA for users with admin roles or those identified as a high-risk user.

Conditional access

Conditional access is provided through AD Premium P1 and P2 licensing. It provides higher-level and more granular control of authentication for defining privileged accounts, such as various admin accounts, as well as user accounts for executives and other critical accounts. Recommended admin accounts to be defined with exceptions include the following:

  • Global administrator.
  • Application administrator.
  • Authentication administrator.
  • Billing administrator.
  • Cloud application administrator.
  • Conditional access administrator.
  • Exchange administrator.
  • Help desk administrator.
  • Password administrator.
  • Privileged authentication administrator.
  • Privileged role administrator.
  • Security administrator.
  • SharePoint administrator.
  • User administrator.

Conditional access provides global policies that can be used to enforce MFA application for access to certain -- or all -- applications, require compliant devices to be used, and define access control settings to apply to specific network locations.

How should enterprise organizations handle Azure MFA?

While MFA on its own is not perfectly secure, it is a significant improvement to basic authentication. The options for deploying MFA in the enterprise are fairly mature, and it can be assumed Microsoft will continue to move toward requiring modern authentication, which enables MFA in all applications. Specific recommendations include the following:

  1. Adopt practices to move the entire enterprise to MFA. This includes identifying devices, applications and users that require specific policies.
  2. Organizations that do not have the Azure AD Premium P1 or P2 license should determine any per-user exceptions to the security defaults and how they are applied.
  3. Organizations that have the Azure AD Premium P1 or P2 license should develop the conditional access global policies, as well as any per-user exceptions required.
  4. Whichever policy method is used, determine whether the disabled state should be in place for any users. Deploy this state for access to legacy apps. This should only be the exception, and organizations must formulate a plan on how to update those apps.
  5. Once IT defines the policies, all accounts not defined as disabled should be set to enabled.
  6. Tweak the per-user exceptions as needed.

Dig Deeper on Application management

Virtual Desktop