What this check looks at
Checks for an enabled Conditional Access policy for all users that, when Identity Protection rates a user as high risk, requires MFA and a secure password change, and signs them in again every time.
User risk is ID Protection’s judgement that an account itself is compromised, for example because its password was found in a leak, it behaved like a known attack, or Microsoft’s threat intelligence tied it to an attacker. When the risk is high, the response that needs no service desk is a secure password change: the person proves themselves with MFA and sets a new password, which clears the risk.
The check, for tenants with Entra ID P2, looks for an enabled policy that targets All users and All resources, applies when user risk is High, grants access only with MFA (or an authentication strength) and a password change, and sets sign-in frequency to Every time. It warns when such a policy exists only in report-only mode and fails when there is none.
Without it, a high-risk user signs in as normal. If the risk is real, the attacker who holds the leaked password, and a way past MFA, keeps using it while the real user carries on unaware. Signing in every time makes the password change happen at the very next sign-in, not whenever a cached session happens to expire.
Why it matters
High user risk means Microsoft believes the account is compromised, for example because its password appeared in a leak. Requiring a secure password change after MFA takes the account back from the attacker without waiting for the service desk.
A member of staff’s Microsoft 365 password turns up in a credential dump after they reused it on a breached site, and ID Protection flags them as high risk overnight. With this policy, at their next sign-in they complete MFA and choose a new password, and the stolen one is worthless before anyone is in the office. Without it, whoever bought the dump has as long as it takes someone to read the risk report.
Self-remediation saves the service desk a call and the user a lock-out, and stops the account takeovers that lead to payment fraud, data theft and a possible report to the ICO under UK GDPR.
The CIS Microsoft 365 Foundations Benchmark (5.2.2.6) asks for exactly this policy: all users, all resources, high user risk, MFA with a password change, 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. Self-service password reset with password writeback (for synchronised accounts) lets users clear the risk themselves.
- 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
- Make sure people can remediate themselves. People need MFA registered and self-service password reset enabled; synchronised accounts also need password writeback so the new password reaches Active Directory. Without these, a high-risk user is simply locked out.
- 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 – High user risk – Password change". Users: All users, excluding the emergency access group. Target resources: All resources. Conditions > User risk: Configure Yes, tick High only.
- Set the grant and session, in report-only mode. Under Grant, choose Grant access, tick Require multifactor authentication (or Require authentication strength) and Require password change, and select Require all the selected controls. Under Session, set Sign-in frequency to Every time; the portal may set this for you when Require password change is ticked. Set Enable policy to Report-only and select Create.
- Check the likely impact. Look at ID Protection > Risky users for people now at high risk; each would be asked to change their password at next sign-in. Confirm or dismiss old risk you have already dealt with, then after a few days check the Report-only tab of matching sign-ins.
- Switch the policy on. Set Enable policy to On and select Save. If the legacy user risk policy inside ID Protection is still on, turn it off so there is one policy to manage.
- Confirm. In ID Protection > Risky users, people who changed their password show the risk as remediated, and their sign-in shows this policy as Success. Re-run the assessment to confirm the finding passes.
What users will notice
A user Identity Protection rates as high risk must do MFA and change their password at their next sign-in. Other users see nothing.
How to confirm it worked
Entra admin centre, Protection, Identity Protection, Risky users: users who changed their password show the risk as remediated, and the policy shows "Success" in their sign-in log.
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.5.17 Authentication information |
| CIS M365 | 5.2.2.6 Enable Identity Protection user 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)