What this check looks at
Checks for Conditional Access policies that act on user risk and sign-in risk, where the tenant is licensed for Entra ID P2.
Microsoft Entra ID Protection scores every sign-in and every user for risk. Sign-in risk is the chance that this sign-in is not the account owner: an anonymising network, impossible travel, infrastructure linked to attacks, a token replayed from elsewhere. User risk is the chance the account itself is compromised, for example because its password appeared in a leak. With Entra ID P2 the detections happen anyway, but nothing acts on them unless a Conditional Access policy uses the risk level as a condition.
The check, which applies only to tenants with Entra ID P2, passes when an enabled policy answers high user risk by blocking or by requiring a password change, and an enabled policy blocks high-risk sign-ins. It warns when risk policies exist but leave a gap: user risk not answered by a block or password change, or high sign-in risk answered only with MFA, which a phishing kit that relays MFA passes straight through. It fails when no enabled policy uses user or sign-in risk at all.
Without these policies, ID Protection fills a report with high-risk events that nobody reads in time. The attacker who signed in from an anonymising network, or whose stolen password was confirmed in a breach list, keeps the access until a person notices.
Why it matters
Risk policies are the only control that reacts to a compromise already in progress — a sign-in from an anonymous IP, from two countries at once, or with credentials found in a breach dump. Without them, detection exists but nothing acts on it.
A realistic case: a director’s password and MFA approval are captured by a phishing kit. ID Protection rates the sign-in high risk because it comes from infrastructure linked to attacks, but no policy acts on it and the session is accepted. Within the hour, an inbox rule is forwarding invoices to an outside address. A policy blocking high-risk sign-ins would have stopped the sign-in, and a user-risk policy would have forced a secure password change once the account was flagged.
In a tenant already paying for Entra ID P2 (Microsoft 365 E5, E5 Security or the P2 add-on), these policies cost nothing more, and they act in seconds, out of hours, with nobody watching. Not using them leaves the full cost of an account takeover: lost payments, incident response and a possible report to the ICO under UK GDPR.
The CISA SCuBA baseline asks for high-risk users and high-risk sign-ins to be blocked (MS.AAD.2.1v1 and MS.AAD.2.3v1), the CIS Microsoft 365 Foundations Benchmark asks for user-risk and sign-in-risk Conditional Access policies, and the rule maps to NIST CSF 2.0 DE.CM-01.
How to fix it
Where: Entra admin centre → Protection → Conditional Access
Before you start
- Confirm the tenant has Entra ID P2 (E5, or the Entra ID P2 add-on); risk policies need it.
- Make sure users can self-remediate: MFA registered for sign-in risk, and password reset (SSPR) for user risk.
- 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 the licence and that people can clear their own risk. Confirm the tenant holds Microsoft Entra ID P2. People must be registered for MFA to pass a risk prompt and for self-service password reset to change their password; synchronised accounts also need password writeback. The MFA and SSPR registration findings cover both.
- Clear the existing risk backlog. In the Microsoft Entra admin centre, go to ID Protection > Risky users and Risky sign-ins. Confirm compromised or dismiss the old entries you have already dealt with, so the new policies do not catch stale events, and note how many genuine people appear, to judge the impact.
- Create the user-risk policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy, named "CA07a – All users – High user risk – Password change". Users: All users, excluding the emergency access group. Target resources: All resources. Conditions > User risk: Configure Yes, tick High. Grant: Grant access, tick Require multifactor authentication (or an authentication strength) and Require password change, with Require all the selected controls. Session: Sign-in frequency, Every time. Enable policy: Report-only.
- Create the sign-in-risk policy in report-only mode. Create a second policy, "CA07b – All users – High sign-in risk – Block". Users: All users, excluding the emergency access group. Target resources: All resources. Conditions > Sign-in risk: Configure Yes, tick High (and Medium too if you also want to meet the stricter blocking finding). Grant: Block access. Enable policy: Report-only. A policy that only asks for MFA on high sign-in risk does not satisfy this check.
- Review what they would have done. After a week or two, open the matching sign-ins in Entra ID > Monitoring & health > Sign-in logs and check each policy’s result on the Report-only tab. Count the genuine people who would have been blocked or asked to change their password, and warn any who travel or use consumer VPNs.
- Switch both policies on. Set Enable policy to On for both and select Save. Brief the service desk: a person blocked by sign-in risk must be verified, and the sign-in confirmed safe in ID Protection > Risky sign-ins if it was really theirs; a person asked to change their password does it themselves.
- Turn off the legacy risk policies. If the older user risk and sign-in risk policies inside ID Protection are still on, turn them off once the Conditional Access policies are enforcing, so risk is managed in one place. Microsoft is retiring those legacy policies in favour of Conditional Access.
- Confirm the policies act. In ID Protection > Risky sign-ins and Risky users, new high-risk entries should show as blocked or remediated rather than left at risk. Re-run the assessment to confirm the finding passes.
What users will notice
Risky sign-ins trigger an MFA prompt or are blocked; users flagged as high risk are asked to change their password. Most users never notice.
How to confirm it worked
In Entra ID, Protection, Identity Protection, Risky sign-ins: recent high-risk sign-ins should show "Remediated" or "Blocked" rather than "At risk".
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 | C1.c Generating alerts |
| 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 |
| Secure Score | Turn on sign-in risk policyTurn on user risk policy |
| 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 activities |
| CISA SCuBA | MS.AAD.2.1v1 Users detected as high risk blockedMS.AAD.2.3v1 Sign-ins detected as high risk blocked |
| CIS M365 | 5.2.2.6 Enable Identity Protection user risk policies5.2.2.7 Enable Identity Protection sign-in risk policies5.2.2.8 Ensure 'sign-in risk' is blocked for medium and high risk |
| NIST CSF 2.0 | DE.CM-01: Networks and network services are monitored to find potentially adverse events |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Configure risk policies (Microsoft Learn)