Entra ID Protection risk policies retire October 1, 2026

There is a small, quiet deadline sitting in the last week of September and the first day of October that most mid-market tenants have not put on a change calendar. On October 1, 2026, Microsoft retires the legacy risk policies configured inside Entra ID Protection. The guidance is unambiguous, and it is a Warning box rather than a footnote: "The legacy risk policies configured in Microsoft Entra ID Protection will be retired on October 1, 2026."

This post does three things: tells you in about a minute whether it applies to you at all, sets out what the replacement actually is, and names the two traps that turn a twenty-minute change into a rescheduled one.

First, the question that decides whether you can stop reading

Do you have Entra ID P2? Everything below depends on it, and a large share of the regulated mid-market does not.

Microsoft's license table for ID Protection is explicit. Against the capability "Risk policies — Sign-in and user risk policies (via ID Protection or Conditional Access)", the three columns read Microsoft Entra ID Free: No, Microsoft Entra ID P1: No, Microsoft Entra ID P2 / Microsoft Entra Suite: Yes. The page opens the section with "Using this feature requires Microsoft Entra ID P2 licenses."

Now map that onto what a mid-market tenant usually owns. Microsoft's own pricing page states that Entra ID P1 "is available as a standalone or included with Microsoft 365 E3 for enterprise customers and Microsoft 365 Business Premium for small to medium businesses", and that P2 "is available as a standalone or included with Microsoft 365 E5 for enterprise customers."

Worth being precise about one thing, because the license line is easy to over-read: a P1 tenant is not blind to identity risk. Microsoft's table gives Free and P1 "Limited Information. Only users with medium and high risk are shown. No details drawer or risk history" on the risky users report. You can see that something happened. What P1 cannot do is act on it automatically. That distinction is the whole product boundary, and it is the honest answer to "should we buy P2" — you are buying automated response, not visibility.

What is actually retiring, and what is not

ID Protection is not going away. The detections keep running, the risky users and risky sign-ins reports stay, the Graph APIs stay, and the Sentinel and Defender XDR integrations stay. What retires is the older configuration surface — the user risk policy and sign-in risk policy you set inside ID Protection itself, with an Enforce policy toggle.

The replacement is the same idea expressed as a Conditional Access policy, using User risk and Sign-in risk as conditions. Functionally you are moving the enforcement decision from a product-specific page into the tenant's general access-control engine, which is where the rest of your policy already lives. That is a good change. It is just one somebody has to make.

The migration, in the order Microsoft specifies

1. Build the equivalent policies in Conditional Access, in report-only mode. Microsoft's recommended configuration is a user risk policy requiring risk remediation when user risk is High, and a sign-in risk policy requiring multifactor authentication when sign-in risk is Medium or High. Both start in report-only.
2. Confirm the results, then move the toggle from Report-only to On.
3. Disable the old policies in ID Protection — ID Protection, then Dashboard, then the User risk or Sign-in risk policy, then set Enforce policy to Disabled.

Note that the new policy is validated before the old one is turned off, so for a period both exist. That is deliberate and it is the right order. It also means the job is not finished when the Conditional Access policy goes live — step three is a separate action, and it is the one most likely to be forgotten once the new policy is working.

Trap one: the role that builds the replacement cannot retire the original

Microsoft's role table for ID Protection is worth reading closely before you assign the work. Against Conditional Access Administrator, the "Can do" column reads "Create policies that factor in user or sign-in risk as a condition." The "Can't do" column reads "Read or write to legacy ID Protection policies."

So the administrator who can perform step one cannot perform step three. Full access to ID Protection sits with the Security Administrator role. In a mid-market tenant, where role assignment is often narrower than people assume and the person doing identity work holds exactly the role they needed last time, this is the detail that turns a scheduled change into a half-finished one: the new policy goes live, the old policy stays enforced because nobody in the room can disable it, and both are running until someone notices.

Decide before the change window which named person holds which role. If you are running least-privilege properly — and if you are reading this you probably are, because that is the same discipline behind a Tier 0 model — then this is a two-person change, and that is fine as long as both people are booked.

Trap two: the users who cannot self-remediate get blocked

This is the one that generates helpdesk tickets, and Microsoft flags it as a Warning: "Users must register for Microsoft Entra multifactor authentication before they face a situation requiring remediation. For hybrid users that are synced from on-premises, password writeback must be enabled. Users not registered are blocked and require administrator intervention."

