CA-04: Creating a User Risk-Based Policy

Overview

This guide walks you through creating a Conditional Access policy that responds to user risk levels detected by Microsoft Entra ID Protection. Unlike sign-in risk (which evaluates individual authentication attempts), user risk represents an ongoing risk state for a user account, typically triggered when credentials are found in breached databases or when suspicious activity patterns are detected.

Control ID: CA-04 Category: Conditional Access Severity: High License Required: Microsoft Entra ID P2 (included in Microsoft 365 E5 or standalone Entra ID P2)

Why This Matters

Microsoft continuously monitors the dark web and known breach databases for leaked credentials. When a user's credentials are discovered in a breach, their account becomes "high risk" until remediated. User risk detection identifies:

  • Leaked credentials - Credentials found in public breach databases
  • Anomalous user activity - Patterns indicating account compromise
  • Threat intelligence - Microsoft's internal and partner threat feeds
  • Suspicious inbox rules - Attacker persistence mechanisms

Without a user risk policy, compromised credentials remain valid indefinitely. A user risk policy forces password changes when compromise is detected.


Prerequisites

Required Roles

You need one of the following Entra ID roles:

  • Conditional Access Administrator (recommended - least privilege)
  • Security Administrator
  • Global Administrator

Required Licenses

  • Microsoft Entra ID P2 for each user in scope
  • Included in: Microsoft 365 E5 or standalone Entra ID P2

Pre-Configuration Requirements

Before creating this policy:

  1. Enable Self-Service Password Reset (SSPR) - Users need to reset passwords themselves
  2. SSPR and MFA registration - Users must have methods registered
  3. Emergency access accounts exist - Break-glass accounts must be excluded
  4. Password writeback configured (if hybrid) - For synced users to reset cloud passwords

Time Estimate

TaskDuration
Verify SSPR is enabled15-30 minutes
Policy creation10-15 minutes
Report-only monitoring3-7 days (recommended)
Full enablement5 minutes
Total4-8 days including monitoring

Step-by-Step Instructions

Step 1: Verify SSPR Prerequisites

Before creating the policy, ensure users can reset their passwords:

  1. Navigate to Entra admin center > Protection > Password reset
  2. Verify Self-service password reset enabled is set to All (or at minimum, a pilot group)
  3. Under Authentication methods, ensure at least 2 methods are required
  4. If using hybrid identity, verify Password writeback is enabled under On-premises integration

Step 2: Navigate to Conditional Access

  1. Sign in to the Microsoft Entra admin center
  2. In the left navigation, expand Protection
  3. Select Conditional Access
  4. Click Policies in the submenu

Step 3: Create a New Policy

  1. Click + New policy at the top of the policies list
  2. Enter a descriptive name: Require Password Change for High-Risk Users

Step 4: Configure Users and Groups

  1. Under Assignments, click Users
  2. Select All users under Include
  3. Under Exclude, click Users and groups
  4. Add your emergency access accounts
  5. Optionally add service accounts that cannot reset passwords

Step 5: Configure Target Resources

  1. Under Target resources, click Cloud apps
  2. Select All cloud apps under Include

Step 6: Configure User Risk Condition

This is the key configuration for this policy:

  1. Under Conditions, click User risk
  2. Set Configure to Yes
  3. Select the risk levels to target:

Recommended Configuration:

  • High - Require password change

Optional for High-Security Environments:

  • Medium - Require MFA
  • High - Require password change

Step 7: Configure Access Controls

  1. Under Access controls, click Grant
  2. Select Grant access
  3. Check Require password change
  4. Check Require multifactor authentication (recommended - MFA verifies identity before allowing password change)
  5. Select Require all the selected controls
  6. Click Select

Important: Requiring both MFA and password change ensures an attacker cannot simply reset the password with stolen credentials.

Step 8: Enable the Policy

Recommended approach - Start with Report-only:

  1. Under Enable policy, select Report-only
  2. Click Create
  3. Monitor the Risky users report for 3-7 days
  4. Review impact and identify any users who may need assistance
  5. Once validated, edit the policy and change to On

Understanding User Risk Levels

High Risk

Indicates a high probability the user's account has been compromised.

Detection Examples:

  • Credentials found in a known data breach (leaked credentials)
  • Confirmed malicious activity on the account
  • Impossible travel combined with other risk factors

Recommended Action: Require password change + MFA

Medium Risk

Indicates moderate probability of account compromise.

Detection Examples:

  • Suspicious activity patterns
  • Atypical behavior over time
  • Multiple low-risk detections aggregated

Recommended Action: Require MFA or password change

Low Risk

Indicates minor risk signals.

Detection Examples:

  • Anomalous activity that could be benign
  • Historical patterns that deviate slightly

Recommended Action: Log and monitor (Level 3 environments may require MFA)


How User Risk Remediation Works

