4.6 Microsoft Entra ID Protection and Risk

What ID Protection does

Microsoft Entra ID Protection automates the detection, investigation, and remediation of identity-based risk. Microsoft processes trillions of signals daily and uses machine learning to flag suspicious activity. ID Protection requires Microsoft Entra ID P2 — a key SC-900 licensing fact, since Conditional Access alone is only P1.

ID Protection surfaces its findings in three reports:

• Risky users — accounts that may be compromised (user risk).
• Risky sign-ins — individual authentications that look suspicious (sign-in risk).
• Risk detections — the underlying detected events that feed the two risk scores.

It does not replace authentication, Conditional Access, or governance — it adds risk context to them. The data it produces can also be exported to Microsoft Sentinel or queried via the Microsoft Graph API for SOC investigation.

Sign-in risk vs. user risk

ID Protection calculates two risk types, and the exam expects you to tell them apart:

Each is scored low / medium / high. User risk accumulates from all active detections on the account — most notably leaked credentials (the username/password appeared in a breach dump). Sign-in risk is evaluated per logon from real-time and offline detections.

Common risk detections SC-900 may name include: leaked credentials, sign-in from an anonymous IP address (e.g., Tor), impossible travel / atypical travel, unfamiliar sign-in properties, malware-linked IP address, password spray, and anomalous token. You do not need every detection memorized, but recognize them as identity-risk signals.

Risk-based Conditional Access

The power of ID Protection comes from feeding its risk levels into Conditional Access. Two special conditions — sign-in risk and user risk — let an organization respond automatically:

• Sign-in risk policy — if sign-in risk is medium or high, then require MFA (or block). This challenges the suspicious logon in real time.
• User risk policy — if user risk is high, then require a secure password change (self-service password reset), which both verifies the user and resets the possibly-leaked credential.

Because these are risk conditions, they require P2. Microsoft's recommended pattern is risk-based policies that allow self-remediation: a user who passes MFA clears their sign-in risk, and a user who completes a secure password change clears their user risk — lowering the risk level automatically without a help-desk call.

• Risky sign-in → require MFA.
• Risky user → require secure password change.
• Self-remediation → risk level drops automatically.

Product boundary and the Entra decision map

The name resembles other products, so keep the boundary sharp. Microsoft Entra ID Protection handles cloud identity risk (Entra accounts). Microsoft Defender for Identity is a Defender XDR product that protects on-premises Active Directory by analyzing domain-controller signals. Microsoft Sentinel is the SIEM/SOAR. Microsoft Purview is compliance. A question about risky sign-ins to Entra is ID Protection; a question about lateral movement against an on-prem domain controller is Defender for Identity.

Use this map for the whole Entra objective:

If wording shifts to incidents, hunting, and automation across many sources, the scenario has moved into Microsoft Sentinel.

Detection, investigation, and remediation in detail

ID Protection's value is the full loop of detect, investigate, remediate. On detection, Microsoft classifies signals as real-time (evaluated during sign-in, like impossible travel or anonymous IP) or offline (calculated after the fact, like leaked credentials surfaced from breach intelligence). Each detection raises the sign-in or user risk level.

On investigation, security teams use the risky users, risky sign-ins, and risk detections reports to see the affected accounts, the detection types, and the timeline; they can confirm an account as compromised, confirm a sign-in as safe (suppressing the risk), or dismiss the risk. On remediation, the goal is to return the account to a known-good state.

Remediation can be automatic or manual. Automatic remediation is the recommended path: a risk-based Conditional Access policy forces the user to self-remediate — completing MFA clears sign-in risk, and a secure password change via self-service password reset clears user risk because it both proves identity and replaces a possibly-leaked password. Manual remediation is when an administrator intervenes: reset the password, require the user to re-register MFA, block the user, or dismiss/confirm the risk after investigation.

The exam framing is that self-remediation scales (no help-desk ticket) while admins handle the cases that automation cannot.

Keep three precision facts ready. First, leaked credentials is the classic driver of user risk and is an offline detection — it may appear after the breach data is processed, not at sign-in. Second, ID Protection requires P2; without it you can see only a limited risk view. Third, ID Protection does not block by itself — it produces risk signals; the actual enforcement (challenge, block, password change) happens through Conditional Access. Confusing "detects risk" with "enforces access" is a common trap.

• Detect: real-time and offline detections raise risk levels.
• Investigate: confirm compromised, confirm safe, or dismiss.
• Remediate: self-service MFA / password change, or admin action.
• Enforcement happens in Conditional Access, not ID Protection itself.