Read the last sentence again. The failure mode of a risk policy meeting an unregistered user is not a prompt — it is a block plus a call to your service desk. In a hybrid tenant, password writeback is the specific dependency, and it is exactly the kind of setting that was configured once during the original Entra Connect deployment and has not been looked at since. If you are already touching hybrid identity this month because Entra Connect Sync stops working for out-of-date versions on September 30, 2026, check writeback while you are in there. The two deadlines are a day apart.

Two more configuration details from the same guidance, both easy to get wrong:

• Do not put both risk conditions in one policy. Microsoft's Warning is explicit: "Don't combine sign-in risk and user risk conditions in the same Conditional Access policy. Create separate policies for each risk condition." Two policies, not one.
• Exclude your break-glass and service accounts. Microsoft recommends excluding emergency access accounts "to prevent lockout due to policy misconfiguration", and service accounts and service principals — naming the Microsoft Entra Connect Sync Account specifically. Locking yourself out of the tenant with a risk policy is a real outcome, and the exclusion costs nothing to add.

One behavioral note that surprises people: choosing Require risk remediation automatically applies two further controls — Require authentication strength as a grant control, and Sign-in frequency — Every time as a mandatory session control. And for passwordless users, Microsoft revokes the session so they must reauthenticate, rather than prompting for a password change. If your organization has been moving to passkeys, the user experience of remediation is not the same as it was.

Why this is worth a change window rather than a note in a backlog

Risk-based Conditional Access is not an obscure feature. It is one of the specific controls that gets asserted, by name, on a cyber-insurance application, in a HIPAA security narrative, and in the identity section of a CMMC or NIST 800-171 control description. The gap between "we have automated response to risky sign-ins" and "we had automated response to risky sign-ins until an October retirement we did not action" is the kind of gap that is invisible day to day and awkward at renewal or assessment.

Microsoft's own behavior is a signal about volume here. The guidance publishes a dedicated support path for this one migration: raise a request described as "Migrate legacy ID Protection policy", under service type Microsoft Entra Sign-in and Multifactor Authentication, problem type Identity Protection, subtype Configure risk policies. Vendors do not build a bespoke intake route for a migration they expect three people to perform.

What we would do this week

1. Establish whether you hold Entra ID P2, per user, in the Entra admin center. If not, close the tab — this is not your deadline.
2. Look in ID Protection for an enabled user risk or sign-in risk policy. Plenty of P2 tenants never turned these on; if both are disabled you have nothing to migrate either, and that is worth recording as a checked fact rather than an assumption.
3. Confirm MFA registration coverage and, for hybrid tenants, password writeback before any policy goes to On. This is the step that decides how many blocked users you create.
4. Build both Conditional Access policies in report-only — separately, with break-glass and sync-account exclusions — and read the report-only results for a few days.
5. Book the two roles. Conditional Access Administrator to enable, Security Administrator to disable the legacy policy. Same change window.
6. Write down what you checked and when. If a questionnaire or an assessor asks next year whether risk-based access control was continuously in place, the dated record is the answer.

Related reading

• Entra Connect Sync stops on September 30, 2026 — the other identity deadline in the same week, and the one that shares the password-writeback dependency.
• Active Directory Tier 0 in 90 days — the least-privilege model that makes the two-role problem above a feature rather than an obstacle.
• The October 13, 2026 retirement cluster — what else lands in the same quarter.

Source

• Risk policies — Microsoft Entra ID Protection, Microsoft Learn (page date October 30, 2025; last updated April 28, 2026). Source for the retirement date, the migration steps, Microsoft's recommended risk levels, the MFA-registration and password-writeback warning, the exclusion guidance, and the dedicated support path.
• What is Microsoft Entra ID Protection?, Microsoft Learn (page date October 30, 2025; last updated February 10, 2026). Source for the license table and the required-roles table, including the Conditional Access Administrator limitation.
• Microsoft Entra plans and pricing, Microsoft. Source for which Microsoft 365 suites include Entra ID P1 versus P2.

If you would rather have this run as a bounded piece of work than added to an already-full queue, scope it with us — license check, report-only build, remediation-coverage review and a dated record of what changed.