Identity Protection Risk Policies in Microsoft Entra enable you to enforce blocking controls to user accounts if the Identity Protection service detects a user has an elevated risk level. These risk levels are determined at the user level or at the sign-in level. The user level detects risk activities linked to the user itself, such as leaked credentials, threat intelligence or suspicious activity. The sign-in risk level detects risky activities at the authentication request level, such as atypical travel, password spray attacks or unknown IP addresses.
When the feature was first released, policies were made available to configure controls to a user identity with an elevated risk level, such as requiring a password reset or blocking an account. These policies are now considered legacy and in this post, I will show you how to migrate them to Conditional Access policies.
When are Identity Protection risk policies retiring?
Microsoft have announced that the legacy risk policies in Microsoft Entra ID Protection will be retired on October 1st 2026.
Report Identity Protection risk policies
The first step to migration to Conditional Access policies is to report what configuration you currently have in place. To view this from the Microsoft Entra admin center, follow the below steps:
1. Log in to https://entra.microsoft.com/ as a global administrator.
2. Expand Protection and select Identity Protection.
3. Under protect, select User risk policy or Sign-risk policy.
4. Navigate to each policy and document the User, User risk and Controls.
It is currently not possible to view or manage these legacy policies with Microsoft Graph PowerShell.
Migration to Conditional Access policies
The simplest method to migrate these policies to Conditional Access is to use the Conditional Access templates feature in Microsoft Entra. Follow the below steps to migrate to Conditional Access policies for risk sign-in and users.
1. Log in to https://entra.microsoft.com/ as a global administrator.
2. Expand Protection and select Conditional Access.
3. Click Create new policy (If you have configured both user risk and sign-in risk, you should create two policies).
4. Define a name for your policy and configure the assignments to your target users and resources. Ideally, you should target all users and all cloud apps, then exclude your break-glass accounts.
5. On the Conditions section, define either the User risk OR Sign-in risk for a single policy.
6. Then, depending on the controls you wish to implement, on the Grant control section, either Block access or require a password change.
7. Now set the policy to report-only and save the policy.
8. Do the same with your second policy for either User or Sign-in risks, depending on if you are using both features.
Conditional Access provides much more granular controls over your identity security policies than the legacy identity protection policies. At this stage, you can also consider implementing supplementary controls, such as requiring device compliance or a stronger authentication method, in addition to or as an alternative to higher risk policies.
You can also create policies based on pre-defined templates from Microsoft. On the Conditional Access blade in Microsoft Entra, simply click Create new policy from templates and choose either of the available risk policies.
These policies can also be configured with Microsoft Graph PowerShell; see the following blog posts below for more:
Monitoring sign-in and enabling the Conditional Access policies
While your policies are in Report-only mode, you should continually monitor for what impact this will have on your users. At a high level, you already had the legacy policies enabled, so the impact shouldn’t be a significant worry. However, monitor the Conditional Access sign-in logs as well as the risk reports in Identity Protection to assess the impact.
Risky users and sign-ins
Conditional Access failure logs
When you are at a comfortable stage, enable the Conditional Access policies.
Disable the old Identity Protection risk policies
Follow the below steps to disable the old Identity Protection Risk policies once your Conditional Access policies are enabled.
1. Log in to https://entra.microsoft.com/ as a global administrator.
2. Expand Protection and select Identity Protection.
3. Navigate to both the User risk policy and Sign-in risk policy and set Policy enforcement to Disabled.
Wrapping up
The Identity Protection risk policies have now been considered a legacy for quite a while, although Microsoft has only recently defined a date for this retirement. Setting the retirement date so far in advance, customers have no excuse to complete this migration within good time.
I like this strategy, but this would be even more powerful if Microsoft exposed the different signal classifications to us so we could pick and choose. For example, this whole story gets problematic for us because of impossible travel and our VPN usage, so it would be great to be able to create alerts that excluded that, or included specific signals like leaked creds. Or is it there and I am missing it?
Are you using a corporate VPN? if so you can just add your IP’s as trusted locations.
Do you know if Microsoft has fixed the Secure Score so we are not penalized for disabling the old ID risk policies? When MS first came out with the recommendation to move these to CA, I disabled my old ID risk policies and they deducted points off my Secure Score. I reported it, but they never responded.
Not yet, but I’m sure they will!