This chapter covers Entra ID Risk Policies and Sign-In Risk, a critical component of identity security in Microsoft 365. You will learn how Microsoft Entra ID Protection detects and responds to risky sign-in attempts using real-time and offline risk detections. For the SC-200 exam, this topic appears in approximately 10-15% of questions, often integrated with Conditional Access and Microsoft Defender for Cloud Apps. Understanding risk levels, detection types, and policy configuration is essential for passing the exam and for implementing adaptive access controls in production environments.
Jump to a section
Entra ID sign-in risk policies work like a bank's fraud detection system for credit card transactions. Imagine every sign-in attempt is a credit card swipe. The bank has a fraud detection engine that analyzes each transaction in real time: it checks the location (if a card used in New York is suddenly used in London an hour later, that's suspicious), the device fingerprint (is the card being used from a known phone or a new, unrecognized device?), the transaction amount, and the time of day. Based on these signals, the engine calculates a risk score (low, medium, high). For low risk, the transaction goes through. For medium risk, the bank might send an SMS verification code to the cardholder's phone. For high risk, the bank blocks the transaction outright. The bank also has policies: you can configure that any transaction over $500 requires verification, or that international transactions always trigger a phone call. In the same way, Entra ID evaluates sign-in context (user, device, location, app) to compute a risk level, then applies conditional access policies: allow, block, or require MFA. The bank's fraud team can also review suspicious transactions after the fact, just like security analysts review Risky Sign-ins in the portal.
What is Sign-In Risk and Why Does It Exist?
Sign-in risk is a probability score assigned by Microsoft Entra ID Protection to each authentication attempt, indicating the likelihood that the sign-in is not performed by the legitimate user. The score ranges from 0 to 100 and is categorized into three levels: Low (0-24), Medium (25-49), and High (50-100). This risk assessment enables organizations to implement adaptive access controls—automatically blocking high-risk sign-ins or requiring multi-factor authentication (MFA) for medium-risk ones—without disrupting legitimate users.
The primary purpose of sign-in risk policies is to reduce the attack surface for identity-based threats such as credential theft, password spray, and token replay. By evaluating contextual signals—like IP address reputation, device characteristics, and behavioral patterns—Entra ID can detect anomalies that indicate compromise. For example, a sign-in from a known malicious IP address or from an unfamiliar location would trigger a high-risk score.
How Sign-In Risk Detection Works Internally
Entra ID Protection uses a combination of real-time and offline detection methods. Real-time detections occur during the authentication request itself, while offline detections are processed after the sign-in event, using machine learning models that analyze historical data. Both contribute to the overall risk level.
Real-time detections happen synchronously during the authentication pipeline. When a user submits credentials, Entra ID evaluates the request against a set of rules and models. If the risk is high, the sign-in can be blocked immediately. Real-time detections include: - Anonymous IP address: The sign-in originates from an IP address that is known to be part of an anonymous proxy or Tor network. Entra ID maintains a feed of such IPs. - Atypical travel: Two sign-ins from geographically distant locations within a time window that is impossible for physical travel. This uses the user's historical sign-in locations and travel patterns. - Malware-linked IP address: The source IP is associated with known malware command-and-control (C2) servers. - Unfamiliar sign-in properties: The sign-in shows characteristics that are not typical for the user, such as a new device, browser, or operating system. This is based on a machine learning model that learns the user's baseline behavior over 14-30 days. - Token replay detection: When a token is used from a different IP or device than the one it was issued to, Entra ID can detect the replay and mark the sign-in as risky.
Offline detections are computed after the sign-in completes, using batch processing and machine learning models. These detections can retroactively mark a sign-in as risky, which then updates the risk level and triggers any configured remediation actions (like requiring a password reset). Offline detections include: - Leaked credentials: Microsoft monitors public and dark web sources for leaked username/password pairs. If a user's credentials appear in a leak, any subsequent sign-in using those credentials is flagged as high risk. This detection is updated regularly from sources like Have I Been Pwned. - Suspicious browser: The sign-in used a browser that is known to be compromised or associated with suspicious activity. - Unfamiliar sign-in properties (offline): The same machine learning model that runs in real-time also runs offline to catch patterns that were not detected synchronously. - Password spray: A coordinated attack where a single password is attempted against multiple accounts. Entra ID can detect this pattern and mark affected sign-ins as medium or high risk.
Risk Levels and Their Default Actions
Each sign-in is assigned a risk level: Low, Medium, or High. The risk level is a combination of all detected risk events for that sign-in. The highest individual detection risk determines the overall sign-in risk. For example, if one detection is high and another is low, the overall risk is high.
Low: No action required by default. The sign-in is likely legitimate.
Medium: The sign-in has some suspicious characteristics. The recommended action is to require MFA or a password reset.
High: Strong indication of compromise. The recommended action is to block the sign-in or force a password reset.
Configuring Sign-In Risk Policies
Sign-in risk policies are configured in the Microsoft Entra admin center under Protection > Identity Protection > Sign-in risk policy. The policy consists of three parts: 1. Assignments: Which users or groups are included or excluded. You can target all users, specific groups, or roles. 2. Conditions: The risk level(s) that trigger the policy. You can select Low and above, Medium and above, or High. 3. Controls: The action to take—Allow, Block, or Allow with MFA (which requires the user to complete MFA before access is granted).
The policy can be set to Report-only mode for testing, or On to enforce controls.
Example policy: Block sign-ins when risk level is High. Require MFA when risk level is Medium.
Interaction with Conditional Access
Sign-in risk policies are a type of Conditional Access policy. In fact, they are created as Conditional Access policies under the hood. You can also create custom Conditional Access policies that use the Sign-in risk condition directly. This gives you more granular control, such as requiring a compliant device instead of MFA for medium risk.
Important exam point: If you configure both the Identity Protection sign-in risk policy and a separate Conditional Access policy with sign-in risk condition, both policies are evaluated. The most restrictive control wins. For example, if Identity Protection policy blocks high risk, and Conditional Access policy requires MFA for high risk, the user will be blocked.
Remediation and User Experience
When a sign-in is blocked due to risk, the user sees a generic error message (e.g., "Your sign-in was blocked. Contact your administrator."). If MFA is required, the user is prompted to complete MFA. If the risk is detected after sign-in (offline), the user may be prompted to reset their password on the next interactive sign-in.
Administrators can review risky sign-ins in the Risky sign-ins report under Identity Protection. They can also manually dismiss a risk event if it is a false positive, or confirm the sign-in as compromised to trigger remediation (e.g., force password reset).
Default Values and Timers
Risk score range: 0-100. Low: 0-24, Medium: 25-49, High: 50-100.
Risk event retention: Risk events are retained for 30 days after the sign-in.
Offline detection latency: Leaked credentials detection can take up to 24 hours after the leak is discovered. Other offline detections are processed within hours.
User risk policy (separate): This policy targets users based on their cumulative risk level (aggregated from multiple sign-ins). The user risk policy can force a password reset when user risk is high.
Verification and Monitoring Commands
Using Microsoft Graph API and PowerShell, you can query risky sign-ins:
PowerShell (Microsoft Graph module):
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All"
Get-MgRiskySignIn -Filter "riskLevel eq 'high'"Microsoft Graph API:
GET https://graph.microsoft.com/v1.0/identityProtection/riskySignIns?$filter=riskLevel eq 'high'You can also use the Microsoft 365 Defender portal under Identity > Risky sign-ins for a unified view.
Integration with Microsoft Defender for Cloud Apps
Microsoft Defender for Cloud Apps (MDCA) can ingest sign-in risk events and correlate them with cloud app activity. For example, if a sign-in is high risk, MDCA can apply session policies to restrict download of sensitive data. This integration is part of the Conditional Access App Control feature.
Exam Relevance
The SC-200 exam tests your ability to configure and interpret sign-in risk policies, understand the difference between sign-in risk and user risk, and identify the correct remediation actions. You must know the risk levels, detection types (especially leaked credentials, atypical travel, anonymous IP), and how policies interact with Conditional Access. Common wrong answers include confusing sign-in risk with user risk, or thinking that blocking is the only control (MFA is also an option).
User initiates sign-in attempt
The user navigates to a Microsoft 365 application (e.g., Outlook Web Access, SharePoint Online) and enters their credentials (username and password). The authentication request is sent to Microsoft Entra ID, which begins evaluating the sign-in context. At this point, Entra ID collects data points such as the user's IP address, device fingerprint (browser, OS, device ID), geolocation, timestamp, and the application being accessed.
Real-time risk evaluation
Entra ID Protection runs real-time risk detections against the sign-in request. It checks the IP address against known anonymous proxy and malware-linked IP lists. It evaluates atypical travel by comparing the current location with the user's recent sign-in locations. It also runs the unfamiliar sign-in properties model, which compares the device and browser characteristics to the user's baseline. Each detection produces a risk level (low, medium, high). The highest detection risk becomes the overall sign-in risk level.
Policy evaluation and enforcement
If a sign-in risk policy exists, Entra ID evaluates the assignments (user/group inclusion/exclusion) and conditions (risk level). If the sign-in risk matches the policy condition, the configured control is applied. For example, if risk is high and the policy says Block, the sign-in is denied immediately with an error message. If the policy says Allow with MFA, the user is prompted for MFA. If no policy matches, the sign-in proceeds normally.
Offline risk detection (post-sign-in)
After the sign-in completes, Entra ID Protection runs offline detections in the background. These include checking for leaked credentials (against Microsoft's database of known breaches), suspicious browser signatures, and password spray patterns. If any offline detection triggers a risk level higher than the real-time assessment, the sign-in risk level is updated retroactively. This may trigger remediation actions on the next user interaction.
Administrator review and remediation
Security analysts can review risky sign-ins in the Identity Protection dashboard. They can filter by risk level, detection type, date, and user. For each risky sign-in, the analyst can dismiss the risk (if false positive), confirm compromised (which triggers remediation like password reset), or confirm safe. Remediation actions are logged and can be automated via policies. The analyst can also investigate related alerts in Microsoft 365 Defender.
Scenario 1: Global Enterprise with Remote Workforce
A multinational company with 50,000 employees uses Entra ID for authentication. They configure a sign-in risk policy to block high-risk sign-ins and require MFA for medium risk. They also integrate with Microsoft Defender for Cloud Apps to apply session controls for high-risk sessions. In production, they see about 200 risky sign-ins per week, mostly from leaked credentials and anonymous IP addresses. They set up automated remediation: when a user's credentials are leaked, the policy forces a password reset on next sign-in. A common misconfiguration is setting the policy to block without an exception for break-glass accounts, which can lock out admins. They create an exclusion group for emergency access accounts.
Scenario 2: Healthcare Organization with Strict Compliance
A hospital must comply with HIPAA and requires MFA for all remote access. They configure a Conditional Access policy that uses sign-in risk as a condition: for low risk, allow; for medium, require MFA; for high, block. They also enable user risk policy to force password reset when user risk is high. They use the "New user" risk detection to flag accounts that are newly created and show anomalous behavior. Performance is not an issue as Entra ID scales automatically. However, they face false positives from users traveling frequently; they adjust the atypical travel detection by using named locations to whitelist known office IP ranges.
Scenario 3: Small Business with Limited IT Staff
A 100-person company uses Entra ID Free (which includes basic Identity Protection features). They enable the default sign-in risk policy that blocks high-risk sign-ins. They receive email alerts for risky sign-ins but lack dedicated security staff. They rely on the automated remediation built into the policy. A common issue is that users who use VPNs may trigger anonymous IP detections. The company adds their VPN exit IPs to the trusted IPs list in Conditional Access to reduce false positives. They also periodically review the risky sign-ins report to identify any compromised accounts.
What SC-200 Tests on This Topic
Objective 1.4: Manage Microsoft Defender for Cloud Apps and Microsoft Entra ID Protection. Specifically, you need to "configure and manage sign-in risk policies" and "interpret risk detections."
Detection types: Be able to identify which detection type applies given a scenario. For example, a sign-in from a Tor exit node is "Anonymous IP address." A sign-in from a location 1,000 miles away 5 minutes after a previous sign-in is "Atypical travel."
Risk levels: Know the numeric ranges: Low (0-24), Medium (25-49), High (50-100). The exam may ask what action to take for a given risk level.
Policy controls: Remember that sign-in risk policies can Allow, Block, or Allow with MFA. They cannot directly force a password reset (that's user risk policy).
Integration: Sign-in risk policies are implemented as Conditional Access policies. They can be viewed in Conditional Access blade.
Common Wrong Answers and Why
Confusing sign-in risk with user risk: Sign-in risk is per-authentication event; user risk is cumulative across all sign-ins for a user. The exam may describe a scenario where a single sign-in is suspicious and ask for the policy to apply—that's sign-in risk policy, not user risk policy.
Thinking blocking is the only action: Many candidates think high risk must be blocked, but the policy can also allow with MFA. The exam tests that you can choose less restrictive controls.
Assuming all detections are real-time: Leaked credentials detection is offline and can take up to 24 hours. The exam may present a scenario where a user signs in with leaked credentials and ask why the sign-in wasn't blocked immediately—the answer is that the detection is offline.
Forgetting that policies are evaluated in order: If multiple Conditional Access policies apply, all are evaluated. The most restrictive grant control wins. The exam may test this with a scenario where one policy requires MFA and another blocks—the result is block.
Specific Numbers and Terms
Risk score ranges: Low 0-24, Medium 25-49, High 50-100.
Detection types: Anonymous IP address, Atypical travel, Malware-linked IP address, Unfamiliar sign-in properties, Leaked credentials, Suspicious browser, Password spray.
Default policy: None—you must create it.
Report-only mode: Allows testing without enforcement.
Remediation: For high risk, block or require MFA; for medium, require MFA.
Edge Cases
Guest users: Sign-in risk policies apply to guest users only if they sign in to your tenant. The exam may ask whether a guest user's risky sign-in is evaluated.
Service principals: Sign-in risk policies do not apply to service principal authentication (non-interactive).
Hybrid identity: If using pass-through authentication or federation, risk detection still works because Entra ID evaluates the sign-in context before passing to on-premises.
How to Eliminate Wrong Answers
If the question mentions "cumulative risk" or "over time," it's user risk, not sign-in risk.
If the scenario involves a specific sign-in event, it's sign-in risk.
If the answer includes "force password reset," that's user risk policy, not sign-in risk policy.
If the answer includes "block" or "allow with MFA," that's sign-in risk.
Sign-in risk is a per-authentication probability score from 0-100, categorized as Low (0-24), Medium (25-49), High (50-100).
Real-time detections (anonymous IP, atypical travel, unfamiliar properties) can block sign-ins synchronously; offline detections (leaked credentials) are processed after sign-in.
Sign-in risk policy controls are: Allow, Block, or Allow with MFA. It cannot force a password reset.
Sign-in risk policy is implemented as a Conditional Access policy; you can also create custom CA policies using sign-in risk condition.
Common detection types: Anonymous IP address, Atypical travel, Malware-linked IP address, Unfamiliar sign-in properties, Leaked credentials, Suspicious browser, Password spray.
Offline detections like leaked credentials can take up to 24 hours to appear.
User risk policy is separate and focuses on cumulative risk over time, with remediation like password reset.
These come up on the exam all the time. Here's how to tell them apart.
Sign-in Risk Policy
Evaluates each sign-in event individually.
Controls access at sign-in: allow, block, require MFA.
Risk level is per sign-in (low/medium/high).
Detections include anonymous IP, atypical travel, unfamiliar properties.
Cannot force password reset; only access controls.
User Risk Policy
Evaluates cumulative risk across all sign-ins for a user.
Controls access and triggers remediation like password reset.
Risk level is per user (low/medium/high).
Aggregates multiple sign-in risk events over time.
Can force password reset on next sign-in.
Mistake
Sign-in risk policy can force a password reset.
Correct
Sign-in risk policy controls access at the time of sign-in: allow, block, or require MFA. Forcing a password reset is a remediation action triggered by user risk policy or manually by an administrator. The two policies are separate.
Mistake
All risk detections happen in real-time and block the sign-in.
Correct
Only real-time detections (like anonymous IP, atypical travel) can block the sign-in synchronously. Offline detections (like leaked credentials) are processed after the sign-in and only update the risk level retroactively. The sign-in may have already succeeded.
Mistake
Sign-in risk policy applies to all authentication types, including non-interactive.
Correct
Sign-in risk policy only applies to interactive sign-ins where the user provides credentials. Non-interactive sign-ins (e.g., service-to-service, token refresh) are not evaluated by sign-in risk policies.
Mistake
Low risk means no action is ever taken.
Correct
Low risk means the sign-in is likely legitimate, but you can still configure a policy to require MFA for low risk if you want a more restrictive stance. By default, no action is taken, but policies can be customized.
Mistake
The sign-in risk policy is the only way to use sign-in risk in Conditional Access.
Correct
You can create a custom Conditional Access policy that uses the 'Sign-in risk' condition directly. This gives you more granular control, such as requiring a compliant device instead of MFA. The Identity Protection sign-in risk policy is just a pre-built template.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Sign-in risk is the probability that a specific authentication attempt is not legitimate, evaluated in real-time or offline. User risk is the cumulative probability that a user's account has been compromised, based on multiple risky sign-ins over time. Sign-in risk policies control access at the time of sign-in (allow, block, MFA). User risk policies can force a password reset on next sign-in. For the SC-200 exam, remember that user risk is about the account, sign-in risk is about the event.
Atypical travel detection uses machine learning to compare the geographic location of a sign-in with the user's previous sign-in locations. If two sign-ins occur from locations that are too far apart to be physically possible within the time difference, the later sign-in is flagged as high risk. For example, a sign-in from New York and then from London within 1 hour would be flagged. The model learns the user's typical travel patterns over 14-30 days.
Yes. Instead of using the built-in sign-in risk policy, you can create a custom Conditional Access policy that includes 'Sign-in risk' as a condition. You can then choose 'Require device to be marked as compliant' as a grant control. This gives you more flexibility than the pre-built policy which only offers Allow, Block, or Require MFA.
The user receives a generic error message: 'Your sign-in was blocked. Contact your administrator.' The sign-in event is logged in the Risky sign-ins report with risk level 'High' and risk event type 'Blocked'. Administrators can review and dismiss or confirm the risk.
Risk events (detections) are retained for 30 days after the sign-in. After that, they are automatically deleted. The risky sign-in report shows events within the retention period.
Yes, sign-in risk policies apply to guest users when they sign in to your tenant. However, the policy can only target users in your directory. Guest users are subject to your tenant's Conditional Access policies, including sign-in risk conditions.
In the context of sign-in risk policy, the control 'Allow with MFA' means the user is allowed access only after completing MFA. This is functionally identical to 'Require MFA' in a Conditional Access policy. The exam may use the phrase 'Allow with MFA' as the exact wording from the portal.
You've just covered Entra ID Risk Policies and Sign-In Risk — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?