Since October 1, 2026, the legacy user risk and sign-in risk policies in Microsoft Entra ID Protection can no longer be managed from their original interface. Microsoft asks you to migrate them to Conditional Access. If nobody has done it, no alert will tell you: the protection may have silently disappeared.
This article details what changed, the required licence, the configuration Microsoft recommends and the pitfalls that block users.
What changed on October 1, 2026
Microsoft retired the interface of the legacy ID Protection risk policies (user risk and sign-in risk) by October 1, 2026 at the latest. The Microsoft Learn documentation asks you to recreate them as Conditional Access policies. The move was announced in October 2023, then rolled out in two stages.
October 2023
Initial announcement
Microsoft announces the retirement of the legacy ID Protection risk policies in favour of Conditional Access.
July 31, 2025
Read-only
The user risk and sign-in risk policy pages become read-only. No more creating or editing.
October 1, 2026
Interface retirement
Deadline set by Microsoft for the retirement. The pages display a banner pointing to Conditional Access.
An important nuance. You often hear that the old policies are "probably still there" and keep applying. The documentation does not confirm this: it talks about interface retirement and end of support, not about enforcement continuing. Check the real state in each tenant rather than assuming it.
Why the missing protection goes unnoticed
Risk detection keeps scoring sign-ins: unusual location, unknown network, leaked credentials. Without a Conditional Access policy that reads this risk level, nothing reacts to the score. The alert is recorded, but no action is triggered.
It is an alarm that spots the burglar but whose siren stays silent. No error appears. No user opens a ticket to complain that they were not asked to prove their identity.
A security gap with no symptoms
A missing policy produces neither an error nor a complaint. The only way to detect it is a deliberate check: list your Conditional Access policies and look for user risk and sign-in risk conditions.
Which licence for risk-based policies?
Risk-based Conditional Access policies require Microsoft Entra ID P2 or Microsoft Entra Suite. Conditional Access alone requires Microsoft Entra ID P1, included for example in Microsoft 365 Business Premium. The Microsoft Learn documentation specifies that sign-in risk and user risk conditions are not available with P1.
| Licence | Conditional Access | Risk conditions | Consequence |
|---|---|---|---|
| Microsoft Entra ID P1 | Included | Not included | Manual remediation or via Graph/PowerShell script |
| Microsoft Entra ID P2 | Included | Included | Automated risk policies |
| Microsoft Entra Suite | Included | Included | Automated risk policies |
A P1 tenant therefore cannot rebuild these policies. It must handle risky users itself. The Microsoft Learn page on remediating and unblocking users describes the manual routes.
Two policies, two conditions: the recommended configuration
Microsoft recommends two separate policies. Never combine user risk and sign-in risk in the same policy.
| Policy | Condition | Grant control | Sign-in frequency |
|---|---|---|---|
| Sign-in risk | Medium and high | Require authentication strength (MFA) | Every time, to be configured |
| User risk | High | Require risk remediation | Every time, applied automatically |
With "Require risk remediation", authentication strength and the "Every time" frequency are enforced automatically and are mandatory. For a password user, this forces a secure password change after MFA. For a passwordless user, sessions are revoked and the user must sign in again.
Create the sign-in risk policy
Create the policy
In the Microsoft Entra admin centre, open Conditional Access and create a policy with an explicit name, for example “Medium or high sign-in risk: MFA”.
Target users and resources
Include all users. Exclude your emergency access accounts, ideally via a dedicated group. Select all target resources.
Set the risk condition
In the conditions, choose sign-in risk and tick the medium and high levels.
Configure grant and session
Grant access by requiring an authentication strength, for example your MFA strength. In the session controls, set the sign-in frequency to "Every time".
Without this setting, Entra ID may consider that the user already did MFA that same morning. With it, a risky sign-in triggers a new prompt immediately.
Start in report-only mode
Create the policy with the "Report-only" state. Switch to "On" once the results are validated.
Create the user risk policy
The basics are identical: all users, emergency access group excluded, all resources. Choose the user risk condition with the high level. Grant access with Require risk remediation. Here too, start in report-only mode.
Prerequisites and pitfalls that block users
The most common pitfall is MFA registration. Users must have registered their MFA methods before they face a remediation. Otherwise they are blocked and an administrator has to step in.
To check before enabling
- All targeted users have registered an MFA method.
- Hybrid users have password writeback enabled.
- The emergency access group is excluded from both policies.
- Guests and B2B users are excluded via a guest group.
- Each user falls under only one of these policies.
Several limits are documented by Microsoft Learn:
- The remediation control only handles user risk, not sign-in risk.
- It is not supported for guests and external users.
- The secure password change does not go through self-service password reset (SSPR).
- With multiple policies, remediation takes precedence over password change, and block takes precedence over everything.
MFA fatigue and phishing
The Microsoft FAQ stresses that the "Every time" frequency depends on your risk tolerance. It can cause MFA fatigue and increase exposure to phishing. Some organisations prefer to block high risk outright.
Measure the impact before enabling
Report-only mode shows what the policy would have done, without enforcing anything. Microsoft additionally offers the "Impact analysis of risk-based access policies" workbook. It works without any policy in report-only mode and also takes into account remaining legacy policies, which helps spot what is left.
A company with a few hundred seats could thus create its two policies in report-only mode on day one, analyse the affected users, fix missing MFA registrations, then enable. This sequence is an illustration, not a prescribed duration.
If you run into migration difficulties, a "Migrate legacy ID Protection policy" support request can be opened from the Microsoft Entra admin centre. For the rest of your foundation, also see our guide on enforcing MFA with Conditional Access and our framework for testing Conditional Access policies.
Frequently asked questions
Do my old risk policies still protect my tenant?
There is no way to say for sure. The Microsoft documentation talks about interface retirement and end of support, without stating that the policies keep applying. Check the real state of each tenant and recreate the policies in Conditional Access.
Is Business Premium enough for risk policies?
No. Business Premium includes Microsoft Entra ID P1, which provides Conditional Access but not the user risk and sign-in risk conditions. You need Microsoft Entra ID P2 or Microsoft Entra Suite.
Can I put both risk conditions in a single policy?
No, Microsoft recommends one policy for high user risk and another for medium or high sign-in risk. Also avoid assigning the same user to several of these policies.
What happens to guests and B2B users?
The "Require risk remediation" control does not support them. The Microsoft FAQ recommends excluding them via a guest group.
Where to start
Start with an inventory, not with creating a policy. Check what exists, then rebuild in report-only mode.
Next actions
- Confirm that the tenant has Microsoft Entra ID P2 or Microsoft Entra Suite.
- List the existing Conditional Access policies that have a risk condition.
- Create the two recommended policies in report-only mode.
- Run the impact analysis workbook and fix missing MFA registrations.
- Enable the policies, then monitor blocks during the first few days.
If your tenant is on P1, plan for manual or scripted remediation of risky users, and consider moving to P2. If your organisation fears MFA fatigue, evaluate blocking high risk rather than repeated prompts. To go further on the baseline, our article on Baseline scopes and Conditional Access complements these two policies.
Going further
- Configure and enable risk policies (Microsoft Learn): the official migration procedure, with recommended settings and support request.
- ID Protection risk-based access policies: adaptive remediation, control precedence and limits.
- Risk-based policy impact analysis workbook: simulate the effect of policies and spot legacy policies.
- Microsoft Entra ID Protection FAQ: hybrid, federated and B2B cases, and MFA fatigue.
- Remediate risks and unblock users: manual and automatic remediation, useful without P2.
