Common Conditional Access policy: Require MFA for all users

  • Article

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.

The guidance in this article helps your organization create an MFA policy for your environment.

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 tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant to 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. Service accounts like these should be excluded since MFA can't be completed programmatically. 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. As a temporary workaround, you can exclude these specific accounts from the baseline policy.

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.

For more information about configuring exclusions in Conditional Access policies, see Application exclusions.

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.

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.

  1. Sign in to the Azure portal as a Conditional Access Administrator, Security Administrator, or Global 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.
  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, Require multifactor authentication, and 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 to 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 Conditions > Locations.
    1. Configure Yes.
    2. Include Any location.
    3. Exclude All trusted locations.
    4. Select Done.
  2. Select Done.
  3. Save your policy changes.

Next steps

Conditional Access templates