When a user with elevated risk attempts to sign in:

  1. Policy Triggered: User is identified as high-risk
  2. MFA Prompted: User must complete MFA to verify identity
  3. Password Reset Required: User is redirected to SSPR
  4. New Password Set: User creates a new password meeting complexity requirements
  5. Risk Cleared: User risk level is automatically reset to "No risk"
  6. Access Granted: User can now access resources

Important: The user risk is automatically cleared when the password is changed via SSPR. Admin-initiated password resets do NOT clear user risk.


Verification Checklist

After enabling the policy, verify successful implementation:

Immediate Checks

  • Policy appears in the Conditional Access policies list with status "On" or "Report-only"
  • User risk condition is properly configured (High selected)
  • Both MFA and password change are required in grant controls
  • Emergency access accounts are listed in the exclusions

Identity Protection Dashboard

  1. Navigate to Entra admin center > Protection > Identity Protection
  2. Click Risky users to view current at-risk accounts
  3. Verify the count and review any high-risk users

Sign-in Log Validation

  1. Navigate to Entra admin center > Monitoring > Sign-in logs
  2. Click on any sign-in and check the Conditional Access tab
  3. For risky users, verify your policy appears

Test User Remediation

  1. Have a test user (not emergency account) attempt to sign in
  2. If the user has elevated risk, verify they are prompted for MFA + password change
  3. Confirm the password reset clears their user risk

Troubleshooting

Users Cannot Reset Password

Symptom: High-risk users are stuck in a loop, unable to complete password reset.

Solutions:

  1. Verify SSPR is enabled for the user (or for "All users")
  2. Check if the user has registered authentication methods for SSPR
  3. For hybrid users, verify password writeback is enabled and functional
  4. An admin may need to manually reset the password and dismiss the risk

User Risk Not Clearing After Password Reset

Symptom: User changed password but still shows as high-risk.

Solutions:

  1. Password must be reset via SSPR for automatic risk dismissal
  2. Admin-initiated password resets do NOT clear user risk automatically
  3. To manually clear: Identity Protection > Risky users > Select user > Dismiss user risk

Service Accounts Blocked

Symptom: Service accounts or shared mailboxes are blocked as high-risk.

Solutions:

  1. Exclude service accounts from the user risk policy
  2. Use managed identities where possible (no passwords to leak)
  3. Review if service account credentials were actually leaked
  4. Rotate credentials for any leaked service accounts

False Positives

Symptom: Users are flagged as high-risk but have not been compromised.

Solutions:

  1. Review the specific risk detections in Identity Protection
  2. Check if the user's password appears in public breach databases
  3. Consider that even false positives mean the password is exposed
  4. Encourage users to use unique passwords not used elsewhere

Password Writeback Issues (Hybrid)

Symptom: Cloud password reset fails for synced users.

Solutions:

  1. Verify password writeback is enabled in Entra Connect
  2. Check Entra Connect sync health for errors
  3. Ensure the Entra Connect service account has correct permissions
  4. Review the Entra Connect event logs for password writeback errors

Policy Configuration Summary

SettingValue
Policy NameRequire Password Change for High-Risk Users
Users - IncludeAll users
Users - ExcludeEmergency access accounts, service accounts
Cloud AppsAll cloud apps
Conditions - User riskHigh
GrantRequire password change + Require MFA (all selected)
Enable PolicyOn

Monitoring and Maintenance

Regular Reviews

  1. Daily: Check the Risky users report for new high-risk accounts
  2. Weekly: Review users who remain at risk (may need assistance)
  3. Monthly: Analyze trends in user risk detections

Manual Risk Dismissal

When an admin confirms a false positive:

  1. Navigate to Protection > Identity Protection > Risky users
  2. Select the user
  3. Click Dismiss user risk
  4. Document the reason for dismissal

Manual Risk Confirmation

When an admin confirms account compromise:

  1. Navigate to Protection > Identity Protection > Risky users
  2. Select the user
  3. Click Confirm user compromised
  4. This sets the user to high risk and enforces remediation

Difference Between Sign-In Risk and User Risk

AspectSign-In Risk (CA-03)User Risk (CA-04)
ScopeSingle authentication attemptUser account state
DurationEvaluated per sign-inPersists until remediated
Example TriggerImpossible travel, anonymous IPLeaked credentials
RemediationMFA satisfies the policyPassword change required
Auto-ClearAfter sign-in completesAfter password reset via SSPR

Best Practice: Implement both sign-in risk (CA-03) and user risk (CA-04) policies for comprehensive protection.


Related Controls

  • CA-03: Block or Require MFA for Risky Sign-Ins (sign-in risk policy)
  • ID-03: Enable Self-Service Password Reset (prerequisite)
  • CA-01: Require MFA for All Users (baseline policy)
  • LOG-03: Stream Security Events to SIEM (for correlation)

Additional Resources