Agent Foskett Academy • Microsoft Entra • Module 2 • Lesson 20

Lesson 20 — Microsoft Entra Identity Protection Policies

Microsoft Entra Identity Protection detects suspicious identity activity and assigns risk to sign-ins and users.

Those signals become operational controls when they are connected to Conditional Access. A risky sign-in can require multifactor authentication. A risky user can be required to complete a secure password change. Severe or unresolvable risk can be blocked and investigated.

This lesson explains sign-in risk, user risk, risk detections, remediation, policy design and the migration away from legacy Identity Protection policies before their retirement on October 1, 2026.

Risk detection becomes protection only when a policy responds to it.

Start Lesson Back to Microsoft Entra Academy

Agent Foskett Microsoft Entra Identity Protection Policies lesson

What you will learn

This lesson explains how Microsoft Entra risk detections trigger automated identity protection through Conditional Access.

Sign-in risk

User risk

Risk remediation

Conditional Access

Learning objectives

After completing this lesson, you should be able to design and investigate Microsoft Entra Identity Protection policies.

Explain sign-in risk and user risk.
Describe common risk detections.
Build risk-based Conditional Access policies.
Require MFA for risky sign-ins.
Require secure password change for risky users.
Plan policy exclusions and emergency access.
Investigate and remediate identity risk.

The problem this solves

A correct password does not prove that the genuine user is signing in.

Credentials may be stolen, leaked, sprayed, replayed or used from infrastructure associated with malicious activity.

What is Microsoft Entra Identity Protection?

Microsoft Entra Identity Protection detects, investigates and helps remediate identity-based risk.

Sign-in activity occurs ↓ Microsoft evaluates identity signals ↓ A risk detection is generated ↓ Sign-in risk or user risk is calculated ↓ Conditional Access evaluates the risk ↓ Allow, require MFA, require password change or block ↓ Risk is remediated or investigated

Sign-in risk

Sign-in risk represents the probability that a specific authentication request was not performed by the legitimate identity owner.

It applies to one sign-in event and can change as Microsoft receives more evidence.

User risk

User risk represents the probability that the identity itself has been compromised.

It considers unresolved detections and suspicious activity associated with the account over time.

Sign-in risk vs user risk

Risk type	Question being answered	Typical policy response
Sign-in risk	Is this authentication request likely to be unauthorised?	Require MFA or block the sign-in.
User risk	Is this identity likely to be compromised?	Require secure password change or block access.

Risk levels

Risk is commonly classified as low, medium or high.

Policy design should match the confidence and impact of the detected activity rather than treating every signal identically.

Risk state

A detection can remain at risk, become remediated, be dismissed, be confirmed compromised or be confirmed safe.

The state records what happened after the original detection.

Examples of risk detections

Detection	What it may indicate	Investigation focus
Atypical travel	Sign-ins occurred from distant locations in an unusual timeframe.	Device, IP address, travel history and session continuity.
Anonymous IP address	The sign-in used Tor, VPN or anonymising infrastructure.	Whether the service is legitimate or attacker-controlled.
Unfamiliar sign-in properties	The device, browser, location or network differs from normal behaviour.	Compare with the user’s established sign-in pattern.
Leaked credentials	Microsoft has identified credentials associated with exposure.	Immediate password reset, session revocation and impact review.
Malicious IP address	The source has known malicious reputation or observed attack activity.	Cross-user attempts and successful access.
Password spray	A common password is attempted across many accounts.	Source infrastructure, targeted users and successful sign-ins.

Real-time detections

Some risk detections are evaluated during the sign-in process.

Conditional Access can respond immediately before access is granted.

Offline detections

Other detections require additional processing and appear after the sign-in has completed.

These may raise user risk and require investigation or later remediation.

Modern risk-policy architecture

Microsoft Entra ID Protection ↓ Risk signals and detections ↓ Conditional Access assignments ↓ Sign-in risk condition OR User risk condition ↓ Grant control ↓ Require MFA, require password change or block

Legacy policy retirement

The legacy user-risk and sign-in-risk policies configured directly in Identity Protection retire on October 1, 2026.

Organisations should migrate these controls to Conditional Access.

Why Conditional Access?

Conditional Access provides broader scoping, exclusions, report-only deployment, authentication strengths, session controls and consistent policy management.

It is the modern enforcement path for Identity Protection signals.

Policy 1 — Require MFA for risky sign-ins

Include target users ↓ Target resources ↓ Condition: Sign-in risk ↓ Select medium and high risk ↓ Grant access ↓ Require multifactor authentication ↓ Start in Report-only mode ↓ Review impact and enable

Why require MFA?

A stolen password may satisfy the first authentication factor.

Requiring MFA gives the legitimate user an opportunity to prove possession of an additional registered method.

When to block

Blocking may be appropriate when risk is high, remediation is unavailable or the account is too sensitive to permit self-service access.

Blocking should be paired with a clear investigation and recovery process.

Policy 2 — Require remediation for risky users

Include target users ↓ Target resources ↓ Condition: User risk ↓ Select high risk ↓ Grant access ↓ Require multifactor authentication AND Require password change ↓ User proves identity and changes password securely ↓ Risk is remediated

Secure password change

Self-service remediation requires the user to complete MFA before changing the compromised password.

This prevents an attacker who only knows the password from replacing it with another attacker-controlled value.

Prerequisites

Users need appropriate licensing, registered authentication methods and Self-Service Password Reset capability.

Hybrid users also require correctly configured password writeback when the password must be changed in Active Directory.

Emergency access accounts

Emergency access accounts should be excluded from user-based Conditional Access policies to avoid complete administrative lockout.

Their sign-ins must be separately protected, monitored and alerted.

Service accounts

