Entra ID Risk Policy Retirement October 2026 Conditional Access Migration: What's Changing
The Entra ID risk policy retirement October 2026 Conditional Access migration is a hard cutoff for the original risk-response controls in Entra ID Protection. Per Microsoft Learn, legacy user risk and sign-in risk policies — the ones configured directly inside Identity Protection's own dashboard, not through Conditional Access — "will be retired on October 1, 2026." The admindroid Microsoft 365 deprecation tracker lists the same date and the same framing: "User risk policy or Sign-in risk policy UX in Entra ID Protection (formerly Identity Protection) will be retired on October 1, 2026."
Neither source describes any automatic conversion. Microsoft's own migration guidance is entirely manual: administrators must build equivalent risk-based policies in Conditional Access themselves, validate them, turn them on, and only then go back and disable the old ones. Nothing in the documentation moves a tenant's existing risk-policy configuration into Conditional Access on its own.
Why "No Automatic Migration" Is the Part That Bites
Risk-based response is one of the few Entra ID Protection controls that acts on identity compromise signals without a human in the loop — it's what turns a "risky user" or "risky sign-in" detection into an actual multifactor challenge, forced password change, or block. A tenant that still relies on the legacy policy UX and does nothing before the retirement doesn't get migrated for free: it loses that automated response the moment the legacy policy stops functioning, unless a Conditional Access equivalent is already live.
This is a narrower, harder-edged problem than "risk detections exist but nobody acts on them" (the more general Identity Protection gap EtcSec has covered separately). Here, a tenant can have a working, enforced risk policy today and still end up with zero risk-based enforcement on October 2, 2026 — not because anyone changed anything, but because they didn't.
Detection: Are You Still on the Legacy Policy Path?
Two things need checking, and Microsoft Learn's own migration walkthrough tells you exactly where to look:
- Legacy risk policies. In the Microsoft Entra admin center, go to ID Protection → Dashboard, and open the User risk and Sign-in risk policy tiles. If either shows Enforce policy: On, that tenant is still depending on the policy type being retired.
- Conditional Access risk-based coverage. Go to Entra ID → Conditional Access → Policies and check whether any policy uses Conditions → User risk or Conditions → Sign-in risk. If none exist — or the only ones present are still in Report-only — there is no working replacement yet, regardless of what the legacy dashboard shows.
A tenant can fail either check independently: some have already built Conditional Access risk policies and just forgot to retire the legacy ones (redundant, not urgent); others have neither, which is the combination that goes to zero risk-based enforcement on the retirement date.
Remediation: Migrating Before October 1, 2026
Microsoft Learn documents a specific, three-step migration path:
- Build the Conditional Access equivalents first, in report-only mode. Create a user risk-based policy and a sign-in risk-based policy in Conditional Access (manually, or from a Conditional Access template), targeting All users with the emergency-access/break-glass accounts excluded. If you start from a template, add that exclusion yourself once the policy exists: Microsoft's templates exclude only the account that creates the policy, not the tenant's break-glass accounts. Leave Enable policy set to Report-only at first.
- Validate, then turn the policies on. Use Conditional Access's report-only insights to confirm the new policies fire the way the old ones did before flipping Enable policy from Report-only to On.
- Disable the legacy policies. Back in ID Protection → Dashboard, open each legacy User risk and Sign-in risk policy and set Enforce policy to Disabled — Microsoft's guidance stops short of deleting them, just disabling.
For tenants that need direct help, Microsoft Learn documents a specific support-request path: file a New support request, describe the issue as "Migrate legacy ID Protection policy," and select Microsoft Entra Sign-in and Multifactor Authentication → Configuring new or existing policy settings.
Two related pieces are worth checking alongside this migration: risk policies — sign-in and user risk, whether driven from ID Protection or from Conditional Access — are listed by Microsoft as an Entra ID P2 or Microsoft Entra Suite capability and are unavailable on Free or P1, and any new policy should go through the same report-only validation discipline that applies to every other Conditional Access rollout — a policy left in report-only mode indefinitely provides the same zero enforcement as no policy at all. It's also worth reviewing overall Conditional Access baseline coverage while you're in there, since a tenant migrating risk policies is a tenant already auditing its Conditional Access posture.
This retirement joins a run of dated Entra deadlines in 2026 — SSPR's registered-methods-only enforcement in November is another one with a hard cutover and no silent fallback — and the operational lesson is the same each time: a "will be retired" notice from Microsoft is a to-do, not a background migration.
How EtcSec Detects This
EtcSec's Azure audit measures the thing that still exists after the retirement: whether an enabled Conditional Access policy actually carries a risk condition. CA_NO_RISK_BASED_USER and RISK_NO_USER_RISK_POLICY both fire when no enabled Conditional Access policy sets user risk levels; CA_NO_RISK_BASED_SIGNIN and RISK_NO_SIGNIN_RISK_POLICY both fire when none sets sign-in risk levels. All four read the tenant's Conditional Access policy set — none of them reads the legacy ID Protection policy blade.
Two consequences are worth stating precisely. First, a tenant whose risk response lives only in the legacy ID Protection UX fails these checks today, not on October 2, 2026 — the finding is already sitting in the audit, and it is exactly the migration to-do this deadline creates. Second, the checks count a policy only in state enabled: a risk-based Conditional Access policy still parked in report-only does not clear them, which is the same enforcement reality described above.
Explore the identity security pages that support this topic
