Entra ID Risk-Based Conditional Access : Understanding User Risk vs. Sign-in Risk to Build Smarter Policies

In today’s ever-evolving threat landscape, identity has become the new security perimeter. Attackers no longer need to breach firewalls or exploit network vulnerabilities when they can simply compromise a user’s credentials through phishing, password spraying, or credential stuffing attacks. Microsoft Entra ID Protection, combined with Conditional Access policies, provides organizations with a powerful framework to automatically detect these identity-based threats and require users to remediate risks before gaining access to corporate resources.

This article provides a comprehensive, hands-on guide to understanding and implementing risk remediation policies in Microsoft 365 Conditional Access.

User Risk vs. Sign-in Risk

Understanding the distinction between user risk and sign-in risk is fundamental to configuring effective risk remediation policies. These two risk types address different threat scenarios and require different remediation approaches.

User risk :

Represents the probability that a given user account has been compromised. This is a persistent risk that stays with the user until it is remediated. For example, if a user’s credentials are found in a leaked credentials database, the user risk level is elevated to “High” and remains there until the user completes a secure password change or an administrator manually dismisses the risk. User risk detections include scenarios like leaked credentials, anomalous user activity, attacker-in-the-middle attacks, suspicious API traffic, and attempts to access the Primary Refresh Token (PRT).

Sign-in risk :

On the other hand, represents the probability that a specific authentication request was not authorized by the identity owner. Sign-in risk is transactional — it applies to a single sign-in session rather than the user account as a whole. Examples include sign-ins from anonymous IP addresses, atypical travel patterns, impossible travel, password spray attacks, and unfamiliar sign-in properties. Once the sign-in session is remediated (typically through MFA), the risk for that specific sign-in is resolved.

Aspect	User Risk	Sign-in Risk
Scope	Entire user account	Single sign-in session
Persistence	Remains until remediated	Per-session, resolved after remediation
Typical Remediation	Secure password change + MFA or session revocation	Complete MFA challenge
Examples	Leaked credentials, anomalous token, AiTM attack	Anonymous IP, atypical travel, password spray
Recommended Risk Level	Enforce at High	Enforce at Medium + High
Grant Control	Require Risk Remediation or Require Password Change	Require MFA (Authentication Strength)

Never combine sign-in risk and user risk conditions in the same Conditional Access policy. Microsoft explicitly warns against this. Always create separate policies for each risk condition to avoid conflicts and ensure proper remediation flows.

Risk Detection Types

Microsoft Entra ID Protection provides a broad range of risk detections that identify suspicious activity in your organization. These detections are powered by a combination of real-time analysis during the sign-in flow and offline analysis that runs asynchronously. Understanding these detection types helps you appreciate the depth of intelligence behind risk-based policies and enables you to investigate alerts more effectively.

How Adaptive Risk Remediation Works

The “Require Risk Remediation” grant control is the newest and most intelligent option available for user risk policies in Conditional Access. Unlike the older “Require Password Change” control, which only addresses password-based scenarios, the “Require Risk Remediation” control uses adaptive remediation that adjusts its behavior based on the specific threat observed and the user’s authentication method.

When this control is triggered, Microsoft Entra ID Protection evaluates the nature of the risk detection and the user’s configured authentication methods, then selects the most appropriate remediation action. This means the same policy can effectively protect both password-based users and passwordless users without requiring separate policies for each group.

Prerequisites

Before implementing CA auto-remediation, ensure the following components are licensed, configured, and in scope.

• Microsoft Entra ID P2 : Required for Identity Protection, risk-based CA, and sign-in risk signals. Included in M365 E5.
• Entra ID SSPR Enabled : Self-Service Password Reset must be enabled for user-driven remediation flows.
• MFA Registration : All users must have registered for Microsoft Entra MFA before facing a risk-based policy. Unregistered users will be blocked and require admin intervention.

At least two break-glass accounts must exist and be excluded from all Conditional Access policies. These accounts prevent complete lockout in case of policy misconfiguration or service issues.

Step-by-Step : Configure User Risk Remediation Policy

This section walks you through creating a Conditional Access policy that requires risk remediation when a user’s risk level is High. This is the recommended configuration by Microsoft and covers both password-based and passwordless authentication methods through adaptive remediation.

• Navigate to https://entra.microsoft.com and sign in with an account that has at least the Conditional Access Administrator role assigned.
• In the left navigation menu, browse to Entra ID → Conditional Access.
• Click “New policy” at the top of the Conditional Access blade. Give your policy a descriptive, meaningful name that follows your organization’s naming convention.

• Give your policy a descriptive, meaningful name that follows your organization’s naming convention. For example :
  • CA-UserRisk-High-RequireRemediation or CA301 – User Risk High – Require Risk Remediation – All Users
