Entra ID Protection and risk policies

Microsoft Entra ID Protection detects identity-based risk, scores it, and feeds the result to Conditional Access so that policy can respond automatically. It tracks two different things: sign-in risk (this particular sign-in may not be the real user) and user risk (this account may be compromised). The decision rule for exams: sign-in risk is answered with multifactor authentication, user risk with a secure password change or risk remediation, and both need Microsoft Entra ID P2 for full use.

One incident, followed end to end

This guide explains ID Protection by following a single incident through its stages, because exam questions test the sequence.

Stage 1: detection. During each sign-in, ID Protection runs real-time detections and produces a sign-in risk level. Other detections run offline and may raise risk later. Examples from Microsoft’s catalogue: anonymous IP address, password spray, unfamiliar sign-in properties, atypical travel, malicious IP, leaked credentials, anomalous token, suspicious MFA approval. Leaked credentials is a user-risk detection, found offline; password spray and unfamiliar properties are sign-in detections.

Stage 2: scoring. Detections roll up into a risk level of low, medium or high. Active detections on a user feed the user risk level, which is the probability the account is compromised. The result is reported in three places: Risk detections (each event), Risky sign-ins (one or more detections on a sign-in) and Risky users (the user has risky sign-ins or detections).

Stage 3: policy decision. Conditional Access has two risk conditions, Sign-in risk and User risk, that read ID Protection’s levels. A policy decides what to require.

Stage 4: remediation. If the user satisfies the requirement, the risk is remediated automatically, with no administrator work. If the user cannot satisfy it, they are blocked and an administrator must unblock them.

Which control answers which risk

Microsoft warns against combining the two conditions in one policy; create one policy for each. The “Require risk remediation” grant control handles all authentication methods: for a password user it forces a secure password change after MFA and revokes previous sessions; for a passwordless user whose risk does not involve a compromised password it revokes sessions and forces sign-in again. It remediates user risk only, not sign-in risk, and it is not supported for external and guest users. If a user falls under several user-risk policies, Require risk remediation overrides Require password change, and Block overrides all.

A secure password change is a specific flow: the user knows the current password, passes MFA, and changes it. A normal password change outside that flow does not clear risk. A reset through self-service password reset also remediates user risk, but that is an account-recovery flow and a different thing.

Worked example

Priya signs in from a new country using a VPN exit node known as anonymous. ID Protection flags the sign-in as medium risk. Two policies exist: P-SignIn (require MFA when sign-in risk is medium or high) and P-User (require risk remediation when user risk is high).

• P-SignIn applies. Priya completes Authenticator MFA. The sign-in risk is remediated and she continues.
• Overnight, a leaked-credentials detection arrives for Priya’s account and her user risk becomes high. At the next sign-in P-User applies. She must complete MFA and change her password; previous sessions are revoked. Her user risk is cleared.
• Her colleague Tom has not registered for MFA. A medium-risk sign-in hits P-SignIn, he cannot satisfy it, and he is blocked until an administrator unblocks him. Microsoft’s guidance is that users must register for MFA before they need remediation, and hybrid users need password writeback.

Manual options remain for administrators: dismiss user risk, confirm a sign-in as safe, or confirm compromise. Dismissing and confirming need at least the Security Operator role. Risk policies are Conditional Access policies, so creating them needs at least Conditional Access Administrator; the legacy risk policies inside ID Protection were retired on October 1, 2026. Reading the reports works with Security Reader or Global Reader.

Licensing and scope

Details change, so check them against Microsoft’s page, but the exam-stable pattern is:

• Risk-based Conditional Access policies and full detection detail need Microsoft Entra ID P2 (the Entra Suite also qualifies).
• Without P2 you still receive some detections, shown as “Additional risk detected” without details.
• Risky workload identities (apps and service principals) have their own reports; full details and risk-based access controls need Workload Identities Premium. Managed identities are not currently in scope of those detections, which links to managed identities vs service principals.
• Risk data can be exported through Microsoft Graph, diagnostic settings, or a Microsoft Sentinel connector; see Sentinel explained.

Which exams test this

Rows for SC-300, SC-900, SC-200 and AB-900 follow the English outlines that apply from October 28, October 21, October 21 and October 14, 2026; their change logs list only minor changes.

How questions are built around it

The scenario describes a detection or desired automation, and the options mix risk types, controls and licences. Look for these cues:

• “Leaked credentials”: user risk, so password change or risk remediation, not MFA.
• “Unfamiliar location”, “anonymous IP”, “atypical travel”: sign-in risk, so MFA.
• “Without administrator involvement” or “self-remediate”: a risk-based policy, not manual dismissal.
• “Least privilege to dismiss user risk”: Security Operator. “To create risk policies” or “Conditional Access policies”: Conditional Access Administrator. Older material that places user and sign-in risk policies in the ID Protection blade describes the legacy policies retired on October 1, 2026.
• “Block until investigated”: block access, but note the lockout risk; break-glass accounts must be excluded.
• Licences: a P1-only tenant cannot use risk conditions; the options offering P1 features are traps.

Another trap is confusing ID Protection with Conditional Access itself. ID Protection produces risk levels; Conditional Access enforces. For compromised sessions, Defender XDR correlates identity alerts with endpoint and email signals. Stronger sign-in methods reduce the risk to begin with; see MFA, passwordless and passkeys.

Practice questions

Go deeper

• What is Microsoft Entra ID Protection? (Microsoft Learn)
• What is risk? Detections and riskEventType (Microsoft Learn)
• Configure risk policies (Microsoft Learn)
• Remediate risks and unblock users (Microsoft Learn)
• Related: the SC-300 practice test and how to study for certification exams.