Microsoft scheduled the legacy Entra risk policies in ID Protection for retirement on October 1, 2026, and that date is now nine days behind us. If your tenant still relies on the old user risk and sign-in risk policies, the protection you think you have may have stopped without a visible error. Microsoft’s documentation tells admins to rebuild the same logic in Conditional Access.

The work is not large, but the order matters. A risk policy that blocks or forces a password change can lock out the very people you need to fix the problem, so the safe route runs through report-only mode and a deliberate exclusion list. Nothing in the process requires downtime.

Below is a five-step migration that follows Microsoft Learn, with labels quoted where Microsoft gives them. A few details, such as whether your tenant’s old policies are still enforcing today, I could not confirm from a source, and those are marked.

What You Need

Licensing first. Microsoft states that risk-based access policies require Microsoft Entra ID P2. The migration changes configuration, not licensing, so a tenant that was covered before is covered now. If you are not sure, check your license assignments before building anything.

For roles, Microsoft names Conditional Access Administrator as the least privileged role that can create or edit Conditional Access policies. Reading the reporting workbook takes at least Security Reader plus access to a Log Analytics workspace, and that workspace needs to be connected to your Entra sign-in logs, which requires Entra ID P1 as well.

You also need three pieces of information in hand: which users and groups the old policies targeted, what risk thresholds they used, and who was excluded. Open the old policies and write those down. If the old policy lived only in someone’s memory, now is a good moment to change that.

Step 1: Inventory the Legacy Policies

In the Microsoft Entra admin center, go to ID Protection, then Dashboard. You will find the User risk and Sign-in risk policies there. Record the state of each, the users or groups included, any exclusions, and the risk level that triggers an action.

Entra Risk Policies Retirement: How to Migrate Now - detail view

A third-party migration guide from ecorpit, dated August 2026, describes the failure mode in blunt terms: after the retirement date, the old policies simply stop enforcing, and challenges and password resets stop firing without any alert. That article cites a third-party blog for the claim that the old blade went read-only in July 2025, so I would not repeat that detail as established. Microsoft’s own page confirms the date and the direction of travel, and that is sufficient reason to verify what is actually running.

One more check belongs here. Sign-in risk policies only trigger for people who have registered a method that satisfies Entra MFA, as Microsoft’s concepts page notes. If a chunk of your users never registered, the best policy in the world will block them rather than prompt them. Look at registration coverage now, not after the first support tickets.

Step 2: Protect Your Emergency Access Accounts

Before you build anything, make sure you have at least two emergency access accounts. Microsoft’s guidance says they should be cloud-only accounts on the onmicrosoft.com domain with the Global Administrator role assigned as active permanent in PIM, and that a passkey (FIDO2) is the recommended sign-in method, different from what your normal admins use.

These accounts must be excluded from any enforced policy that blocks or restricts sign-in. Microsoft warns that an enforced MFA or similar policy could make an emergency account unusable in the exact scenario it exists for. Report-only policies do not block access and do not require an exclusion, but you will be turning these on soon, so exclude now. A dedicated group, with a name like EmergencyAccess, keeps the exclusion simple to maintain.

While you are here, confirm that someone has actually tested these accounts recently. Microsoft recommends testing at least every 90 days. An untested break-glass account is a rumor.

Step 3: Build the Replacements in Report-Only Mode

Go to Entra ID, then Conditional Access, then New policy. You can start from a Conditional Access template or build manually. Create two separate policies. Microsoft is explicit that sign-in risk and user risk conditions should not be combined in one policy.

For user risk, Microsoft’s recommended configuration is a trigger of High, a grant control of Require risk remediation, and a session control of Sign-in frequency set to Every time. Requiring remediation automatically adds Require authentication strength, and the sign-in frequency control is applied for you. In plain terms, a user with a password gets a password change and has their sessions revoked; a passwordless user has sessions revoked and signs in again; and if an attacker registered a device, that device object is disabled.

For sign-in risk, the recommendation is a trigger of Medium and High, a grant control of Require authentication strength set to the built-in Multifactor authentication, and Sign-in frequency set to Every time. Assign users to the matching groups you recorded in Step 1, add the emergency group as an exclusion, and set Enable policy to Report-only before saving.

Two limits to know. Remediation is not supported for external and guest users, because Entra cannot revoke sessions for them. And precedence is strict: Require risk remediation overrides Require password change, and Block overrides everything. Put each user under only one of these user-risk policies at a time. For hybrid users synced from on-premises, Microsoft adds that password writeback must be enabled.

