Require phishing-resistant MFA for admins with authentication strengths

To require phishing-resistant MFA for administrators, create a Conditional Access policy that includes the privileged directory roles, excludes your emergency access accounts, targets All resources, and uses the grant control Require authentication strength with the built-in Phishing-resistant MFA strength. That strength accepts only passkeys (FIDO2), Windows Hello for Business or platform credential, and multifactor certificate-based authentication. Register those methods for every admin before you turn the policy on, and add an authentication context policy for PIM activation so eligible admins are covered too.

Who this is for and what you will have at the end

This guide is for identity administrators protecting privileged accounts in Microsoft Entra ID, particularly where admins currently satisfy MFA with push notifications, one-time codes or SMS, all of which can be relayed by an adversary-in-the-middle phishing kit.

At the end you will have:

• An understanding of which methods each built-in authentication strength accepts.
• Admins registered for a phishing-resistant method before enforcement.
• Optionally, a custom strength that restricts admins to specific security key models or certificate issuers.
• A Conditional Access policy enforcing the Phishing-resistant MFA strength for privileged roles.
• PIM role activation protected by the same requirement through authentication context.
• A way to confirm in the sign-in logs which strength was enforced.

How authentication strengths work

An authentication strength is a Conditional Access control that lists the combinations of authentication methods a user can use to access a resource. Microsoft provides three built-in strengths that can't be modified and are updated as new methods become available:

"Something the user has" means a text message, voice call, push notification, or software or hardware OATH token.

A few rules shape every design decision:

• Strengths sit on top of the Authentication methods policy. A method must be enabled for the user and registered (before or during the request) to count.
• Evaluation happens after initial authentication. A strength doesn't stop someone typing a password; it requires a phishing-resistant method before they can continue.
• Multiple strengths stack. If two policies apply different strengths, the user must satisfy both, which can mean two methods.
• You can't combine Require multifactor authentication and Require authentication strength in one policy.
• External authentication methods are currently incompatible with authentication strengths. If your admins use one, use Require multifactor authentication instead.

Prerequisites

• License: Microsoft Entra ID P1 for Conditional Access.
• Roles: at least Conditional Access Administrator for the policy, Security Administrator to create custom strengths, Privileged Role Administrator to change PIM role settings.
• Emergency access accounts: your break-glass accounts identified, so you can exclude them from the policy and avoid a lockout caused by misconfiguration.
• Methods enabled: passkeys (FIDO2), Windows Hello for Business, or certificate-based authentication enabled for your admins in the Authentication methods policy.
• Admins registered: every admin holds at least one phishing-resistant method. Microsoft warns that enabling this policy before registration risks locking you out of the tenant.

Step 1: Register phishing-resistant methods first

Some phishing-resistant methods can't be registered during the sign-in interrupt that a strength triggers, so plan registration explicitly:

A Temporary Access Pass is the documented way to bootstrap passwordless registration for an admin who has no strong method yet. If you also enforce a strength on the Register security information user action, note that Microsoft treats strengths on that user action as preferred over strengths on All resources during registration. Microsoft's example pattern uses a "Bootstrap and recovery" custom strength that includes Temporary Access Pass on the registration action, so new users can register with a TAP that works nowhere else.

Before moving on, confirm in each admin's Authentication methods blade that a passkey, Windows Hello for Business or a certificate is present.

Step 2 (optional): Create a custom strength

The built-in strength accepts any FIDO2 key and any multifactor certificate. If you issue specific hardware keys to admins, or use certificates from a dedicated PKI, a custom strength can enforce that. You can create up to 15 custom strengths.

1. Sign in to the Microsoft Entra admin center as at least a Security Administrator.
2. Browse to Entra ID > Authentication methods > Authentication strengths.
3. Select New authentication strength, enter a Name such as Admin phishing-resistant, and an optional Description.
4. Select the allowed methods, for example Passkeys (FIDO2) and Certificate-based authentication (multifactor).
5. To restrict key models, select Passkeys (FIDO2) > Advanced options, then Add AAGUID and enter each Authenticator Attestation GUID you issue.
6. To restrict certificates, select Advanced options under certificate-based authentication and choose certificate issuers, enter issuers by subject key identifier, or enter policy OIDs. You can configure up to five issuers and five OIDs. If you set both, a certificate must match one issuer and one OID.
7. Select Next, review, and Create.

