3.4.4. Microsoft Entra ID Protection
💡 First Principle: Identity Protection continuously evaluates sign-in and user behavior for risk signals — impossible travel, leaked credentials, unfamiliar sign-in properties — and assigns a risk level that Conditional Access policies can then act on automatically, closing the loop between "detecting something looks wrong" and "actually doing something about it."
Identity Protection distinguishes sign-in risk (is this specific sign-in attempt suspicious — e.g., from a new country with no prior history) from user risk (is this user's account likely compromised overall — e.g., their credentials appeared in a leaked-credentials feed). A risk-based Conditional Access policy might require MFA on medium sign-in risk, but force a password reset entirely on high user risk.
⚠️ Exam Trap: Identity Protection detects and scores risk; it's Conditional Access policies (3.3.1), configured to respond to that risk level, that actually enforce a control like blocking access or requiring MFA — the two work together but perform different jobs.
Licensing note: Conditional Access requires Microsoft Entra ID P1. The full Identity Protection risk detections and Privileged Identity Management require Microsoft Entra ID P2 (or Microsoft Entra ID Governance for PIM), so exam scenarios that mention these capabilities assume the higher tiers.
Reflection Question: A user's credentials show up in a known leaked-credentials dataset, but their most recent sign-in looks completely normal. Is this a sign-in risk or a user risk, and why does the distinction matter for what action should be taken?
