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:
- Enable Self-Service Password Reset (SSPR) - Users need to reset passwords themselves
- SSPR and MFA registration - Users must have methods registered
- Emergency access accounts exist - Break-glass accounts must be excluded
- Password writeback configured (if hybrid) - For synced users to reset cloud passwords
Time Estimate
| Task | Duration |
|---|---|
| Verify SSPR is enabled | 15-30 minutes |
| Policy creation | 10-15 minutes |
| Report-only monitoring | 3-7 days (recommended) |
| Full enablement | 5 minutes |
| Total | 4-8 days including monitoring |
Step-by-Step Instructions
Step 1: Verify SSPR Prerequisites
Before creating the policy, ensure users can reset their passwords:
- Navigate to Entra admin center > Protection > Password reset
- Verify Self-service password reset enabled is set to All (or at minimum, a pilot group)
- Under Authentication methods, ensure at least 2 methods are required
- If using hybrid identity, verify Password writeback is enabled under On-premises integration
Step 2: Navigate to Conditional Access
- Sign in to the Microsoft Entra admin center
- In the left navigation, expand Protection
- Select Conditional Access
- Click Policies in the submenu
Step 3: Create a New Policy
- Click + New policy at the top of the policies list
- Enter a descriptive name:
Require Password Change for High-Risk Users
Step 4: Configure Users and Groups
- Under Assignments, click Users
- Select All users under Include
- Under Exclude, click Users and groups
- Add your emergency access accounts
- Optionally add service accounts that cannot reset passwords
Step 5: Configure Target Resources
- Under Target resources, click Cloud apps
- Select All cloud apps under Include
Step 6: Configure User Risk Condition
This is the key configuration for this policy:
- Under Conditions, click User risk
- Set Configure to Yes
- 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
- Under Access controls, click Grant
- Select Grant access
- Check Require password change
- Check Require multifactor authentication (recommended - MFA verifies identity before allowing password change)
- Select Require all the selected controls
- 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:
- Under Enable policy, select Report-only
- Click Create
- Monitor the Risky users report for 3-7 days
- Review impact and identify any users who may need assistance
- 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:
- Policy Triggered: User is identified as high-risk
- MFA Prompted: User must complete MFA to verify identity
- Password Reset Required: User is redirected to SSPR
- New Password Set: User creates a new password meeting complexity requirements
- Risk Cleared: User risk level is automatically reset to "No risk"
- 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
- Navigate to Entra admin center > Protection > Identity Protection
- Click Risky users to view current at-risk accounts
- Verify the count and review any high-risk users
Sign-in Log Validation
- Navigate to Entra admin center > Monitoring > Sign-in logs
- Click on any sign-in and check the Conditional Access tab
- For risky users, verify your policy appears
Test User Remediation
- Have a test user (not emergency account) attempt to sign in
- If the user has elevated risk, verify they are prompted for MFA + password change
- 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:
- Verify SSPR is enabled for the user (or for "All users")
- Check if the user has registered authentication methods for SSPR
- For hybrid users, verify password writeback is enabled and functional
- 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:
- Password must be reset via SSPR for automatic risk dismissal
- Admin-initiated password resets do NOT clear user risk automatically
- 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:
- Exclude service accounts from the user risk policy
- Use managed identities where possible (no passwords to leak)
- Review if service account credentials were actually leaked
- Rotate credentials for any leaked service accounts
False Positives
Symptom: Users are flagged as high-risk but have not been compromised.
Solutions:
- Review the specific risk detections in Identity Protection
- Check if the user's password appears in public breach databases
- Consider that even false positives mean the password is exposed
- Encourage users to use unique passwords not used elsewhere
Password Writeback Issues (Hybrid)
Symptom: Cloud password reset fails for synced users.
Solutions:
- Verify password writeback is enabled in Entra Connect
- Check Entra Connect sync health for errors
- Ensure the Entra Connect service account has correct permissions
- Review the Entra Connect event logs for password writeback errors
Policy Configuration Summary
| Setting | Value |
|---|---|
| Policy Name | Require Password Change for High-Risk Users |
| Users - Include | All users |
| Users - Exclude | Emergency access accounts, service accounts |
| Cloud Apps | All cloud apps |
| Conditions - User risk | High |
| Grant | Require password change + Require MFA (all selected) |
| Enable Policy | On |
Monitoring and Maintenance
Regular Reviews
- Daily: Check the Risky users report for new high-risk accounts
- Weekly: Review users who remain at risk (may need assistance)
- Monthly: Analyze trends in user risk detections
Manual Risk Dismissal
When an admin confirms a false positive:
- Navigate to Protection > Identity Protection > Risky users
- Select the user
- Click Dismiss user risk
- Document the reason for dismissal
Manual Risk Confirmation
When an admin confirms account compromise:
- Navigate to Protection > Identity Protection > Risky users
- Select the user
- Click Confirm user compromised
- This sets the user to high risk and enforces remediation
Difference Between Sign-In Risk and User Risk
| Aspect | Sign-In Risk (CA-03) | User Risk (CA-04) |
|---|---|---|
| Scope | Single authentication attempt | User account state |
| Duration | Evaluated per sign-in | Persists until remediated |
| Example Trigger | Impossible travel, anonymous IP | Leaked credentials |
| Remediation | MFA satisfies the policy | Password change required |
| Auto-Clear | After sign-in completes | After 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)