A custom strength referenced by a Conditional Access policy can't be deleted, and edits require confirmation. AAGUID restrictions aren't supported for external users whose home and resource tenants are in different Microsoft clouds.

Step 3: Create the Conditional Access policy for admin roles

Microsoft recommends this requirement for at least these built-in roles:

• 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

Create the policy:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies and select New policy.
3. Name the policy, for example CA-Admins-PhishingResistantMFA.
4. Under Assignments > Users or workload identities:
   • Include: Directory roles, then select at least the roles listed above.
   • Exclude: Users and groups, then your emergency access accounts.
5. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
6. Under Access controls > Grant, select Grant access, then Require authentication strength and choose Phishing-resistant MFA strength (or your custom strength). Select Select.
7. Set Enable policy to Report-only and select Create.

After reviewing policy impact and the report-only results, switch Enable policy to On.

Directory role targeting supports built-in roles only. Roles scoped to an administrative unit and custom roles aren't enforced through this assignment, so if you delegate administration that way, also target those admins through a group.

Step 4: Cover PIM activation with authentication context

A policy scoped to directory roles applies to users who hold the role. With Privileged Identity Management, an eligible admin doesn't hold the role at activation time, so the activation itself isn't covered. PIM's role setting On activation, require Microsoft Entra Conditional Access authentication context closes the gap.

1. In Entra ID > Conditional Access > Authentication context, select New authentication context, give it a display name such as Privileged role activation, and select Publish to apps. You can define up to 99 contexts (c1 to c99).
2. Create a Conditional Access policy that targets that authentication context under Target resources, includes all users or your eligible admins (not a directory role), excludes break-glass accounts, and requires the Phishing-resistant MFA strength. Under Session, set sign-in frequency to Every time so each activation reauthenticates.
3. Turn that policy on before you change PIM. If PIM references a context with no policy, PIM falls back to requiring MFA, but that fallback doesn't trigger if the policy exists but is off, in report-only mode, or excludes the user.
4. In ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles, select each role, then Role settings > Edit, and set On activation, require Microsoft Entra Conditional Access authentication context to your context.

Don't scope one policy to both the authentication context and a directory role; during activation the user has no role, so it wouldn't apply. Microsoft's recommended pattern is two policies: one on the authentication context for activation, and the Step 3 policy on directory roles for use of the activated role. After a reauthentication, a 10-minute window applies across activations, so an admin activating several roles isn't prompted repeatedly.

Anyone who can edit Conditional Access policies can change or remove these activation requirements, so treat Conditional Access Administrator and Security Administrator as highly privileged roles.

Verify the policy

• In Sign-in logs, open an admin sign-in. On Authentication Details, the Requirement column shows the name of the authentication strength. On the Conditional Access tab, select the policy and check Grant Controls for the enforced strength.
• Test with a pilot admin: sign in with a password and push notification, and confirm you're asked for a passkey (or another allowed method) before reaching the admin center.
• Activate a PIM role and confirm the prompt "A Conditional Access policy is enabled and may require additional verification."

Troubleshooting

Checklist

• Passkeys (FIDO2), Windows Hello for Business or CBA enabled for admins in the Authentication methods policy.
• Every admin has a phishing-resistant method registered; TAP used for bootstrap.
• Emergency access accounts excluded from the policy.
• Optional custom strength with AAGUID or certificate restrictions.
• Policy on the recommended directory roles, all resources, Phishing-resistant MFA strength, validated in report-only mode, then on.
• Authentication context policy with sign-in frequency Every time, turned on before PIM role settings reference it.
• PIM roles set to require that authentication context on activation.
• Sign-in logs show the strength under Authentication Details.

Phishing-resistant sign-in protects the authentication step. To stop a token stolen after sign-in from being replayed, add Conditional Access token protection, and for admin workstations consider requiring compliant devices.

References

• Overview of Conditional Access authentication strengths
• How authentication strengths work in a Conditional Access policy
• Create and manage custom Conditional Access authentication strengths
• Troubleshoot Conditional Access authentication strengths
• Require phishing-resistant MFA for Microsoft Entra administrator roles
• Configure Microsoft Entra role settings in PIM
• Targeting resources in Conditional Access policies (authentication context)
• Conditional Access: users, groups, agents and workload identities