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.
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?