• Under Assignments, click “Users or workload identities”.
  • Under Include, select “All users”.
  • Under Exclude, click “Users and groups” and select your organization’s emergency access (break-glass) accounts.

• Under Target resources → Include, select “All resources (formerly ‘All cloud apps’)”. This ensures the risk remediation requirement applies regardless of which application the user is trying to access.
  • Under Conditions → User risk:
  • Set Configure to “Yes”.
  • Under “Configure user risk levels needed for policy to be enforced”, select “High”.
  • Click Done.

Microsoft recommends enforcing at the High level to minimize false positives. Adjust based on your organization’s risk tolerance.

• Under Access controls → Grant:
  • Select “Grant access”.
  • Check “Require risk remediation”.
  • Notice that “Require authentication strength” is automatically selected. Choose the strength appropriate for your organization (e.g., Multifactor authentication or Phishing-resistant MFA).
  • Click Select.

• Set Enable policy to “Report-only”. This is a critical best practice that allows you to validate the policy’s impact on your users without actually enforcing it. Monitor the results in the Conditional Access insights and reporting workbook for at least one to two weeks before switching to enforcement.

• Click “Create” to save the policy. After confirming your settings using report-only mode, move the “Enable policy” toggle from “Report-only” to “On” to start enforcement. Monitor the sign-in logs and Identity Protection reports to ensure the policy is working as expected.

Step-by-Step: Configure Sign-in Risk Policy

While the user risk policy addresses persistent account compromise, the sign-in risk policy handles suspicious individual authentication attempts. Microsoft recommends requiring MFA when the sign-in risk is Medium or High.

• In the Entra admin center, navigate to Entra ID → Conditional Access → New policy.
  • Name it something descriptive like : CA302 -SignInRisk - MediumHigh -RequireMFA – All Users

• Under Conditions → Sign-in risk:
  • Set Configure to “Yes”.
  • Select both “High” and “Medium” risk levels.
  • Click Done.

• Under Access controls → Grant:
  • Select “Grant access”.
  • Select “Require authentication strength”, then choose the built-in “Multifactor authentication” strength from the list.
  • Click Select.

• Under Session:
  • Select “Sign-in frequency”.
  • Ensure “Every time” is selected.
  • Click Select.
• Set Enable policy to “Report-only”, click Create, validate results, then switch to “On”.

Monitoring and Investigating Risks

Deploying risk remediation policies is only the beginning. Continuous monitoring and investigation are essential to maintaining an effective identity security posture. Microsoft provides several tools and reports for this purpose.

• Identity Protection Dashboard : Entra ID → Identity Protection → Dashboard : Kink
• Risky Users Report : : Entra ID → Identity Protection → Risky Users : Link
• Risky Sign-ins Report : Entra ID → Identity Protection → Risky Sign-ins : Link
• Risk Detections Report : Entra ID → Identity Protection → Risk detections : Link

Best Practices

• Always Deploy in Report-Only Mode First : Before enforcing any risk-based policy, deploy it in report-only mode for at least 1-2 weeks. Analyze the Conditional Access insights and reporting workbook to understand the policy’s impact on your users. This prevents unexpected lockouts and gives you time to identify edge cases.
• Maintain Emergency Access Accounts : Always have at least two break-glass accounts excluded from all Conditional Access policies, including risk-based ones. These accounts should use strong, unique credentials stored securely, and their usage should be monitored through alerts. They are your lifeline in case of policy misconfiguration.
• Separate User Risk and Sign-in Risk Policies : Never combine user risk and sign-in risk conditions in the same Conditional Access policy. Microsoft explicitly warns against this. Create distinct policies for each risk type with appropriate grant controls and risk level thresholds.
• Enforce MFA Registration Proactively : Deploy an MFA registration policy through Identity Protection to ensure all users register for MFA before they encounter a risk-based policy. Users who haven’t registered for MFA will be blocked and require admin intervention, creating unnecessary helpdesk burden.
• Migrate Legacy Policies Before Retirement : If you’re still using legacy risk policies in the Identity Protection blade, migrate them to Conditional Access before the October 2026 retirement date. Create equivalent policies in report-only mode, validate them, then enable and disable the legacy policies.
• Monitor and Review Regularly : Review the Identity Protection dashboard, risky users report, and Conditional Access insights weekly. Look for trends in risk detections, investigate persistent risks, and adjust policies as your organization’s security posture evolves.
• Enable Password Hash Sync for Hybrid Environments : For hybrid organizations, ensure password hash synchronization is enabled and consider enabling the “Allow on-premises password change to reset user risk” setting. This allows hybrid users to self-remediate by changing their password on-premises, reducing helpdesk intervention.

Thanks