Traditional user-based risk remediation may not suit noninteractive service accounts.

Move workloads toward managed identities or service principals and apply workload-specific controls.

Safe deployment process

1. Review current risky users and risky sign-ins ↓ 2. Identify existing legacy risk policies ↓ 3. Define exclusions and emergency access ↓ 4. Create Conditional Access policies ↓ 5. Use Report-only mode ↓ 6. Review the risk-policy impact workbook ↓ 7. Validate MFA and SSPR registration ↓ 8. Pilot with a controlled group ↓ 9. Enable enforcement ↓ 10. Retire legacy policies before October 1, 2026

Report-only mode

Report-only mode shows how the policy would evaluate without enforcing its grant controls.

Use sign-in logs and Conditional Access results to detect unexpected scope or access impact.

Impact analysis

The risk-based access policy impact workbook helps estimate which users and sign-ins would be challenged, remediated or blocked.

This is valuable before broad enforcement.

Remediation outcomes

Outcome	Meaning	Use
Self-remediated	The user successfully completed the required secure action.	Risk can be cleared automatically.
Admin confirmed safe	Investigation determined the activity was legitimate.	Close a false positive with evidence.
Admin confirmed compromised	Investigation confirmed attacker activity.	Trigger containment, reset and impact review.
Risk dismissed	An administrator manually closed the risk.	Use cautiously and document the reason.
User blocked	Access is prevented pending investigation.	Contain severe or unresolved identity risk.

Agent Foskett investigation: “The user completed MFA, but the account is still risky”

1. Open the risky user record ↓ 2. Review every active risk detection ↓ 3. Separate sign-in risk from user risk ↓ 4. Confirm whether MFA was completed during the risky sign-in ↓ 5. Check whether secure password change was required ↓ 6. Review successful sessions after the detection ↓ 7. Inspect devices, applications and IP addresses ↓ 8. Revoke sessions if compromise remains possible ↓ 9. Reset credentials and authentication methods if required ↓ 10. Confirm safe, confirm compromised or allow policy remediation

Compromise indicators

Successful access from malicious infrastructure.
Leaked credentials detection.
New MFA methods registered unexpectedly.
Inbox rules, OAuth consent or privilege changes follow the sign-in.
Multiple users are targeted from the same source.
The user denies the activity.

False-positive indicators

The user confirms travel or VPN usage.
The device and session are known and managed.
No suspicious post-authentication activity occurred.
The source belongs to an approved corporate service.
The detection is explained by a documented network change.
Authentication and endpoint evidence agree.

Real-world scenario: MFA stopped the password attacker

1. An attacker obtains a valid password ↓ 2. The attacker signs in from unfamiliar infrastructure ↓ 3. Microsoft Entra raises sign-in risk ↓ 4. Conditional Access requires MFA ↓ 5. The attacker cannot satisfy the second factor ↓ 6. Access is denied ↓ 7. Agent Foskett reviews the failed attempt ↓ 8. Sessions are revoked and the password is reset ↓ 9. The user confirms the sign-in was not theirs ↓ 10. The event is documented as prevented credential compromise

Common mistakes

Mistake	Impact	Better practice
Leaving legacy risk policies in place	Controls face retirement and fragmented management.	Migrate to Conditional Access before October 1, 2026.
Enabling broad blocking immediately	Legitimate users may be locked out.	Use Report-only mode and staged deployment.
Ignoring MFA and SSPR readiness	Users cannot self-remediate safely.	Complete registration before enforcement.
Excluding too many users	High-risk identities remain unprotected.	Keep exclusions minimal and documented.
Dismissing risk without investigation	Compromise evidence may be erased operationally.	Correlate sign-ins, devices and post-authentication activity.
Treating MFA success as proof of safety	Token theft or compromised methods may be missed.	Review the full identity timeline.

Key takeaways

Sign-in risk measures the likelihood that one authentication request is unauthorised.
User risk measures the likelihood that the identity is compromised.
Identity Protection risk signals should be enforced through Conditional Access.
Medium or high sign-in risk can require MFA.
High user risk can require secure password change.
Legacy Identity Protection risk policies retire on October 1, 2026.
Report-only mode, impact analysis and staged deployment reduce operational risk.
MFA, SSPR and password writeback readiness are essential for self-remediation.
Risk should be investigated using sign-in, endpoint, application and post-authentication evidence.

Related Agent Foskett resources

Continue developing Microsoft Entra risk, authentication and identity investigation skills.

Lesson 19 — Smart Lockout Lesson 18 — Microsoft Entra Password Protection Lesson 17 — Self-Service Password Reset Lesson 3 — Conditional Access Fundamentals Lesson 5 — Risky Users and Risky Sign-ins Microsoft Identity and Access Services

Continue learning

Continue through Microsoft Entra identity security, or return to the academy roadmap.

⬅ Previous lesson

Lesson 19 — Smart Lockout in Microsoft EntraUnderstand password attack detection, lockout behaviour and hybrid policy alignment.

🏠 Academy home

Microsoft Entra AcademyReview the roadmap and continue through the identity security learning path.

📘 Next lesson

Lesson 21 — Microsoft Entra Sign-in DiagnosticsLearn how to troubleshoot authentication failures, Conditional Access decisions and interrupted sign-ins.

Microsoft Entra Identity Protection Risk Policies and Conditional Access

Microsoft Entra Identity Protection detects risky users and risky sign-ins, then supplies those signals to Conditional Access for multifactor authentication, secure password change, blocking and automated remediation.

Microsoft Entra Academy Lesson 20 — Identity Protection Policies

This Agent Foskett lesson explains user risk, sign-in risk, risk detections, Conditional Access design, MFA challenges, secure password remediation, investigation workflows and migration from legacy Identity Protection policies before October 1, 2026.