Require phishing-resistant multifactor authentication for administrators

Accounts that are assigned privileged administrative roles are frequent targets of attackers. Requiring phishing-resistant multifactor authentication (MFA) on those accounts is an easy way to reduce the risk of those accounts being compromised.

Caution

Before creating a policy requiring phishing-resistant multifactor authentication, ensure your administrators have the appropriate methods registered. If you enable this policy without completing this step you risk locking yourself out of your tenant. Administrators can Configure Temporary Access Pass to register passwordless authentication methods or follow the steps in Register a passkey (FIDO2).

Microsoft recommends you require phishing-resistant multifactor authentication on the following roles at a minimum:

• Global Administrator
• Application Administrator
• Authentication Administrator
• Billing Administrator
• Cloud Application Administrator
• Conditional Access Administrator
• Exchange Administrator
• Helpdesk Administrator
• Password Administrator
• Privileged Authentication Administrator
• Privileged Role Administrator
• Security Administrator
• SharePoint Administrator
• User Administrator

Organizations might choose to include or exclude roles based on their own requirements.

Organizations can use this policy in conjunction with features like Privileged Identity Management (PIM) and its ability to require MFA for role activation.

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)
• Passwordless MFA strength
• Phishing-resistant MFA strength (most restrictive) recommended in this article

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. For more information, see Authentication strength for external users.

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.
  • More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID.
• 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

Warning

If you use external authentication methods, these are currently incompatible with authentication strength and you should use the Require multifactor authentication grant control.

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Protection > Conditional Access > Policies.
3. Select 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 Directory roles and choose at least the previously listed roles.

      Warning

      Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles.

   2. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.

6. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
7. Under Access controls > Grant, select Grant access.
   1. Select Require authentication strength, then select Phishing-resistant MFA 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.

Related content

• Microsoft Entra built-in roles
• Conditional Access templates
• Configure Microsoft Entra role settings in Privileged Identity Management