How to require phishing-resistant MFA for administrators

What this check looks at

Checks whether privileged accounts are covered by a Conditional Access policy using a phishing-resistant authentication strength, or have registered passwordless methods.

Not all MFA is equal. Text message codes, voice calls, one-time codes and Authenticator push approvals can all be relayed: an adversary-in-the-middle phishing site sits between the user and Microsoft, passes the password and the second factor through, and keeps the session cookie. Phishing-resistant methods (passkeys and FIDO2 security keys, Windows Hello for Business and certificate-based authentication) are bound to the real Microsoft sign-in address, so they do not work on a fake site.

Conditional Access can require these methods through an authentication strength. The check looks at enabled policies using Microsoft’s built-in Phishing-resistant MFA strength, or a custom strength named as phishing-resistant, and works out which administrator roles they cover; a policy for All users covers them all. It passes when every role in its list is covered: Global, Privileged Role, Security, Conditional Access, Exchange, SharePoint, User, Helpdesk, Authentication, Application, Cloud Application and Billing Administrator.

It warns when a phishing-resistant policy covers only some of those roles, or when every administrator already holds a passwordless credential but no policy requires it. It fails when administrators lack phishing-resistant credentials and no policy requires one. A policy using the ordinary Multifactor authentication strength does not count, because that strength accepts codes and push approvals.

Why it matters

SMS and push-approval MFA are defeated by real-time phishing proxies and MFA-fatigue attacks. Administrators are the highest-value target in the tenant and warrant hardware-backed credentials.

Adversary-in-the-middle phishing, sold as a ready-made kit, is now the usual way Microsoft 365 administrator accounts are taken over, because it defeats the MFA most firms rely on. An engineer receives a convincing shared-document or voicemail email, signs in on the fake page, approves the push, and the attacker holds a live administrator session.

With a Global Administrator session the attacker can add their own MFA method, create a new admin account, turn off auditing, grant an app access to every mailbox, or wipe devices through Intune. Ransomware groups use exactly this access to delete data and backups held in the tenant before encrypting systems on-premises. Recovery for a small business can take weeks.

The CIS Microsoft 365 Foundations Benchmark (5.2.2.5) and the CISA SCuBA baseline (MS.AAD.3.6v1) both ask for phishing-resistant MFA for administrator roles, NCSC guidance favours phishing-resistant methods such as FIDO2 for privileged accounts, and Cyber Essentials requires every administrator to use MFA. The rule maps to NIST CSF 2.0 PR.AA-03.

How to fix it

Where: Entra admin centre → Protection → Conditional Access → Authentication strengths

Before you start

• Give each administrator a phishing-resistant method first: a FIDO2 security key, a passkey in Microsoft Authenticator, or Windows Hello for Business.
• Confirm two emergency access (break-glass) accounts exist and exclude them from the policy, so a mistake cannot lock every administrator out.
• Create the policy in report-only mode first and review its results in Entra ID sign-in logs (Conditional Access tab) for at least a week.

Step by step

1. 1List the administrators and their methods. In the Microsoft Entra admin centre, go to Entra ID > Roles & admins and note who holds each of the roles listed above. Then open Entra ID > Authentication methods > User registration details, search for each administrator and check the Methods registered and Passwordless capable columns.
2. 2Enable passkeys and security keys. Go to Entra ID > Authentication methods > Policies, open Passkey (FIDO2), set Enable to Yes and target at least the administrators’ group, leaving self-service set-up allowed. If you want only particular key models, or passkeys in Microsoft Authenticator, set key restrictions under Configure. Windows Hello for Business, if used, is set up through Intune and needs nothing here.
3. 3Give each administrator two phishing-resistant credentials. Each administrator signs in at https://aka.ms/mysecurityinfo, chooses Add sign-in method and adds a passkey: a FIDO2 security key, or a passkey in Microsoft Authenticator on their phone. Two credentials each (for example a key and a phone passkey) mean losing one does not lock them out. Register FIDO2 keys for the emergency access accounts too and store them securely.
4. 4Confirm everyone is ready. Back in User registration details, check every administrator now shows as passwordless capable. Do not enforce the policy until they all do, or the ones without a credential are locked out of admin work.
5. 5Create the policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy, named for example "CA06 – Admins – Phishing-resistant MFA". Under Users, choose Select users and groups > Directory roles and tick every role listed above, plus any other admin role in use; exclude the emergency access group. Under Target resources, include All resources. Under Grant, choose Grant access > Require authentication strength > Phishing-resistant MFA. Set Enable policy to Report-only and select Create.
6. 6Check the effect. Look at the Report-only tab of each administrator’s recent sign-ins in Entra ID > Monitoring & health > Sign-in logs. A sign-in that used a push or a code shows the policy would not have been satisfied; make sure that person has switched to their passkey.
7. 7Switch the policy on. Set Enable policy to On and select Save. Tell administrators that when they sign in with an admin role, only a passkey, security key, Windows Hello or certificate will now be accepted.
8. 8Confirm enforcement. Sign in as an administrator in a private browser window: you should be asked for the passkey or key. In the sign-in log, Authentication details shows the method used and the Conditional Access tab shows the policy as Success. Re-run the assessment to confirm every role is covered.

What users will notice

Administrators must sign in with a security key, passkey or Windows Hello when using admin roles. Push notifications and SMS are no longer accepted for them.

How to confirm it worked

Sign in as an administrator and check the sign-in log shows the "Phishing-resistant MFA" authentication strength satisfied.

Frameworks and controls

This check maps to controls in 18 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

• Conditional Access authentication strength (Microsoft Learn)
• Passwordless deployment (Microsoft Learn)

Related checks

• How to require phishing-resistant MFA for every user
• How to find users without MFA in Microsoft 365
• How to require MFA for every user with Conditional Access
• How to block legacy authentication in Microsoft 365

The full Microsoft 365 security checklist, worst first