10.2 Implementing Entra Identity Protection

Quick Answer: In the Entra admin center, under Protection > Identity Protection, you configure three policies: the MFA registration policy (require users to register for MFA), the sign-in risk policy (require MFA or block based on sign-in risk level), and the user risk policy (require a secure password reset or block based on user risk level). You monitor through three reports — risky users, risky sign-ins, and risk detections — and you remediate through self-service password reset, MFA challenge, or manual admin dismissal.

The Three Policies

Identity Protection is implemented through three policy blades in the Entra admin center. Each is a Conditional Access policy under the hood but is surfaced with a simplified UI:

1. MFA Registration Policy

Requires users to register for MFA within a given number of days. It does not enforce MFA on sign-in — it only drives registration so that the other two policies can use MFA as a remediation. You scope it to users (typically all users except break-glass accounts) and set the registration window (default 14 days). Users see a banner at sign-in prompting them to register.

2. Sign-in Risk Policy

Triggers when a sign-in's risk level meets the threshold you set. The remediation options are:

• Require MFA — let the user prove the sign-in is legitimate by completing an MFA challenge
• Block access — deny the sign-in outright (use for High risk where MFA is not enough)

You choose the risk level threshold (Low/Medium/High) and the users in scope. A sign-in that passes MFA remediation is marked as risk-confirmed-safe; the user continues uninterrupted.

3. User Risk Policy

Triggers when a user's overall risk level meets the threshold. Because user risk implies the identity itself may be compromised, the remediation is stronger:

• Require secure password reset — the user must perform a self-service password reset (SSPR), which requires SSPR to be configured and the user to be registered for it
• Block access — deny sign-in until an admin investigates

A successful SSPR clears the user's risk so they can sign in normally afterward.

The Three Reports

Identity Protection gives you three investigation surfaces:

From Risky users you can choose Confirm user compromised (which blocks the user and requires admin reset) or Dismiss user risk (used when you have verified the activity was legitimate). Dismissing risk feeds back into Microsoft's models and tunes future detection for the tenant.

Risk Detections Identity Protection Surfaces

These are the conceptual detections you should recognize on the exam:

• Impossible travel — sign-ins from geographically distant locations within a timeframe that real travel could not bridge
• Anonymous IP — sign-in from an anonymizer, Tor, or VPN known to hide identity
• Malicious IP — sign-in from an IP linked to known malware or botnet infrastructure
• Unfamiliar sign-in properties — sign-in from a new location, device, or browser that does not match the user's baseline
• Leaked credentials — Microsoft has evidence the user's credentials appear in a public breach dump
• Password spray — many accounts attacked with a common password list; a successful spray raises user risk
• Token theft (preview) — refresh or session tokens stolen and replayed from an attacker-controlled environment

Each detection contributes a probability weight to either user risk or sign-in risk. Leaked credentials and password spray most strongly raise user risk; impossible travel and anonymous IP most strongly raise sign-in risk.

Remediation Paths

Remediation can be self-service or admin-driven:

• Self-remediation (sign-in risk) — the user completes an MFA challenge at sign-in. On success the sign-in is allowed and the detection is marked safe.
• Self-remediation (user risk) — the user performs SSPR, which requires SSPR to be enabled and the user registered for the required methods. On success, user risk is cleared.
• Admin manual dismissal — when a detection is a confirmed false positive (for example, a legitimate new-office sign-in flagged as unfamiliar), an admin dismisses the risk from the risky users or risky sign-ins report. Dismissing helps Microsoft's models learn the tenant's normal patterns.
• Admin confirmation of compromise — when compromise is real, the admin confirms the user compromised, which blocks the account and forces an admin-driven password reset.

Operational Workflow

1. Configure the MFA registration policy first so users are registered.
2. Configure the user risk policy at High and the sign-in risk policy at Medium and above, both in Report-only mode first.
3. Review the report-only results in the Conditional Access Insights and reporting workbook.
4. Flip the policies to On once impact is acceptable.
5. Monitor the risky users and risky sign-ins reports daily; tune thresholds based on noise.
6. Use the risk detections report to investigate patterns (for example, repeated impossible-travel from one country) and feed the findings back into named locations or policy exclusions.