Microsoft Entra ID Protection watches every sign-in and every account for signs of compromise, then hands that risk score to Conditional Access. Entra ID Protection risk policies are how you turn that score into action: an extra MFA prompt when a sign-in looks suspicious, or a forced secure password change when an account looks compromised. The two risk types are easy to confuse, and mixing them up leads to policies that either nag everyone or catch nothing.
Here is what each one means, the policies I recommend for most businesses, and what changed when Microsoft retired the old ID Protection policy pages.
Sign-in risk and user risk in one sentence each
Sign-in risk is the probability that this particular sign-in isn’t being made by the account owner. It is calculated in real time, during the sign-in.
User risk is the probability that the account itself is compromised. It builds up over time from signals like leaked credentials or a pattern of risky sign-ins.
A useful way to think about it: sign-in risk asks “is this you, right now?”, and user risk asks “has someone else got your password?”.
Leaked credentials, threat intelligence on the account, an accumulation of risky sign-ins
Typical response
Require MFA (ideally phishing-resistant) and reauthenticate every time
Require risk remediation or a secure password change
How it clears
User passes the MFA challenge
User completes the remediation, or an admin dismisses or confirms the risk
Recommended trigger
Medium and high
High
Licensing: what you actually need
Risk-based Conditional Access policies require Microsoft Entra ID P2, which is included in Microsoft 365 E5 and the Microsoft Entra Suite, or available as an add-on. Microsoft 365 Business Premium includes Entra ID P1, which gives you Conditional Access but not the risk conditions. Tenants on Free or P1 can see some risk information in reports, but can’t use risk in policies.
If you are on Business Premium and wondering whether P2 is worth it, our E5 vs E3 calculator helps compare the costs against the add-on route.
The old policies are gone: move to Conditional Access
ID Protection used to have its own User risk policy and Sign-in risk policy pages. Those legacy policies retired on October 1, 2026. If your tenant had them configured, check that equivalent Conditional Access policies exist and are enforced. Microsoft’s impact workbook includes a section that shows whether legacy policies are still present.
Building them in Conditional Access is better anyway. You get report-only mode, sign-in frequency control, combined conditions such as risk plus location, multiple policies for different groups, and clearer sign-in logs that show which risk policy applied.
Recommended policies
I deploy two separate policies. Microsoft specifically recommends not combining sign-in risk and user risk in the same policy.
Policy 1: Sign-in risk
In Entra ID > Conditional Access > Policies, create a new policy, for example CA007-All-AllApps-SignInRisk-MFA.
Users: include All users. Exclude emergency access accounts.
Target resources: All resources.
Conditions: Sign-in risk, set to High and Medium.
Grant: Require authentication strength. Use Multifactor authentication to start, or Phishing-resistant MFA for users who already have passkeys.
Session: Sign-in frequency set to Every time, so a risky sign-in can’t ride on an earlier MFA claim.
Start in report-only, then turn on.
Policy 2: User risk
Create CA008-All-AllApps-UserRisk-Remediate.
Users: All users, excluding emergency access accounts.
Target resources: All resources.
Conditions: User risk set to High.
Grant: Require risk remediation where available, which lets ID Protection pick the right remediation flow for the user’s authentication method. Otherwise use Require password change, which also requires MFA.
Session: Sign-in frequency set to Every time.
Report-only first, then on.
Some organizations choose to trigger user risk at medium as well. That catches more, at the cost of more forced remediations. For most 20 to 500 person businesses I start at high and review the risky users report monthly to decide whether to tighten.
Self-remediation and why MFA registration matters
The real value of these policies is that users fix their own risk. When a medium-risk sign-in is challenged and the user passes MFA, the risk is closed. When a high-risk user completes a secure password change, their user risk is remediated. No ticket, no admin investigation for the routine cases.
That only works if users have already registered a method that can satisfy MFA. A user with no registered method who hits a risk policy is simply blocked. Before you enforce risk policies, make sure registration coverage is close to complete. Our MFA enablement work usually comes first for this reason.
Password change remediation for synced accounts also needs password writeback configured, so the new password reaches on-premises Active Directory.
Testing before you enforce
Risk events are relatively rare, so a week of report-only might not show much. Two tools help:
The Impact analysis of risk-based access policies workbook, under ID Protection > Dashboard, estimates the effect of risk policies from existing sign-in logs without waiting. It needs sign-in logs in a Log Analytics workspace.
The Risky users and Risky sign-ins reports show what ID Protection has already flagged, which tells you how many people would have been challenged.
Also make sure your office public IP ranges are defined as trusted named locations. That improves the accuracy of risk calculations and reduces false positives.
Self-remediation handles most cases, but someone should still look at the reports. A 30-minute monthly routine is enough for most small and mid-sized businesses:
Open the Risky users report and sort by risk level. Anyone still at high risk who hasn’t remediated needs a call.
Check the Risk detections list for patterns: the same anonymous IP across several users, or leaked credentials for a shared account.
Confirm compromise for any account you know was taken over, so ID Protection learns from it, and dismiss risk only when you are sure it was a false positive.
Look for users who keep triggering sign-in risk from the same location. That often means a home VPN or travel pattern worth adding to your notes, not a policy exception.
Record what you found. Over a few months the notes show whether thresholds need tightening.
Frequently asked questions
Can I use risk policies with Microsoft 365 Business Premium?
Not on their own. Business Premium includes Entra ID P1, and risk-based conditions need Entra ID P2. You can add Entra ID P2 licenses for the users you want covered, or move to a plan that includes it.
Should I block high-risk sign-ins instead of requiring MFA?
Blocking is stricter but stops the user from self-remediating, which means every block becomes a helpdesk ticket. For most businesses, requiring strong MFA with sign-in frequency set to every time is the better balance. Blocking can make sense for admin accounts.
What happens to a user flagged as high risk who can’t change their password?
They are blocked until the risk is remediated. An admin can review the user in the Risky users report, then reset the password, confirm the compromise or dismiss the risk if it was a false positive.
Not sure whether risk policies are configured, or still pointing at the retired pages? Get a free Microsoft 365 security assessment and we’ll check your ID Protection setup, licensing and Conditional Access coverage.
Microsoft Entra ID Protection watches every sign-in and every account for signs of compromise, then hands that risk score to Conditional Access. Entra ID Protection risk policies are how you turn that score into action: an extra MFA prompt when a sign-in looks suspicious, or a forced secure password change when an account looks compromised. The two risk types are easy to confuse, and mixing them up leads to policies that either nag everyone or catch nothing.
Here is what each one means, the policies I recommend for most businesses, and what changed when Microsoft retired the old ID Protection policy pages.
Sign-in risk and user risk in one sentence each
A useful way to think about it: sign-in risk asks “is this you, right now?”, and user risk asks “has someone else got your password?”.
Licensing: what you actually need
Risk-based Conditional Access policies require Microsoft Entra ID P2, which is included in Microsoft 365 E5 and the Microsoft Entra Suite, or available as an add-on. Microsoft 365 Business Premium includes Entra ID P1, which gives you Conditional Access but not the risk conditions. Tenants on Free or P1 can see some risk information in reports, but can’t use risk in policies.
If you are on Business Premium and wondering whether P2 is worth it, our E5 vs E3 calculator helps compare the costs against the add-on route.
The old policies are gone: move to Conditional Access
ID Protection used to have its own User risk policy and Sign-in risk policy pages. Those legacy policies retired on October 1, 2026. If your tenant had them configured, check that equivalent Conditional Access policies exist and are enforced. Microsoft’s impact workbook includes a section that shows whether legacy policies are still present.
Building them in Conditional Access is better anyway. You get report-only mode, sign-in frequency control, combined conditions such as risk plus location, multiple policies for different groups, and clearer sign-in logs that show which risk policy applied.
Recommended policies
I deploy two separate policies. Microsoft specifically recommends not combining sign-in risk and user risk in the same policy.
Policy 1: Sign-in risk
Entra ID > Conditional Access > Policies, create a new policy, for exampleCA007-All-AllApps-SignInRisk-MFA.Policy 2: User risk
CA008-All-AllApps-UserRisk-Remediate.Some organizations choose to trigger user risk at medium as well. That catches more, at the cost of more forced remediations. For most 20 to 500 person businesses I start at high and review the risky users report monthly to decide whether to tighten.
Self-remediation and why MFA registration matters
The real value of these policies is that users fix their own risk. When a medium-risk sign-in is challenged and the user passes MFA, the risk is closed. When a high-risk user completes a secure password change, their user risk is remediated. No ticket, no admin investigation for the routine cases.
That only works if users have already registered a method that can satisfy MFA. A user with no registered method who hits a risk policy is simply blocked. Before you enforce risk policies, make sure registration coverage is close to complete. Our MFA enablement work usually comes first for this reason.
Password change remediation for synced accounts also needs password writeback configured, so the new password reaches on-premises Active Directory.
Testing before you enforce
Risk events are relatively rare, so a week of report-only might not show much. Two tools help:
ID Protection > Dashboard, estimates the effect of risk policies from existing sign-in logs without waiting. It needs sign-in logs in a Log Analytics workspace.Also make sure your office public IP ranges are defined as trusted named locations. That improves the accuracy of risk calculations and reduces false positives.
Microsoft’s article on configuring and enabling risk policies covers the full set of options. If you want someone watching the alerts that these policies don’t auto-remediate, that is part of our managed security service.
A monthly risk review routine
Self-remediation handles most cases, but someone should still look at the reports. A 30-minute monthly routine is enough for most small and mid-sized businesses:
Frequently asked questions
Can I use risk policies with Microsoft 365 Business Premium?
Not on their own. Business Premium includes Entra ID P1, and risk-based conditions need Entra ID P2. You can add Entra ID P2 licenses for the users you want covered, or move to a plan that includes it.
Should I block high-risk sign-ins instead of requiring MFA?
Blocking is stricter but stops the user from self-remediating, which means every block becomes a helpdesk ticket. For most businesses, requiring strong MFA with sign-in frequency set to every time is the better balance. Blocking can make sense for admin accounts.
What happens to a user flagged as high risk who can’t change their password?
They are blocked until the risk is remediated. An admin can review the user in the Risky users report, then reset the password, confirm the compromise or dismiss the risk if it was a false positive.
Not sure whether risk policies are configured, or still pointing at the retired pages? Get a free Microsoft 365 security assessment and we’ll check your ID Protection setup, licensing and Conditional Access coverage.