What this check looks at
Counts users flagged at risk by Identity Protection whose risk has not been remediated or dismissed.
Microsoft Entra ID Protection scores every user for the likelihood that the account is compromised, from detections such as leaked credentials found online, sign-ins from anonymous or malicious IP addresses, atypical travel, password spray, unfamiliar sign-in properties and anomalous tokens. A user stays at risk until someone remediates the risk (a secure password change or an administrator’s reset) or dismisses it. Without a user-risk policy nothing happens automatically: the account keeps working and the flag sits in the Risky users report.
The check fails, as critical, when any user is flagged at high risk and has not been signed out everywhere since the risk was last raised, because any session an attacker stole is still valid. It warns when the only high-risk users have been signed out since (the stolen session has ended, but the password may still be known), and warns when users are flagged only at medium or low risk. The evidence lists the accounts, their risk level and state, and whether each has been signed out since.
An attacker holding a valid session or refresh token does not need the password again: the token keeps the session alive for weeks unless it is revoked. In a typical business email compromise the attacker reads the mailbox quietly, adds an inbox rule that hides replies from a supplier or the bank, and waits for an invoice to intercept. A high-risk flag left for days is exactly the window they need.
Why it matters
Each unremediated risky user is an account Microsoft believes may already be compromised. Left alone, the attacker keeps the session; the alert ages while the mailbox is read.
Picture a 60-person firm whose finance manager’s password appears in a leaked credential set. Identity Protection raises her to high risk, nobody looks, and a week later the attacker signs in from a hosting provider, sets up a rule moving anything from the firm’s main supplier into the RSS Feeds folder, and sends the accounts team new bank details for this month’s invoice. A £40,000 payment goes to a mule account, and by the time the supplier chases, the money has moved on.
Beyond the loss, a compromised mailbox almost always holds personal data. Under UK GDPR the organisation must decide quickly whether to report the breach to the ICO, within 72 hours of becoming aware of it where there is a risk to individuals, and without knowing what the attacker opened the safe assumption is that they read everything. Investigation, legal advice and notifying customers often cost more than the fraud itself.
Responding to detected compromise is a core expectation of every framework this check maps to: NIST CSF 2.0 RS.MA-01 and RS.MA-02 (incidents managed, reports triaged), ISO 27001 A.5.26 (response to information security incidents) and A.8.16 (monitoring activities), and NCSC CAF C1.d (identifying security incidents) and D1.b (response and recovery capability). The NCSC’s 10 Steps puts incident management alongside identity and access management for the same reason.
How to fix it
Where: Entra admin centre → Protection → Identity Protection → Risky users
Before you start
- Look at each user’s risk detections to decide whether it is a real compromise or a false positive (travel, VPN).
Step by step
- Open the Risky users report. In the Microsoft Entra admin centre, go to ID Protection > Risky users (Protection > Identity Protection > Risky users in older menus). Filter Risk state to At risk and sort by Risk level so the high-risk users from the finding are at the top. Acting on risk needs at least the Security Operator role.
- Review each user’s detections and sign-ins. Select a user and read the Risk history and the recent risky sign-ins: the detection type (leaked credentials, anomalous token, unfamiliar sign-in properties, password spray, malicious IP address), time, IP address, location and device. Open the same sign-ins in Entra ID > Monitoring & health > Sign-in logs and compare them with where the person actually works and the devices they use; ask them if in doubt.
- Contain a likely compromise straight away. If anything points to an attacker (a sign-in the person does not recognise, an anomalous token, a leaked password still in use), select Confirm user compromised. Open the user under Entra ID > Users, select Revoke sessions to invalidate every refresh token, and reset the password (for an account synced from Active Directory, reset it on-premises and let it sync). Check Authentication methods on the user and delete any method the person did not register.
- Check the mailbox for what the attacker left. In Exchange Online PowerShell run Get-InboxRule -Mailbox user@contoso.com -IncludeHidden | Format-List Name, Enabled, MoveToFolder, DeleteMessage, ForwardTo, RedirectTo, ForwardAsAttachmentTo and remove any rule the person did not create with Remove-InboxRule. Check Get-Mailbox user@contoso.com | Format-List ForwardingSmtpAddress, DeliverToMailboxAndForward, review Sent Items, and look at the user’s app consents (Entra ID > Users > the user > Applications) for anything new.
- Dismiss the explained detections. Where a detection has an innocent explanation (travel, a new phone, a VPN exit in another country), select Dismiss user risk and record the reason in your ticket, as the portal keeps no note. If the same office or VPN address keeps triggering detections, add it as a trusted named location in Conditional Access, which Identity Protection takes into account.
- Make future risk remediate itself. Where the tenant has Microsoft Entra ID P2 (Microsoft 365 E5 or the add-on), create a Conditional Access policy in report-only mode for all users, excluding the emergency access accounts, with the condition User risk: High and the grant Require password change (shown as Require risk remediation in newer tenants), then turn it on after a week. For accounts synced from Active Directory, also turn on Allow on-premises password change to reset user risk in ID Protection > Settings, where available.
- Confirm nobody is left at risk. Back in ID Protection > Risky users, filter Risk state to At risk: the list should be empty, with each user now Remediated or Dismissed. The next assessment passes when no user is flagged at risk, and fails again if a high-risk user appears and is not signed out.
What users will notice
Users confirmed as compromised have their password reset and are signed out everywhere.
How to confirm it worked
Identity Protection, Risky users: none remain "At risk"; each is Remediated or Dismissed with a reason.
Frameworks and controls
This check maps to controls in 12 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | D1.b Response and recovery capabilityC1.d Identifying security incidents |
| DSPT | Standard 6: Responding to incidents |
| DORA | Art. 17 ICT-related incident management process |
| NIS2 | Art. 21(2)(b) Incident handling |
| Microsoft Cloud Security Benchmark | IR-3 Detection and analysis: create incidents based on high-quality alertsLT-2 Enable threat detection for identity and access management |
| Zero Trust | Identities |
| SOC 2 | CC7.4 Responding to security incidents |
| NIST SP 800-171 | 3.6.1 Establish an operational incident-handling capability |
| CMMC Level 2 | IR.L2-3.6.1 Incident Handling |
| ISO 27001:2022 | A.5.26 Response to information security incidentsA.8.16 Monitoring activities |
| NIST CSF 2.0 | RS.MA-01: The incident response plan is executed in coordination with relevant third parties once an incident is declaredRS.MA-02: Incident reports are triaged and validatedDE.AE-02: Potentially adverse events are analyzed to better understand associated activities |
| NCSC 10 Steps | Incident management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Remediate risks (Microsoft Learn)