Entra ID risk policies stop enforcing on October 1, 2026, and nothing will tell you

A silent failure, not an end of support

On October 1, 2026, the risk policies configured in Microsoft Entra ID Protection stop enforcing. No red banner, no warning at sign-in time, no unexpected lockout. They stay visible in the portal and they simply stop doing their job. That is what makes this deadline trickier than a normal end of support: nothing breaks, so nothing raises a flag.

Two protections go away. The user risk policy, which forces remediation on an account whose credentials Microsoft judges likely compromised. And the sign-in risk policy, which requires multifactor authentication when a session falls outside normal behaviour. Risk detection itself keeps running and keeps filling the dashboard. You keep the screen, you lose the bouncer at the door.

The date is confirmed on the Microsoft Learn page covering risk-based access policies, updated August 14, 2026. The replacement runs entirely through Conditional Access.

Two Conditional Access policies, never one

The procedure Microsoft documents, updated April 28, 2026, is manual. No automatic conversion is documented: whatever is not rebuilt by hand will not carry over.

The first instinct to avoid is bundling both conditions into a single rule. Microsoft explicitly forbids it, because the remediation controls each one needs are different. You need two separate policies.

• User risk: all users, all resources, the user risk condition set to High, grant control Require risk remediation. That control automatically pulls in an authentication strength requirement and a sign-in frequency of every time.
• Sign-in risk: same targets, the sign-in risk condition set to Medium and High, grant control Require authentication strength with multifactor authentication, sign-in frequency every time.
• In both cases, exclude emergency access or break-glass accounts, and move service accounts to Conditional Access for workload identities instead.

Entra ID risk policies and Conditional Access: what you gain in the trade

Both policies are created in report-only mode, validated against the sign-in logs, then turned on. The legacy policies are disabled last, from the ID Protection dashboard.

From a distance the whole thing looks like imposed paperwork. It does fix real limits of the old model, which was single and global: one risk level, one control, for everyone.

In Conditional Access you can apply a different threshold to privileged accounts than to standard users, test in report-only mode before enforcing anything, drive it all through the Graph API, and read a precise diagnostic in the logs when a user calls the help desk. It also ends an inherited inconsistency: risk conditions lived in one portal, every other access rule in another.

The three pitfalls that derail the switch

• MFA registration. A user who has never registered a multifactor authentication method cannot self-remediate: they get blocked and an administrator has to step in. Across a fleet with dormant accounts or field staff, that is dozens of calls on the first morning.
• Password writeback. In a hybrid identity setup, remediating a user risk assumes the password change flows back down to on-premises Active Directory. Without password writeback enabled, the policy blocks with no way out.
• Licensing. Risk conditions in Conditional Access require Entra ID P2 or the Entra Suite. An organization that was already using the legacy policies is covered. One that only holds P1 never had these protections, and sometimes finds that out now.

What to do before October 1

Done now, this is half a day of configuration and two weeks of passive observation. Done after October 1, it is no longer a migration: it is a stretch of time during which risky sign-ins go unchallenged and nobody notices. In front of a cyber insurer or a privacy regulator, the difference between the policy existed and the policy enforced is hard to defend. To run the inventory and frame the switch with us, talk to an io4 expert.

• Check whether the legacy policies are actually enabled in ID Protection. Plenty of organizations inherited them from an initial rollout and never revisited them.
• Create both policies in report-only mode this week, so you keep two to three weeks of observation before enforcing.
• Inventory users with no registered MFA method, and clear that list before you enforce.
• Validate password writeback if the directory is hybrid.
• Disable the legacy policies only after the new ones are on, so you never open a window with no protection.