ID Protection is brilliant when it's tuned and infuriating when it isn't: users locked out after a hotel VPN, a risky-users list nobody clears, and a security team unsure whether "Unfamiliar sign-in properties" means compromise or a new laptop. In this post I'll explain how risk is calculated, how to build the risk-based Conditional Access policies Microsoft recommends, and how to work the three reports so real compromise gets handled and false positives stop hurting people.
Symptoms#
- Users are blocked or forced through MFA and a password change after travelling, switching VPN or getting a new device.
- The Risky users report keeps growing because nothing remediates or dismisses risk.
- Sign-ins fail with
AADSTS50053and the reason "Sign-in was blocked by built-in protections due to high confidence of risk". - Hybrid users can't complete the password change ID Protection asks for.
- Tenants on Entra ID P1 or Free see detections called Additional risk detected with no details.
Why it happens#
ID Protection scores two things. Sign-in risk is the probability that a specific authentication wasn't performed by the account owner. User risk is the probability that the identity itself is compromised, aggregated from risky sign-ins and user-level detections such as leaked credentials. Both come as low, medium or high, and show hidden when the tenant isn't licensed for the detail. Detections are real-time, available during the sign-in so Conditional Access can act, or offline, calculated afterwards and affecting user risk and later sign-ins.
A few documented detections you'll meet constantly:
| Detection | Type | Why it's often benign |
|---|---|---|
| Unfamiliar sign-in properties | Sign-in, real-time | Compares IP, ASN, location, device, browser and tenant IP subnet with the user's history. New users sit in a learning mode of at least five days; legacy authentication has few properties, so it's noisier. |
| Atypical travel | Sign-in, offline | Two distant sign-ins too close together. It learns for 14 days or 10 sign-ins and ignores known VPNs and colleagues' locations, but a new VPN egress still trips it. |
| Anonymous IP address | Sign-in, real-time | Tor or anonymising VPNs, which privacy-conscious users trigger legitimately. |
| Anomalous token | Sign-in or user | Unusual token lifetime or replay from an unfamiliar location. Microsoft documents a higher than normal false-positive rate at low and medium levels. |
| Leaked credentials | User, offline | Rarely a false positive: it fires only when leaked material matches the user's current password hash. |
The policy side matters just as much. Blocking on risk strands legitimate users, and the legacy risk policies in the ID Protection blade were documented for retirement on 1 October 2026. The supported approach is risk-based Conditional Access that lets users self-remediate.
How to fix it#
1. Build the two Conditional Access policies#
You need the Conditional Access Administrator role and Entra ID P2 (or Microsoft Entra Suite). Keep user risk and sign-in risk in separate policies; Microsoft explicitly warns against combining them. Under Entra ID › Conditional Access › New policy:
- User risk policy: include all users, exclude break-glass accounts and sync service accounts; target All resources; under Conditions › User risk select High; under Grant choose Require risk remediation. That control automatically adds Require authentication strength and the Sign-in frequency: Every time session control. Users with passwords get MFA followed by a secure password change; passwordless users have their sessions revoked and reauthenticate.
- Sign-in risk policy: same assignments; Conditions › Sign-in risk set to High and Medium; grant Require authentication strength with the built-in Multifactor authentication strength (or Passwordless MFA / Phishing-resistant MFA for passwordless users); session control Sign-in frequency: Every time.
- Create both in Report-only, review the Report-only tab in the sign-in logs for a week, then switch to On. If the legacy policies are still visible under ID Protection › Dashboard, set them to Disabled afterwards.
2. Make self-remediation possible#
- Users must already be registered for MFA; unregistered users are blocked and need an admin.
- Hybrid users need password writeback for the cloud flow, or password hash synchronization plus the Allow on-premises password change to reset user risk setting under Protection › Identity Protection › Settings if they'll change the password on a domain-joined device.
- Only the policy-driven flow counts. A user changing their password on their own, or an SSPR reset, remediates user risk differently; a plain "I know my password" change outside the flow doesn't satisfy the secure password change requirement.
3. Investigate from the three reports#
Under Protection › Identity Protection, Risky users gives the aggregated level, risk state and risk history; Risky sign-ins shows each flagged authentication with its detections, device and Conditional Access results; Risk detections lists every detection with its type and timing. Then ask the documented questions: is the app normal for this user, is the device registered or compliant, does the IP or ASN belong to a known VPN, does the user confirm the sign-in through a channel that isn't the possibly compromised mailbox? Security Reader or Global Reader can view, Security Operator can act, User Administrator resets passwords.
4. Close the false positives properly#
- Confirm sign-in safe or Dismiss user risk when the investigation is clean; the risk state becomes Confirmed safe or Dismissed. Dismissing doesn't change the password, so tell the user if there's any doubt.
- Add corporate VPN and office ranges as trusted named locations. ID Protection uses trusted locations to reduce false positives in some detections, and that's Microsoft's own advice for a sanctioned VPN flagged as atypical travel.
- Move the last legacy authentication clients to modern authentication.
- Don't dismiss token-theft detections (Anomalous token, Token issuer anomaly, Attacker in the Middle, Verified threat actor IP, Entra threat intelligence) on a hunch. Microsoft no longer auto-remediates these when an MFA claim is present; the user must complete the password change and reauthenticate.
5. Unblock a user hit by the high-confidence block#
The 50053 built-in block mostly hits legacy protocols and clearly malicious patterns. Have the user sign in from a familiar device or location, add the IP to trusted locations if it's genuinely yours, or switch the client to modern authentication. If your own policy is the problem, exclude the user temporarily or disable it, then dismiss the risk so they can sign in.
6. Script the clean-up#
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All","IdentityRiskyUser.ReadWrite.All"
# What is firing, and for whom?
Get-MgRiskDetection -Filter "RiskType eq 'unfamiliarFeatures'" |
Format-Table UserDisplayName, RiskLevel, RiskState, DetectedDateTime
# High-risk users untouched for 90+ days, then bulk dismiss after review
$stale = Get-MgRiskyUser -Filter "RiskLevel eq 'high'" |
Where-Object RiskLastUpdatedDateTime -lt (Get-Date).AddDays(-90)
Invoke-MgDismissRiskyUser -UserIds $stale.Id
# Confirmed compromise raises the user to high risk
Confirm-MgRiskyUserCompromised -UserIds "<user object id>"Verify the fix#
- Trigger a risky sign-in from a Tor browser with a test account: the sign-in log shows a medium or high Risk level (during sign-in), the Conditional Access tab lists your sign-in risk policy, and after MFA the risk state reads Remediated with the detail "User passed multifactor authentication".
- For user risk, confirm a test user compromised, sign in, and check that the password change completes and the risky users entry switches to Remediated.
- Risky sign-in data is kept 7 days on Free, 30 on P1 and 90 on P2; risky users stay until remediated or dismissed. Export
RiskyUsersandUserRiskEventsthrough diagnostic settings if you need longer.
Prevent it next time#
- Register everyone for MFA before enabling enforcement.
- Review the Impact analysis workbook before changing risk levels in a policy.
- Give feedback (confirm safe or compromised) consistently: it tunes the detections for your tenant.
- Watch alerts in Microsoft Defender XDR with the product name filter AAD Identity Protection, or connect the risk logs to Microsoft Sentinel.