What this check looks at
Checks for an enabled Conditional Access policy for all users that requires MFA, signing in again every time, when a sign-in is rated medium or high risk.
Sign-in risk is ID Protection’s judgement that a particular sign-in is not the account owner: an anonymous or malicious IP address, impossible travel, unfamiliar sign-in properties or a password-spray pattern. Asking for MFA at that moment lets the genuine person through in seconds and stops an attacker who has only the password.
The check, for tenants with Entra ID P2, looks for an enabled policy that targets All users and All resources, applies when sign-in risk is Medium or High (both ticked), and either requires MFA with sign-in frequency set to Every time, or blocks access, which is stricter. It warns when such a policy is only in report-only mode and fails when there is none.
Without it, a sign-in Microsoft considers suspicious goes through on whatever the normal policy asks for, which may be nothing on a device with an existing session. Setting sign-in frequency to Every time matters: it forces a fresh MFA prompt for the risky sign-in itself instead of accepting MFA done earlier in the session.
Why it matters
A risky sign-in, from an anonymising network or an impossible location, is often an attacker holding a valid password. Asking for MFA at that moment stops them while the real person passes in seconds.
Password-spray attacks against UK businesses are constant: attackers try a few common passwords against every account from rotating IP addresses. When one works, ID Protection usually rates the sign-in medium or high risk. With this policy the attacker meets an MFA prompt they cannot answer; without it, a tenant that asks for MFA only for some apps or places may let them in.
The cost to staff is an extra MFA prompt when they sign in from somewhere unusual, such as a hotel abroad, which most accept as reasonable. The cost of a successful attack is the usual account-takeover bill: fraud, investigation and a possible report to the ICO.
The CIS Microsoft 365 Foundations Benchmark (5.2.2.7) asks for this policy: all users, all resources, medium and high sign-in risk, MFA and sign-in every time. The rule maps to NIST CSF 2.0 DE.CM-03.
How to fix it
Where: Entra admin centre → Protection → Conditional Access
Before you start
- Needs Entra ID P2.
- 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
- Check people can complete MFA. Everyone covered needs a registered MFA method, or a risky sign-in becomes a lock-out. Check the MFA registration finding first.
- Create the policy and its condition. In the Microsoft Entra admin centre, go to Entra ID > Conditional Access > Policies > New policy, named "CA – All users – Medium and high sign-in risk – MFA". Users: All users, excluding the emergency access group. Target resources: All resources. Conditions > Sign-in risk: Configure Yes, tick High and Medium.
- Set the grant and session, in report-only mode. Under Grant, choose Grant access and tick Require multifactor authentication (or an authentication strength). Under Session, tick Sign-in frequency and choose Every time. Set Enable policy to Report-only and select Create.
- Review the impact. After a week, open ID Protection > Risky sign-ins and the Report-only tab of matching sign-ins in Entra ID > Monitoring & health > Sign-in logs. Note how many genuine people would have been prompted, and whether any could not complete MFA.
- Switch the policy on. Set Enable policy to On and select Save. If the legacy sign-in risk policy inside ID Protection is still on, turn it off so risk is handled in one place.
- Confirm. In ID Protection > Risky sign-ins, recent medium and high-risk sign-ins should show the policy applied, with MFA completed or the sign-in failed. Re-run the assessment to confirm the finding passes.
What users will notice
A sign-in rated medium or high risk (unfamiliar location, anonymous IP address and so on) asks for MFA every time.
How to confirm it worked
Identity Protection, Risky sign-ins: recent risky sign-ins show the policy applied and MFA satisfied; the policy state is On.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | C1.c Generating alertsB2.a Identity verification, authentication and authorisation |
| DSPT | Standard 9: IT protection |
| DORA | Art. 10 Detection of anomalous activities |
| NIS2 | Art. 21(2)(b) Incident handling |
| Microsoft Cloud Security Benchmark | LT-2 Enable threat detection for identity and access management |
| Zero Trust | Identities |
| SOC 2 | CC7.2 Monitoring system components for anomalies |
| NIST SP 800-171 | 3.14.7 Identify unauthorised use of systems |
| CMMC Level 2 | SI.L2-3.14.7 Identify Unauthorized Use |
| ISO 27001:2022 | A.8.16 Monitoring activitiesA.8.5 Secure authentication |
| CIS M365 | 5.2.2.7 Enable Identity Protection sign-in risk policies |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1) |
| NIST CSF 2.0 | DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events |
| NCSC 10 Steps | Identity and access managementLogging and monitoring |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Risk-based policies (Microsoft Learn)