User Risk and Sign-In Risk Policies

User Risk and Sign-In Risk Policies in Microsoft Entra ID Protection – SC-300 Exam Guide

Why Are User Risk and Sign-In Risk Policies Important?

In today's threat landscape, identity is the new security perimeter. Attackers constantly attempt to compromise user credentials through phishing, password spray, credential stuffing, and other techniques. Organizations need automated, intelligent mechanisms to detect and respond to these threats in real time. User Risk and Sign-In Risk Policies, part of Microsoft Entra ID Protection (formerly Azure AD Identity Protection), provide exactly this capability. They allow organizations to enforce adaptive access controls based on the assessed risk level of a user or a specific sign-in attempt, dramatically reducing the window of exposure when credentials are compromised.

For the SC-300 (Microsoft Identity and Access Administrator) exam, understanding these policies is critical because they form a core pillar of implementing authentication and access management in a Zero Trust architecture.

What Are User Risk and Sign-In Risk Policies?

Microsoft Entra ID Protection uses machine learning, heuristics, and Microsoft's vast threat intelligence network to calculate two distinct types of risk:

1. User Risk
User risk represents the probability that a user's identity or account has been compromised. It is calculated offline and is not tied to a single sign-in event. Instead, it considers signals over time.

Examples of detections that contribute to user risk:
- Leaked credentials: Microsoft discovers the user's credentials on the dark web or in public paste sites.
- Azure AD Threat Intelligence: Microsoft's internal and external threat intelligence identifies suspicious activity associated with the user.
- Anomalous user activity: Unusual patterns that suggest account compromise.

User risk levels: Low, Medium, High, and None.

2. Sign-In Risk
Sign-in risk represents the probability that a specific authentication request is not authorized by the identity owner. It is calculated in real time during the sign-in process.

Examples of detections that contribute to sign-in risk:
- Anonymous IP address: Sign-in from a Tor browser or anonymous VPN.
- Atypical travel: Two sign-ins from geographically distant locations in an impossibly short time (impossible travel).
- Malware-linked IP address: Sign-in from an IP address known to communicate with bot servers.
- Unfamiliar sign-in properties: Sign-in with properties not seen recently for the user.
- Password spray: Multiple accounts attacked with common passwords.
- Token anomalies: Unusual token characteristics detected.

Sign-in risk levels: Low, Medium, High, and None.

How Do These Policies Work?

Configuration Options:

There are two ways to configure risk-based policies:

1. Identity Protection policies (classic): Configured directly in the Microsoft Entra ID Protection blade. These are simpler but have limited controls.

2. Conditional Access policies (recommended): Microsoft now recommends using Conditional Access as the mechanism for enforcing risk-based policies. This provides the full power of Conditional Access conditions, grant controls, and session controls.

User Risk Policy – How It Works:

- Condition: You configure the policy to trigger when user risk is at a specified level (e.g., High, Medium and above, or Low and above).
- Action (Grant Control): You can require the user to change their password (requires self-service password reset to be enabled) or block access entirely.
- When a user's risk is elevated and they sign in, the policy intercepts the sign-in and enforces the configured control.
- If the user successfully changes their password, the user risk is automatically remediated (risk is dismissed), because the assumption is that the compromised credentials are no longer valid.
- Requires Microsoft Entra ID P2 license.

Sign-In Risk Policy – How It Works:

- Condition: You configure the policy to trigger when sign-in risk is at a specified level (e.g., High, Medium and above).
- Action (Grant Control): You can require multifactor authentication (MFA) or block access.
- The policy evaluates the sign-in in real time. If the risk level meets or exceeds the configured threshold, the user is challenged with MFA or blocked.
- If the user successfully completes MFA, the sign-in risk for that session is automatically remediated, as MFA proves the legitimate user is present.
- Requires Microsoft Entra ID P2 license.

Key Differences Between User Risk and Sign-In Risk:

Aspect	User Risk	Sign-In Risk
Scope	Overall account compromise	Specific sign-in attempt
Detection timing	Offline (calculated over time)	Real-time (during sign-in)
Recommended remediation	Password change	Multifactor authentication
Auto-remediation	Password change clears user risk	Completing MFA clears sign-in risk

Important Prerequisites and Dependencies:

- Licensing: Microsoft Entra ID P2 (or equivalent like EMS E5, Microsoft 365 E5).
- Self-Service Password Reset (SSPR): Must be enabled for user risk policy remediation via password change. If SSPR is not enabled, users cannot self-remediate and an admin must manually dismiss the risk or reset the password.
- MFA registration: Users must be registered for MFA before a sign-in risk policy can challenge them. Identity Protection includes an MFA registration policy to enforce registration.
- Combined registration: Microsoft recommends enabling combined security information registration for SSPR and MFA.

Administrative Actions for Risk Management:

- Dismiss user risk: An admin can manually dismiss a user's risk if they determine it is a false positive or has been remediated outside of the automated flow.
- Confirm user compromised: An admin can manually set user risk to High.
- Confirm sign-in safe / compromised: Admins can provide feedback on individual sign-in risk detections to improve the machine learning model.
- Block user: If a user's risk cannot be remediated, the admin can block sign-in.

Risk Remediation Flow Summary:

1. A risk detection occurs (e.g., leaked credentials detected → user risk set to High).
2. The user attempts to sign in.
3. The Conditional Access policy (or Identity Protection policy) evaluates the user risk level.
4. If the threshold is met, the policy requires a password change.
5. The user changes their password via SSPR.
6. User risk is automatically remediated to None.
7. The user gains access.

