In a lot of the Microsoft Entra tenants I work in, the old user and sign-in risk policies from legacy Identity Protection are still switched on, and nobody has looked at them in a long time. Someone configured them once, and they have often sat untouched for years. Microsoft has been recommending a different approach for a while now: move those risk policies into Conditional Access, which is where they belong. If you care about security and about keeping your policies manageable, this migration is more than a box to tick. It finally lets you combine risk with the conditions, exclusions and controls that Conditional Access supports today.

Conditional Access gives risk policies the flexibility they lacked

The legacy Identity Protection policies were a reasonable first step, but they feel clumsy now. You can barely combine risk with other conditions, proper exclusions don't exist, and it's hard to see in advance what a change will do. Once the risk policies live in Conditional Access, you get some concrete advantages:

  • Richer conditions: Combine risk detection with device, location, app or user group requirements.
  • Exclusions and granularity: Protect high-value accounts or service accounts specifically, or exclude them when you need to.
  • Report-only mode: Test a policy without risk before you enforce it.
  • Combine with authentication strengths and sign-in frequency: Require passwordless sign-in or force re-authentication every time.
  • Policy templates: Start from Microsoft's ready-made risk-based templates.

In my experience, many organizations use the migration to tidy up Conditional Access as a whole, getting rid of old complexity and bringing their policy design up to date.

Microsoft provides templates for risk-based Conditional Access policies

The Conditional Access blade in the Microsoft Entra admin center includes templates specifically for risk-based policies. These starting points ("require MFA for sign-in risk", "require password change for user risk") follow Microsoft's best practices, and you can adjust them to what your organization actually needs. You no longer configure risk in the old Identity Protection blade. You create a Conditional Access policy and add user or sign-in risk as a condition.

Microsoft's documentation covers the background and the official guidance: Identity Protection policy concepts, configuring risk policies and risk-based Conditional Access.

The diagram below shows how risk-based enforcement runs through the legacy path compared with the Conditional Access path:

graph TD
    LegacyPolicy["Legacy ID Protection policy"]
    CA["Conditional Access policy"]
    RiskDetection["Risk detected"]
    LegacyEnforcement["Enforcement (MFA, password change)"]
    CAConditions["Additional conditions and exclusions"]
    CAEnforcement["Flexible controls (MFA, reset, etc.)"]

    RiskDetection --> LegacyPolicy --> LegacyEnforcement
    RiskDetection --> CA --> CAConditions --> CAEnforcement

Figure: Legacy and CA risk policies compared in terms of enforcement and flexibility.

Remediation differs for user risk and sign-in risk

Remediation is where Conditional Access risk policies really pay off. For sign-in risk, most organizations either require step-up MFA or block access outright. For user risk, the usual response is a forced secure password change. With hybrid users, though, that only works if Entra ID password writeback is enabled. Without it, the password reset never makes it back to the local AD account.

Wherever I can, I recommend passwordless remediation instead. Conditional Access lets you require modern authentication strengths such as "passwordless required", so a compromised user has to re-authenticate with Microsoft Authenticator or a FIDO2 key, for example. That's more secure, and it also spares you a lot of the frustration and lockouts that forced password resets tend to cause.

Practical tip: Run every new risk policy in report-only mode before you enforce it, particularly policies that block access or require a password change. You'll see quickly who would be affected and can adjust exclusions before anything breaks.

Identity Protection remains the place to monitor risky users and sign-ins

For monitoring, I still start in the Microsoft Entra admin center under Protection → Identity Protection. It shows you which users and sign-ins are currently flagged as risky, whether remediation worked, and which risk events keep coming back or are new. The details on risky users and sign-ins are extremely useful to me for recognizing attack patterns and for adjusting Conditional Access rules as threats change.

If you want to automate the analysis, you can stream risk data into Microsoft Defender or Sentinel and query it with KQL. For most admins, though, the Identity Protection dashboard covers what they need. If you're looking for a general introduction to Conditional Access best practices, my earlier guide may help: Getting started with Conditional Access in Entra ID.

Licensing and manual cleanup cause most migration problems

Any Conditional Access policy that uses user or sign-in risk as a condition requires a Microsoft Entra ID P2 license. I regularly find P2 licenses assigned unevenly, or risk policies that accidentally include users without the right license. The result can be gaps in coverage or even licensing violations.

The second thing to keep in mind is that the migration doesn't happen on its own. Once your Conditional Access risk policies are in place, you have to disable the legacy Identity Protection policies yourself. If you leave them on, enforcement can become unpredictable, and support tickets will follow.

I would not wait any longer with the migration

Moving your risk policies into Conditional Access isn't only about following Microsoft's advice. It's a genuine improvement: more flexibility, better remediation options and a far clearer set of policies. In nearly every tenant I've worked on this year, the migration was overdue, and it paid off fast in security and in how easy the setup was to understand for admins.

If you still rely on the old ID Protection policies, switch now. Users and admins both gain too much to keep putting it off.