Entra ID Protection: making sign-in risk and user risk work for you
Entra ID Protection continuously estimates how likely it is that a sign-in or an account has been compromised. Many organisations own the required licence without using these signals, or use them with no process to handle the alerts. Both situations are risky.
Two distinct kinds of risk
Sign-in risk relates to a single authentication: is this sign-in likely to be performed by the account owner? It is calculated in real time or offline. User risk relates to the account itself: have its credentials leaked, does its overall behaviour suggest compromise? User risk persists until it is remediated.
Detections
Common detections include anonymous IP address, atypical travel, unfamiliar sign-in properties, password spray, leaked credentials and token anomalies. Some are only available with Entra ID P2; without that licence, visibility is very limited.
AADUserRiskEvents | where TimeGenerated > ago(30d) | summarize Detections = count() by RiskEventType, RiskLevel | sort by Detections desc
Risk-based policies
Risk becomes useful when it triggers an automatic response in Conditional Access. Microsoft now recommends configuring these policies in Conditional Access rather than in the legacy Identity Protection policies. A typical starting point:
- medium or high sign-in risk: require MFA, which remediates the risk if it succeeds;
- high user risk: require a secure password change, preceded by MFA;
- for administrators: stricter thresholds, or even a block.
For passwordless users a password change makes little sense; check the remediation options Microsoft currently offers for that scenario.
Hybrid environments. If passwords are managed in AD, password-change remediation requires password writeback, or the setting that allows an on-premises password change to reset user risk. Without it, users simply stay blocked.
Handling alerts: confirm, dismiss, remediate
Every risky user needs a decision. Administrators can confirm compromise, which raises the risk and feeds the model, dismiss the risk after investigation, or confirm a sign-in as safe. Dismissing in bulk to "clean up" the dashboard erases signals that may well have been genuine.
False positives
Corporate VPNs, security gateways, cloud-hosted virtual desktops and highly mobile users generate legitimate but misleading detections. Rather than excluding users from policies, declare the organisation's internet egress points as trusted named locations and fine-tune thresholds.
In short
Identity Protection only delivers value when three conditions are met: active risk policies in Conditional Access, self-service remediation that actually works (MFA registered, password writeback where needed) and someone responsible for handling the remaining risky users. Without that last point, the dashboard turns into a list of ignored alerts.