Yet another deadline – and this one is RISKY!

A few months after the scramble over Authentication methods in Entra, we yet again face a deadline that actually matters if you care about keeping things secure.

This time it is your risk policies you need to revisit. If you have an Entra P2 license then hopefully you have configured your user risk and your sign-in risk policies to stop and mitigate signins flagged as risky by Entra. For years these policies have been located under Entra ID Protection (referred to as legacy policies) and separate from Conditional Access policies. They are similar to Conditional Access policies, but much simpler with far fewer options to set.

Though for the past couple of years, we have had the option to set this up and Conditional Access policies if your tenant had the required licenses.

The deadline

🚨 On October 1st, 2026, legacy risk policies under Microsoft ID Protection will be retired. Unlike the recent authentication policy changes, there won’t be an automatic migration to Conditional Access. If you don’t manually update your Conditional Access setup to include risk-based conditions, affected accounts will lose their risk protection from that date onward.

Don’t overlook this change.

Check your Conditional Access policies now to ensure they cover user and sign-in risk. If they don’t, add this to the top of your to-do list! Because after October 1st, 2026, legacy risk policies will no longer protect your users!

Source and configuration recommendations: Risk policies – Microsoft Entra ID Protection | Microsoft Learn

User risk vs sign-in risk

Let’s first clarify the difference between user risk and sign-in risk, then take a quick peek at relevant Conditional Access settings.

User risk is about whether the account itself is compromised, while sign-in risk is about whether a specific login attempt is suspicious. Microsoft Entra evaluates both in real time and offline, using signals like leaked credentials, impossible travel, or unusual device activity.

User risk

• The probability that a user’s account has been compromised.
• Evaluation examples:
  • Leaked credentials (offline detection): Microsoft finds the user’s password in a breach database. Even if the user hasn’t signed in recently, their account is flagged as risky.
  • Unusual activity (real-time or offline): A user suddenly downloads massive amounts of data or accesses sensitive apps they’ve never used before.
  • Malware-linked sign-ins: If a device associated with the user is known to be infected, the account risk increases.

Scenario: An employee’s credentials appear on the dark web. Even if they haven’t tried to log in, Entra marks their account as “high user risk,” and Conditional Access can require a password reset before they regain access.

Sign-in risk

• The probability that a specific login attempt is malicious.
• Evaluation examples:
  • Impossible travel (real-time detection): A user signs in from Norway, then 10 minutes later from Brazil. The second sign-in is flagged as risky.
  • Anonymous IP addresses (real-time): Login attempts from TOR or known VPN exit nodes raise sign-in risk.
  • Atypical sign-in properties (offline): A login occurs at an unusual time or from a device never used before.

Scenario: A user tries to log in from a suspicious IP address at 3 AM. Entra flags the session as “medium sign-in risk,” and Conditional Access can enforce MFA before granting access.

Be aware that a sign-in can be risky even if the user isn’t, and a user can be risky even if a specific sign-in looks fine. That’s by design: Entra evaluates account compromise risk and session compromise risk separately, using both real-time and offline detections powered by machine learning and threat intelligence

More details can be found here: Risk detection types and levels – Microsoft Entra ID Protection | Microsoft Learn

Condtional Access settings

As mentioned in the first link you can start by simply mimicking your legacy risk policies in your Conditional Access policies. There are however a few additional options you can set in Conditional Access policies, and you should be aware of those.

If your tenant has any Entra P2 licenses, you will find “User risk” and “Sign-in risk” under “Conditions” in your Conditional Access policies, as shown in the picture below. These can be set to low/medium/high, and sign-in risk can additionally be set to “no risk”.

❗Do NOT set both user risk and sign-in risk in the same policy! Conditional Access evaluates Conditions with AND logic. So if you include both, the policy fires only when both risks are present, which will under-protect you.

In the picture below, under the “Grant“ section of the Conditional Access policy, there is a new option called “Require risk remediation“. When you select this, it will automatically also enable “Require Authentication Strength” and “Session control – Every time“. So if a user signs in, and is flagged with risk and this policy applies, then all the users sessions are revoked and the user must perform authentication according to the authentication strength which are set. This will reset the users risk score. More information here: How to Configure Grant Controls in Microsoft Entra – Microsoft Entra ID | Microsoft Learn

Final Thoughts

😱 Legacy user/sign-in risk policies retire Oct 1, 2026 with no auto-migration. Recreate them in Conditional Access using risk conditions and “Require risk remediation,” but don’t combine user risk and sign-in risk in the same policy. Test, scope, and roll out before the deadline.

A little checklist to help you get started:

• License check: Confirm Entra ID P2 is present for risk conditions.
• Inventory: List existing legacy risk policies and their thresholds (user risk: high; sign-in risk: medium/high).
• CA migration: Create separate CA policies for user risk and sign-in risk; choose appropriate thresholds.
• Grant controls:
  • Use: Require risk remediation.
  • Verify: Authentication strength selection and session revocation behavior match your requirements.
• Scope: Start with “report-only,” pilot with a controlled group, then expand.
• Exceptions: Document break-glass accounts and emergency access procedures.
• Monitoring: Set up alerts/Workbooks to track risk detections and policy hits post-rollout.

I wish you all good luck with the policy migration, and I hope you don’t wait until the last day before doing this transfer. Start early and get it out of the way.