What this check looks at
Checks for a Conditional Access policy requiring phishing-resistant MFA (passkeys, Windows Hello for Business or security keys) for all users.
Phishing-resistant MFA means methods bound cryptographically to the genuine sign-in page: passkeys (FIDO2 security keys or passkeys in Microsoft Authenticator), Windows Hello for Business and certificate-based authentication. A fake page cannot relay them, because the credential will not sign for a site it was not registered with. Conditional Access can require them through the built-in authentication strength Phishing-resistant MFA; by default Microsoft Entra ID accepts any MFA method.
This check applies where the tenant has Conditional Access (Entra ID P1). It looks for a policy that targets all users and requires the Phishing-resistant MFA authentication strength, and passes when such a policy is On. This check only warns, never fails: it raises a warning when the policy is missing or only in report-only mode, because most organisations reach this target in stages, administrators first.
Adversary-in-the-middle phishing kits, sold as a service, sit between the user and the real Microsoft sign-in page: they pass the password and the Authenticator approval or code through in real time and capture the session cookie at the end. Number matching and app context do not stop this, because the user really is signing in. Only phishing-resistant methods, or a compliant-device requirement, break it.
Why it matters
Codes and push approvals stop most attacks, but phishing kits that sit between the person and Microsoft relay them in real time. Phishing-resistant methods are bound to the real sign-in page and cannot be relayed. It is the target state the CISA baselines set for every account.
Business email compromise in UK small businesses commonly starts this way: a shared-document email leads to a convincing Microsoft sign-in page, the user approves MFA as normal, and the attacker’s proxy takes the session. Within an hour inbox rules are set up and the attacker is replying to supplier threads with new bank details. With phishing-resistant MFA the stolen password and approval are useless.
It is the largest change in this area: everyone needs a passkey, Windows Hello or a security key, and some older apps and devices need checking. Once in place it closes the most common route to account takeover, and passkeys are quicker for users than codes.
CISA SCuBA MS.AAD.3.1 asks for phishing-resistant MFA to be enforced for all users. CIS Controls v8 safeguards 6.3 and 6.5, ISO 27001 A.8.5, the NCSC CAF identity verification and authentication outcome and NIST CSF PR.AA-03 support it, and the NCSC recommends phishing-resistant methods wherever they are available.
How to fix it
Where: Entra admin centre → Protection → Conditional Access → Authentication strengths
Before you start
- Enable passkeys in Microsoft Authenticator and Windows Hello for Business; plan security keys for people without a suitable phone or laptop.
- Roll out in groups, starting with administrators and finance, and watch the report-only results.
- 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
- Enable passkeys. In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > Policies > Passkey (FIDO2), set Enable to on and target All users. On the Configure tab allow self-service set-up and, if you restrict which keys can be used, make sure the Microsoft Authenticator passkey AAGUIDs are on the allowed list. Save.
- Turn on Windows Hello for Business. In the Microsoft Intune admin centre, configure Windows Hello for Business for Entra joined devices (Devices > Enrolment > Windows > Windows Hello for Business, or an account protection policy under Endpoint security). For hybrid joined devices, set up cloud Kerberos trust first.
- Issue security keys where phones are not an option. Buy FIDO2 security keys for people who cannot use a work or personal phone and for shared or restricted environments, and register them with a Temporary Access Pass at https://aka.ms/mysecurityinfo.
- Run the registration team by team. Ask users, group by group, to add a passkey in Microsoft Authenticator (https://aka.ms/mysecurityinfo > Add sign-in method > Passkey) or set up Windows Hello on their laptop. Track progress in Entra ID > Authentication methods > User registration details, filtering on passkey or passwordless capable.
- Create the all-users policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy and name it "Require phishing-resistant MFA - all users". Under Users, include All users and exclude the emergency access accounts, All guest and external users (cover guests with a separate MFA policy) and any service accounts. Target All resources. Under Grant choose Require authentication strength: Phishing-resistant MFA. Set Enable policy to Report-only and Create.
- Enforce in stages. Create a copy of the policy scoped to administrators and finance and switch that On first, then widen the groups as each team finishes registering. Use the all-users policy’s report-only results (Sign-in logs, Report-only tab, Report-only: Failure) to find who is not ready.
- Switch the all-users policy on. When the report-only results show no failures for people who should be included, set the all-users policy to On and delete the staged copies.
- Confirm phishing-resistant sign-in is required. Sign in as a test user who has only Authenticator push: access should be refused with a request for a stronger method. Normal users’ sign-in logs should show the authentication strength satisfied with a passkey or Windows Hello. The finding clears at the next assessment.
What users will notice
Once enforced, everyone signs in with a passkey, Windows Hello or a security key; codes and push approvals stop being accepted.
How to confirm it worked
The policy’s report-only results show no sign-ins that would fail before it is switched on; afterwards, sign-in logs show the authentication strength satisfied.
Frameworks and controls
This check maps to controls in 15 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.a Identity verification, authentication and authorisation |
| DSPT | Standard 4: Managing data access |
| DORA | Art. 9(4)(d) Strong authentication mechanisms |
| NIS2 | Art. 21(2)(j) Multi-factor authentication and secured communications |
| Microsoft Cloud Security Benchmark | IM-6 Use strong authentication controls |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 8.4.2 MFA for all access into the CDE |
| NIST SP 800-171 | 3.5.3 Use multi-factor authentication |
| CMMC Level 2 | IA.L2-3.5.3 Multifactor Authentication |
| ISO 27001:2022 | A.8.5 Secure authentication |
| CISA SCuBA | MS.AAD.3.1v1 Phishing-resistant MFA enforced for all users |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1)6.5 Require MFA for administrative access (IG1) |
| NIST CSF 2.0 | PR.AA-03: Users, services, and hardware are authenticated |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Plan a phishing-resistant passwordless deployment (Microsoft Learn)