Require multifactor authentication for all users

As Alex Weinert, the Director of Identity Security at Microsoft, mentions in his blog post Your Pa$$word doesn't matter:

Your password doesn't matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Authentication strength

The guidance in this article helps your organization create an MFA policy for your environment using authentication strengths. Microsoft Entra ID provides three built-in authentication strengths:

  • Multifactor authentication strength (less restrictive) recommended in this article
  • Passwordless MFA strength
  • Phishing-resistant MFA strength (most restrictive)

You can use one of the built-in strengths or create a custom authentication strength based on the authentication methods you want to require.

For external user scenarios, the MFA authentication methods that a resource tenant can accept vary depending on whether the user is completing MFA in their home tenant or in the resource tenant.

User exclusions

Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies:

  • Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access.
  • Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals.
    • If your organization has these accounts in use in scripts or code, consider replacing them with managed identities.

Template deployment

Organizations can choose to deploy this policy using the steps outlined below or using the Conditional Access templates.

Create a Conditional Access policy

The following steps help create a Conditional Access policy to require all users do multifactor authentication using the authentication strength policy.

  1. Sign in to the Azure portal as at least a Conditional Access Administrator.
  2. Browse to Microsoft Entra ID > Security > Conditional Access.
  3. Select Create new policy.
  4. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
  5. Under Assignments, select Users or workload identities.
    1. Under Include, select All users
    2. Under Exclude select Users and groups and choose your organization's emergency access or break-glass accounts.
      1. You might choose to exclude your guest users if you're targeting them with a guest user specific policy.
  6. Under Target resources > Cloud apps > Include, select All cloud apps.
    1. Under Exclude, select any applications that don't require multifactor authentication.
  7. Under Access controls > Grant, select Grant access.
    1. Select Require authentication strength, then select the built-in Multifactor authentication strength from the list.
    2. Select Select.
  8. Confirm your settings and set Enable policy to Report-only.
  9. Select Create to create to enable your policy.

After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On.

Named locations

Organizations might choose to incorporate known network locations known as Named locations in their Conditional Access policies. These named locations might include trusted IP networks like those for a main office location. For more information about configuring named locations, see the article What is the location condition in Microsoft Entra Conditional Access?

In the previous example policy, an organization might choose to not require multifactor authentication if accessing a cloud app from their corporate network. In this case they could add the following configuration to the policy:

  1. Under Assignments, select Network.
    1. Configure Yes.
    2. Include Any network or location.
    3. Exclude All trusted networks and locations.
  2. Save your policy changes.

Application exclusions

Organizations might have many cloud applications in use. Not all of those applications require equal security. For example, the payroll and attendance applications might require MFA but the cafeteria probably doesn't. Administrators can choose to exclude specific applications from their policy.

Subscription activation

Organizations that use the Subscription Activation feature to enable users to "step-up" from one version of Windows to another and use Conditional Access policies to control access need to exclude one of the following cloud apps from their Conditional Access policies using Select Excluded Cloud Apps:

Although the app ID is the same in both instances, the name of the cloud app depends on the tenant.

When a device is offline for an extended period of time, it might not reactivate automatically if this Conditional Access exclusion isn't in place. Setting this Conditional Access exclusion ensures that Subscription Activation continues to work seamlessly.

Starting with Windows 11, version 23H2 with KB5034848 or later, users are prompted for authentication with a toast notification when Subscription Activation needs to reactivate. The toast notification shows the following message:

Your account requires authentication

Please sign in to your work or school account to verify your information.

Additionally, in the Activation pane, the following message might appear:

Please sign in to your work or school account to verify your information.

The prompt for authentication usually occurs when a device is offline for an extended period of time. This change eliminates the need for an exclusion in the Conditional Access policy for Windows 11, version 23H2 with KB5034848 or later. A Conditional Access policy can still be used with Windows 11, version 23H2 with KB5034848 or later if the prompt for user authentication via a toast notification isn't desired.