For sign-in risk:
1. A user attempts to sign in from an anonymous IP → sign-in risk calculated as Medium.
2. The Conditional Access policy evaluates the sign-in risk.
3. If the threshold is met, the user is challenged with MFA.
4. The user completes MFA successfully.
5. Sign-in risk for that session is remediated.
6. The user gains access.

Conditional Access Integration (Recommended Approach):

When creating a Conditional Access policy for risk:
- Assignments → Users: Select the users or groups (typically All users, with exclusions for emergency access accounts).
- Assignments → Conditions → User risk: Select the risk level (High, Medium, Low).
- Assignments → Conditions → Sign-in risk: Select the risk level (High, Medium, Low).
- Grant controls: Require password change (user risk), require MFA (sign-in risk), or block access.
- Session controls: You can also configure sign-in frequency to force re-authentication.

Note: You should not combine user risk and sign-in risk in the same Conditional Access policy. Create separate policies for each.


===== Exam Tips: Answering Questions on User Risk and Sign-In Risk Policies =====

Tip 1: Know the difference between User Risk and Sign-In Risk.
This is the most commonly tested concept. Remember: User risk = account compromise over time (offline detection). Sign-in risk = suspicious sign-in attempt (real-time detection). If a question mentions leaked credentials or dark web, it's user risk. If it mentions anonymous IP, impossible travel, or atypical location, it's sign-in risk.

Tip 2: Know the correct remediation for each risk type.
- User risk → Require password change (self-remediation) or block access.
- Sign-in risk → Require MFA or block access.
If a question asks what control to apply for user risk, the answer is almost always password change. If for sign-in risk, it's MFA. Do NOT confuse these.

Tip 3: Remember the SSPR prerequisite.
If a question describes a scenario where users cannot self-remediate user risk, check whether SSPR is enabled. If SSPR is not enabled or the user is not registered for SSPR, the user cannot change their password and an administrator must intervene. This is a common trap in exam questions.

Tip 4: Microsoft recommends Conditional Access over Identity Protection policies.
If a question asks for the recommended way to configure risk-based policies, the answer is Conditional Access, not the legacy Identity Protection policy blade. Conditional Access provides more granular control and is the Microsoft-recommended approach.

Tip 5: Licensing matters.
Risk-based policies require Microsoft Entra ID P2. If a scenario describes an organization with only P1 or Free tier, they cannot use risk-based Conditional Access policies. This is occasionally tested.

Tip 6: Always exclude emergency access (break-glass) accounts.
Best practice (and sometimes tested) is to exclude at least one emergency access account from risk-based policies to prevent lockout. If a question asks about best practices for implementing these policies, remember this exclusion.

Tip 7: Understand auto-remediation.
- Completing a password change auto-remediates user risk.
- Completing MFA auto-remediates sign-in risk.
If a question asks what happens after remediation, the risk level returns to None/cleared.

Tip 8: Know when admin intervention is required.
If a policy is set to block access (rather than requiring password change or MFA), the user cannot self-remediate. An admin must either dismiss the risk, reset the user's password, or unblock the account. Questions may describe scenarios where users are completely blocked and ask what the admin should do.

Tip 9: Risk levels and policy thresholds.
Microsoft recommends:
- User risk policy: Require password change at High risk level.
- Sign-in risk policy: Require MFA at Medium and above risk level.
These are the recommended default thresholds. Setting thresholds too low increases false positives; setting them too high may miss real threats.

Tip 10: Separate policies for separate risk types.
Do not combine user risk and sign-in risk conditions in a single Conditional Access policy. Create dedicated policies for each. This is a best practice that may appear in scenario-based questions.

Tip 11: MFA registration policy.
Identity Protection includes an MFA registration policy that can require users to register for MFA. This ensures users are ready to respond to sign-in risk challenges. If users are not registered for MFA and a sign-in risk policy requires MFA, they may be blocked. Exam questions may test this prerequisite.

Tip 12: Understand the risk investigation workflow.
You may be asked about investigating risks. Key tools include:
- Risky users report: Shows users with elevated risk levels and the detections contributing to their risk.
- Risky sign-ins report: Shows sign-ins flagged as risky.
- Risk detections report: Shows individual detections with details.
Admins can filter, investigate, and take action (confirm compromised, dismiss, block) from these reports.

Tip 13: Watch for scenario-based questions.
The SC-300 exam heavily uses scenarios. A typical pattern is: 'A user reports they cannot sign in. Investigation shows their user risk is High due to leaked credentials. SSPR is not enabled. What should the admin do?' The answer would involve the admin resetting the user's password and dismissing the user risk, since the user cannot self-remediate without SSPR.

Tip 14: Risk-based policies and named locations.
Remember that Conditional Access allows combining risk conditions with other conditions like named locations. A question might ask you to require MFA for risky sign-ins only from outside the corporate network. This is achievable by combining sign-in risk with a location condition in Conditional Access.

Summary for Quick Review:

- User Risk = Account likely compromised → Remediate with password change → Requires SSPR → Detected offline
- Sign-In Risk = Suspicious sign-in attempt → Remediate with MFA → Requires MFA registration → Detected in real time
- Use Conditional Access (not legacy Identity Protection policies) for configuration
- Requires Entra ID P2 license
- Always exclude break-glass accounts
- Create separate policies for user risk and sign-in risk
- Successful remediation auto-clears the associated risk