Standard MFA stops most password attacks, but it does not stop an attacker who proxies the whole sign-in page and steals the session cookie. That is why Microsoft now recommends phishing-resistant methods for anyone with admin rights. A Conditional Access authentication strength is the control that enforces it: instead of asking for “any MFA”, it asks for specific methods that cannot be relayed through a fake login page.
Why ordinary MFA is no longer enough for admins
Push notifications, SMS codes and one-time passcodes all share a weakness. The user types or approves something, and nothing ties that approval to the real Microsoft sign-in page. Adversary-in-the-middle phishing kits sit between the user and Microsoft, pass the MFA prompt through, and capture the resulting session. The user sees a normal sign-in. The attacker gets a working token.
For a regular user, that is serious. For a Global Administrator, Exchange Administrator or Conditional Access Administrator, it can mean the whole tenant. Admin accounts are the accounts where the extra effort of phishing-resistant authentication clearly pays off.
Phishing-resistant methods work differently. FIDO2 passkeys, Windows Hello for Business and certificate-based authentication all use a cryptographic exchange bound to the real sign-in origin. A fake page on a different domain cannot complete it, so there is nothing useful to relay.
What authentication strengths are
Authentication strength is a grant control in Conditional Access. Rather than the older “Require multifactor authentication” checkbox, you choose a named set of allowed method combinations. Microsoft Entra ID includes three built-in strengths:
Built-in strength
What it allows
Typical use
Multifactor authentication strength
Any combination that satisfies MFA, including password plus push, SMS, voice or OATH codes
Baseline for all users
Passwordless MFA strength
FIDO2 security key, Windows Hello for Business or platform credential, certificate-based authentication (multifactor), Microsoft Authenticator phone sign-in
Users moving off passwords
Phishing-resistant MFA strength
FIDO2 security key or passkey, Windows Hello for Business or platform credential, certificate-based authentication (multifactor)
Administrators and high-risk access
You can also build a custom authentication strength if you need something specific, for example allowing only FIDO2 keys with particular hardware models. For most small and mid-sized businesses, the built-in Phishing-resistant MFA strength is the right choice for admins.
Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and E3/E5.
Before you enforce: get admins registered
The fastest way to lock out your own IT team is to turn on a phishing-resistant requirement before anyone has a phishing-resistant method. Do the groundwork first.
Enable the methods. In Entra ID > Authentication methods > Policies, enable Passkey (FIDO2) for your admin group. If your admins use Windows devices joined to Entra ID, plan Windows Hello for Business as well.
Issue hardware. Give each admin at least two FIDO2 security keys, or one key plus a device-bound passkey, so a lost key is not a lockout.
Use a Temporary Access Pass for bootstrapping. A TAP lets an admin sign in once to register their new key without relying on the old method.
Confirm registration. Check Authentication methods > User registration details and filter on your admin accounts. Every admin should show a passkey or Windows Hello registration.
Review your emergency access accounts. Break-glass accounts should already use a phishing-resistant method of their own and be excluded from the policy you are about to build.
Building the Conditional Access policy
Microsoft publishes a template for this policy, and the manual steps are short.
Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
Go to Entra ID > Conditional Access > Policies and select New policy.
Name it clearly, for example CA-Admins-RequirePhishingResistantMFA.
Under Users, include Directory roles and select your privileged roles: Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Helpdesk Administrator, Billing Administrator, Application Administrator, Authentication Administrator and any others your team uses.
Under Exclude, select your emergency access accounts.
Under Target resources, include All resources.
Under Grant, choose Require authentication strength and select Phishing-resistant MFA strength.
Set the policy to Report-only, create it, and review the results in the sign-in logs for a week before switching it to On.
Conditional Access policies that target directory roles apply to built-in roles. They are not enforced for administrative unit-scoped assignments or custom roles. If you use either, add those admins through a group as well.
Eligible roles in PIM
If you use Privileged Identity Management, admins with eligible (not active) roles may not be matched by a role-based policy until they activate. The cleanest approach is to target a dedicated admin group, or to require the authentication strength on role activation itself using an authentication context.
Separate admin accounts
Admins should use a dedicated, cloud-only admin account that is separate from their daily mailbox account. This keeps phishing-resistant requirements on the privileged identity without disrupting their normal email and Teams use.
You cannot combine both MFA grant controls
“Require multifactor authentication” and “Require authentication strength” cannot sit in the same policy. Use one or the other. Existing all-user MFA policies can stay as they are, because the admin policy adds the stricter requirement on top.
External authentication methods are not compatible
If you use an external authentication method provider, it currently cannot satisfy authentication strengths. Use the standard MFA grant control for those users.
Extending phishing-resistant MFA beyond admins
Once admins are done, the same building block can protect other high-value access. Common next steps include requiring phishing-resistant MFA for finance staff who approve payments, for access to Azure management, or for high-risk sign-ins detected by Microsoft Entra ID Protection (Entra ID P2). Passkeys in Microsoft Authenticator have made this far easier for ordinary users than it was a few years ago, because the phone becomes the phishing-resistant credential.
A sensible rollout order is: admins first, then the people who can move money or export sensitive data, then everyone else as devices and passkeys allow. At each stage, run the policy in report-only mode, check the sign-in logs for users who would have been blocked, and help them register before you enforce. Keep the all-user MFA policy in place throughout, so nobody is ever left with weaker protection while you work through the groups.
If you are still getting baseline MFA in place, start with our MFA enablement service. For a full review of your Conditional Access design, the Microsoft 365 security assessment covers policy gaps, exclusions and break-glass setup. You can also compare license tiers with our E5 vs E3 calculator.
Frequently asked questions
Does Microsoft Authenticator push count as phishing-resistant?
No. Authenticator push notifications, even with number matching, satisfy the standard MFA strength but not the Phishing-resistant MFA strength. A passkey stored in Microsoft Authenticator does count, because it uses the FIDO2 standard.
What license do I need for authentication strengths?
Authentication strengths are part of Conditional Access, which requires Microsoft Entra ID P1. Microsoft 365 Business Premium, E3 and E5 all include it. Risk-based conditions require Entra ID P2.
What happens if an admin loses their only security key?
They will be blocked from admin portals until they register a new phishing-resistant method. Another admin can issue a Temporary Access Pass so they can register a replacement. This is why every admin should have two registered methods.
Want your admin accounts protected with phishing-resistant MFA without locking anyone out? Request a free Microsoft 365 security assessment and we will review your Conditional Access policies and admin registrations.
Standard MFA stops most password attacks, but it does not stop an attacker who proxies the whole sign-in page and steals the session cookie. That is why Microsoft now recommends phishing-resistant methods for anyone with admin rights. A Conditional Access authentication strength is the control that enforces it: instead of asking for “any MFA”, it asks for specific methods that cannot be relayed through a fake login page.
Why ordinary MFA is no longer enough for admins
Push notifications, SMS codes and one-time passcodes all share a weakness. The user types or approves something, and nothing ties that approval to the real Microsoft sign-in page. Adversary-in-the-middle phishing kits sit between the user and Microsoft, pass the MFA prompt through, and capture the resulting session. The user sees a normal sign-in. The attacker gets a working token.
For a regular user, that is serious. For a Global Administrator, Exchange Administrator or Conditional Access Administrator, it can mean the whole tenant. Admin accounts are the accounts where the extra effort of phishing-resistant authentication clearly pays off.
Phishing-resistant methods work differently. FIDO2 passkeys, Windows Hello for Business and certificate-based authentication all use a cryptographic exchange bound to the real sign-in origin. A fake page on a different domain cannot complete it, so there is nothing useful to relay.
What authentication strengths are
Authentication strength is a grant control in Conditional Access. Rather than the older “Require multifactor authentication” checkbox, you choose a named set of allowed method combinations. Microsoft Entra ID includes three built-in strengths:
You can also build a custom authentication strength if you need something specific, for example allowing only FIDO2 keys with particular hardware models. For most small and mid-sized businesses, the built-in Phishing-resistant MFA strength is the right choice for admins.
Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and E3/E5.
Before you enforce: get admins registered
The fastest way to lock out your own IT team is to turn on a phishing-resistant requirement before anyone has a phishing-resistant method. Do the groundwork first.
Entra ID > Authentication methods > Policies, enable Passkey (FIDO2) for your admin group. If your admins use Windows devices joined to Entra ID, plan Windows Hello for Business as well.Authentication methods > User registration detailsand filter on your admin accounts. Every admin should show a passkey or Windows Hello registration.Building the Conditional Access policy
Microsoft publishes a template for this policy, and the manual steps are short.
Entra ID > Conditional Access > Policiesand select New policy.Microsoft’s walkthrough for this exact policy is in Require phishing-resistant multifactor authentication for administrators.
Gotchas I see in real deployments
Role-based targeting only covers built-in roles
Conditional Access policies that target directory roles apply to built-in roles. They are not enforced for administrative unit-scoped assignments or custom roles. If you use either, add those admins through a group as well.
Eligible roles in PIM
If you use Privileged Identity Management, admins with eligible (not active) roles may not be matched by a role-based policy until they activate. The cleanest approach is to target a dedicated admin group, or to require the authentication strength on role activation itself using an authentication context.
Separate admin accounts
Admins should use a dedicated, cloud-only admin account that is separate from their daily mailbox account. This keeps phishing-resistant requirements on the privileged identity without disrupting their normal email and Teams use.
You cannot combine both MFA grant controls
“Require multifactor authentication” and “Require authentication strength” cannot sit in the same policy. Use one or the other. Existing all-user MFA policies can stay as they are, because the admin policy adds the stricter requirement on top.
External authentication methods are not compatible
If you use an external authentication method provider, it currently cannot satisfy authentication strengths. Use the standard MFA grant control for those users.
Extending phishing-resistant MFA beyond admins
Once admins are done, the same building block can protect other high-value access. Common next steps include requiring phishing-resistant MFA for finance staff who approve payments, for access to Azure management, or for high-risk sign-ins detected by Microsoft Entra ID Protection (Entra ID P2). Passkeys in Microsoft Authenticator have made this far easier for ordinary users than it was a few years ago, because the phone becomes the phishing-resistant credential.
A sensible rollout order is: admins first, then the people who can move money or export sensitive data, then everyone else as devices and passkeys allow. At each stage, run the policy in report-only mode, check the sign-in logs for users who would have been blocked, and help them register before you enforce. Keep the all-user MFA policy in place throughout, so nobody is ever left with weaker protection while you work through the groups.
If you are still getting baseline MFA in place, start with our MFA enablement service. For a full review of your Conditional Access design, the Microsoft 365 security assessment covers policy gaps, exclusions and break-glass setup. You can also compare license tiers with our E5 vs E3 calculator.
Frequently asked questions
Does Microsoft Authenticator push count as phishing-resistant?
No. Authenticator push notifications, even with number matching, satisfy the standard MFA strength but not the Phishing-resistant MFA strength. A passkey stored in Microsoft Authenticator does count, because it uses the FIDO2 standard.
What license do I need for authentication strengths?
Authentication strengths are part of Conditional Access, which requires Microsoft Entra ID P1. Microsoft 365 Business Premium, E3 and E5 all include it. Risk-based conditions require Entra ID P2.
What happens if an admin loses their only security key?
They will be blocked from admin portals until they register a new phishing-resistant method. Another admin can issue a Temporary Access Pass so they can register a replacement. This is why every admin should have two registered methods.
Want your admin accounts protected with phishing-resistant MFA without locking anyone out? Request a free Microsoft 365 security assessment and we will review your Conditional Access policies and admin registrations.