10.1 Planning for Identity Protection

Quick Answer: Entra ID Identity Protection turns Microsoft's threat intelligence and machine-learning signals into two risk scores — user risk (the probability the identity itself is compromised) and sign-in risk (the probability that a specific sign-in is not performed by the legitimate owner). Planning means deciding which risk-based policies to enforce, what thresholds to trigger on, and how users remediate. Risk-based policies and the Identity Protection reports require Entra ID P2 licensing for every user covered by a policy.

Microsoft Entra ID Identity Protection is a security service that detects identity-based risks and lets you automate a response. The MS-102 administrator plans it before configuring it: the planning choices determine what users experience and what the helpdesk has to support.

The Two Risk Scores

Identity Protection computes two distinct scores, and the distinction matters on the exam:

User risk is aggregated across detections tied to the user; sign-in risk is evaluated per authentication. A user can be high user risk with a low-risk sign-in (the identity is compromised but the attacker signs in from a familiar location), or low user risk with a high-risk sign-in (the legitimate user is on a new network). The two policies respond to these independently.

Licensing: Entra ID P2 Is Required

Identity Protection's risk-based policies (user risk policy and sign-in risk policy) and its three investigation reports (risky users, risky sign-ins, risk detections) are Entra ID P2 features. This means every user you include in a risk policy must be licensed for P2 — either directly, through Microsoft 365 E5, or through the Entra ID P2 add-on to a P1-based SKU like Microsoft 365 E3. Microsoft 365 E3 alone includes Entra ID P1, which is not sufficient. This licensing fact appears directly on MS-102.

Security Defaults vs Conditional Access

A core planning decision is which enforcement model you will use, because the two are mutually exclusive:

• Security Defaults — a free, tenant-wide baseline that requires MFA registration for all users, blocks legacy authentication, and protects privileged operations. It is all-or-nothing and cannot be scoped to groups.
• Conditional Access — licensed policies (Entra ID P1 minimum) that let you scope MFA, device compliance, and other controls to specific users, apps, and conditions.

If you plan to use Conditional Access — and you will, because Identity Protection risk-based policies are delivered as Conditional Access policies — you must turn Security Defaults off. Leaving Security Defaults on while trying to enforce Conditional Access is a common configuration error; the Entra admin center blocks creating Conditional Access policies while Security Defaults is enabled.

Risk Levels and Thresholds

Identity Protection classifies risk as Low, Medium, or High. When you plan a risk policy you choose which threshold triggers the policy:

• High — most conservative on user friction; fewest users interrupted
• Medium — balances detection and friction
• Low — most aggressive; interrupts the most sign-ins

Microsoft's documented starting point is not the same threshold for both policies: set the user risk policy to High and the sign-in risk policy to Medium and above. The asymmetry is deliberate — a high user risk implies the credential itself is likely compromised and warrants the friction of a forced password reset, whereas sign-in risk is evaluated per authentication and an MFA challenge is cheap enough to justify firing at medium. Use Report-only mode (a Conditional Access capability) to assess impact before enforcing. The threshold is ultimately a business decision: too low and helpdesk volume rises; too high and real compromise slips through.

Integration with Conditional Access

Identity Protection is not a standalone enforcement engine. User risk and sign-in risk are exposed as conditions in Conditional Access. When you create a Conditional Access policy, under Conditions you can add User risk and Sign-in risk and select the levels that trigger the policy. The policy then grants or blocks access based on those risk levels — for example, "If sign-in risk is High or Medium, require MFA; if High, block."

This is why the planning phase must settle the Conditional Access vs Security Defaults question first: you cannot consume risk as a condition if Security Defaults is still on.

Planning Checklist

• Confirm Entra ID P2 licensing for every user who will be in scope of a risk policy.
• Decide whether to enforce user risk policy, sign-in risk policy, or both, and at which threshold — Microsoft's recommended starting point is user risk = High and sign-in risk = Medium and above.
• Decide the remediation path — self-remediation via SSPR for user risk, MFA challenge for sign-in risk — and confirm SSPR and MFA registration are in place.
• Plan to disable Security Defaults before enabling Conditional Access-based risk policies.
• Identify break-glass / emergency access accounts and exclude them from every risk policy so a tenant-wide risk event does not lock out all admins.
• Plan to run new policies in Report-only first, then flip to On after reviewing the impact.