Microsoft Entra ID Protection & Risk-Based Conditional Access

Microsoft Entra ID Protection analyzes identity signals and assigns:

• Sign-in risk: likelihood that a specific authentication request is not performed by the identity owner.
• User risk: likelihood that the identity itself is compromised.
• Risk detections: individual signals such as leaked credentials, unfamiliar sign-in properties, anonymous IP, atypical travel, suspicious browser/token activity, or integrated Defender signals.

Use Microsoft Entra Conditional Access for current automated response. The legacy user-risk and sign-in-risk policies configured inside the Identity Protection blade are scheduled for retirement on October 1, 2026 and should be migrated before that date.

---

• Full ID Protection risk investigation and risk-based Conditional Access require Microsoft Entra ID P2 or Microsoft Entra Suite licensing for targeted users.
• Conditional Access Administrator is the least-privileged role for policy creation/editing.
• Security Operator or Security Administrator capabilities can investigate and confirm/dismiss risk according to current role permissions.
• Some detections require additional Defender services or licenses; do not assume every tenant receives every detection.

---

Microsoft warns against combining user risk and sign-in risk in one Conditional Access policy. Create separate policies.

Sign-in risk policy

Microsoft's current baseline recommendation is:

• include intended users, commonly all users after staged validation
• exclude monitored emergency-access accounts
• target all resources
• condition: Medium and High sign-in risk
• grant: require an appropriate authentication strength, commonly MFA
• session: sign-in frequency Every time
• start in report-only mode

The user must already be registered for an allowed authentication method. Risky sessions cannot be used to register MFA; an unregistered user is blocked and can receive AADSTS53004.

User risk policy

Microsoft's current recommendation is:

• condition: High user risk
• grant: Require risk remediation
• start in report-only mode

When Require risk remediation is selected, Conditional Access automatically applies an authentication-strength grant and sign-in frequency Every time. For password users, successful strong authentication can lead to secure password change. For passwordless users, the remediation flow revokes sessions and requires reauthentication according to the supported experience.

Hybrid users need password writeback for a cloud secure password change to update on-premises AD.

---

---

1. Inventory legacy ID Protection user-risk and sign-in-risk policies.
2. Create equivalent, separate Conditional Access policies in report-only mode.
3. Exclude emergency-access accounts and handle workload identities separately.
4. Verify user registration and hybrid password writeback.
5. Analyze report-only sign-ins and existing active risks.
6. Enable the Conditional Access policies in stages.
7. Disable the legacy ID Protection risk policies.
8. Confirm no duplicate or contradictory policy remains.

Do not wait until retirement day; policy migration requires registration, support, and false-positive validation.

---

1. Open the risky user or sign-in.
2. Review:

• detection type and timing
• IP, ASN, country, device, client, and authentication details
• interactive and non-interactive sign-ins
• related Defender XDR incidents and alerts
• user reports of suspicious MFA activity

1. Contact the user through a trusted channel when appropriate.
2. Determine whether the activity is compromised, safe, or unresolved.
3. Apply identity containment independently when compromise is likely:

• disable/block sign-in where necessary
• revoke sessions
• reset credentials or require supported remediation
• remove malicious authentication methods/app consent
• investigate mailbox, endpoints, and applications

1. Record the decision and evidence.

Risk-policy automation is not a substitute for incident response.

---

• Confirm user compromised moves the user to high risk and informs detection/remediation workflows. It does not by itself guarantee that every session is immediately revoked; perform required containment actions.
• Confirm sign-in safe marks the selected sign-in as safe and helps reduce false positives.
• Dismiss user risk resets the user's risk state after investigation; it does not change the user's password and is not evidence that a compromise was remediated.
• Block user prevents sign-in but should be paired with investigation and recovery.

Use these actions only after evidence review and with the appropriate role.

---

---

---

• Register strong authentication before risk-policy enforcement.
• Prefer phishing-resistant authentication methods.
• Use report-only and representative pilot data.
• Investigate noninteractive sign-ins and token-related detections.
• Integrate ID Protection with Defender XDR/SOC workflow.
• Alert on high-risk users and emergency-account activity.
• Limit risk dismissal permissions.
• Complete migration from legacy risk policies before October 1, 2026.

---

---

• Configure and enable risk policies
• Require MFA for elevated sign-in risk
• Require remediation for risky users
• What are risk detections?
• Remediate risks and unblock users
• Investigate risk