Step 4: Watch the Results Before You Enforce

Report-only policies are evaluated at each sign-in and logged, but they do not enforce. Microsoft’s reporting workbook lives at Entra ID, Conditional Access, Insights and reporting. Pick the report-only policies in the parameters at the top, set a time range between 4 hours and 90 days, and read the impact summary tiles.

Entra Risk Policies Retirement: How to Migrate Now - working context

Those tiles are Success, Failure, User action required and Not applied. The third one needs a short explanation: a report-only policy cannot complete an interactive control like MFA, so those sign-ins land in User action required rather than a clean pass or fail. Do not read that as a problem. The condition breakdown beneath the tiles, which covers device state, platform, client app, location, application and sign-in risk, helps you spot a surprising slice of users before it affects them.

If you prefer raw data, Microsoft notes that downloading the sign-in logs in JSON format includes the Conditional Access report-only results. Plan on a few days of observation at minimum. Risk events are by nature rare, so a quiet week may show little. That is a reason to keep watching, not a reason to skip the step.

If the workbook shows no data at all, run SigninLogs in Log Analytics under Monitoring and health. Microsoft says an empty result suggests the workspace is not configured correctly.

Step 5: Turn On the New Policies and Disable the Old Ones

Once the report-only data looks sane, open each new policy, change Enable policy from Report-only to On, and save. Microsoft’s order of operations is to confirm results first, then switch, then retire the old ones. Its page does not address running old and new policies side by side, so keep any overlap short.

Then return to ID Protection, Dashboard, select the User risk or Sign-in risk policy, and set Enforce policy to Disabled. If the retirement date has already passed in your tenant, the old policies may no longer show as enforceable; document what you see and move on.

Finish with the companion policy that makes the others workable: the multifactor authentication registration policy, found under ID Protection, Dashboard. Microsoft says users are prompted at next interactive sign-in and have 14 days to register, after which registration is required to complete sign-in. Creating or editing it takes at least the Security Administrator role. Exclude the emergency accounts here too.

Service accounts and service principals sit outside all of this. Policies scoped to users do not block service principal calls. Microsoft points to Conditional Access for workload identities, and suggests replacing script-bound service accounts with managed identities where possible.

Troubleshooting: Locked-Out Users and Silent Policies

Users are blocked and cannot self-remediate. This almost always means they never registered for MFA. Microsoft says unregistered users are blocked and need administrator intervention. Fix registration coverage, and for hybrid users, check that password writeback is enabled.

Entra Risk Policies Retirement: How to Migrate Now - supporting scene

Two policies fight each other. If a user matches more than one user-risk policy, precedence decides the outcome, and Block wins. Audit group memberships so each user lands in exactly one.

The policy never seems to fire. Check the licensing, then the targeting. A policy scoped to a group that is empty applies to nobody. Also remember that risk detections are infrequent; a policy that has not fired in report-only mode is not necessarily broken.

Prompts are too frequent. Microsoft notes that lower thresholds produce more prompts, and that configuring trusted network locations helps reduce false positives. Moving the user risk threshold to High is already the recommended default.

You are stuck. Microsoft documents a support route in the Entra admin center: New support request, with the service Microsoft Entra Sign-in and Multifactor Authentication, the problem Configuring new or existing policy settings, and the summary “Migrate legacy ID Protection policy.”

Frequently asked questions

When did the legacy ID Protection risk policies retire?

Microsoft Learn gives October 1, 2026 as the retirement date for the user risk policy and sign-in risk policy in ID Protection. I could not independently confirm how an individual tenant behaves after that date.

Do I need Entra ID P2 for the Conditional Access replacements?

Yes. Microsoft states that risk-based access policies require Microsoft Entra ID P2, for both the old and new approach.

Should I combine user risk and sign-in risk in one policy?

No. Microsoft’s guidance is to create a separate policy for each condition.

Which risk levels does Microsoft recommend?

High for user risk, with Require risk remediation, and Medium plus High for sign-in risk, with MFA authentication strength. Both with sign-in frequency set to Every time.

Retirements like this rarely announce themselves. Nobody gets paged when a policy quietly stops doing its job; the evidence shows up months later in an incident review. The useful habit is not just migrating this one feature but keeping a list of what each protective control is supposed to do and checking it against reality on a schedule. Rebuild the two policies, test the break-glass accounts, and then put a recurring entry on the calendar to check that both still fire.

Sources