Moving ID Protection risk policies to Conditional Access before 1 October

The legacy policies were simple, and that makes it easy to miss something when you migrate them. Each had a user assignment (all users or selected groups, with exclusions), a single risk threshold and one control: block, or allow with a password change (user risk) or MFA (sign-in risk). No app targeting, no other conditions, no session controls, no report-only, only an Enforce policy switch. The thresholds were cumulative ("Medium and above"), while in Conditional Access you tick individual levels, so a legacy "Medium and above" becomes Medium plus High. Forgetting to tick High is the kind of mistake I expect to find in more than one tenant this month.

A legacy policy also doesn't appear on the Conditional Access tab of a sign-in event. It shows up in the sign-in's authenticationRequirementPolicies, as tenantSessionRiskPolicy or accountCompromisePolicies. Microsoft doesn't document which legacy policy each value belongs to; judging by the names, the first is the sign-in risk policy and the second the user risk policy. We'll use them later to find the legacy policies.

Microsoft's configuration guide says not to combine user risk and sign-in risk in one Conditional Access policy. Conditions are combined with AND, so a merged policy only fires when both are elevated at once. Two legacy policies become at least two Conditional Access policies.

In Conditional Access, "require MFA" is a requirement on the token, and it doesn't guarantee a prompt. The ID Protection FAQ puts it plainly: a sign-in risk policy that requires MFA triggers a new challenge only when there is no MFA claim on the existing token. On a Windows device whose PRT carries an MFA claim, or in a browser session that completed MFA an hour ago, a risky sign-in satisfies the policy without the user seeing anything. If the risk comes from a replayed session cookie or an adversary-in-the-middle kit, the attacker's session carries that same claim. Microsoft has already stopped auto-remediating token theft detections such as Anomalous token and Attacker in the Middle on the strength of an existing MFA claim, for this reason.

Setting sign-in frequency to Every time forces a fresh authentication when the session is evaluated, and that fresh strong authentication is what remediates the sign-in risk. Microsoft's pages don't fully agree here (the configuration guide recommends it, the FAQ calls it a matter of risk tolerance and warns about MFA fatigue). For risk policies I find the fatigue argument weak, because the prompt only appears when risk is elevated, which is exactly when you want it.

The Require password change grant is a secure password change: the user completes MFA, then sets a new password, without going through SSPR. It comes with restrictions that catch people out during migration. The policy must target All resources, it can't be combined with other grant controls such as a compliant device, and the only conditions allowed are users and user risk. Users who aren't registered for MFA before they become risky are simply blocked, and hybrid users need password writeback for the change to land.

That flow assumes the user knows their current password. A user who signs in with a passkey or Windows Hello for Business and never knew their password reaches a dead end. Before the new control existed, Microsoft's own guidance for passwordless users at high user risk was a separate policy that blocks them, followed by administrator remediation. (An SSPR reset also remediates user risk, but that is hardly a plan for a blocked user.)

The fix is the Require risk remediation grant, in public preview since November 2025 and documented without the preview label since June 2026. ID Protection picks the remediation itself. When the detection involves the password (leaked credentials, password spray), the user does a secure password change and previous sessions are revoked. When it doesn't (anomalous token, impossible travel, unfamiliar sign-in properties), the sessions are revoked and the user signs in again. For a device added by an attacker, the Entra device object is disabled as well. Selecting the control automatically adds Require authentication strength and a mandatory Sign-in frequency of Every time, because a revocation without an immediate fresh sign-in would remediate nothing.

For a migration, note that it remediates user risk only (you still need a sign-in risk policy) and isn't supported for guests and external users. If a user falls under several user risk policies, Block wins over everything and Require risk remediation wins over Require password change. The remediation runs through a dedicated app (93625bc8-bfe2-437a-97e0-3d0060024faa) that other Conditional Access policies don't block, so expect it in your sign-in logs.

The authentication strength you pick decides who can remediate. If you choose Phishing-resistant MFA for users who mostly have Authenticator push, they can't remediate and the policy works as a block for them. Microsoft's sign-in risk guidance follows the same logic: the built-in Multifactor authentication strength for everyone, and a separate policy with Passwordless MFA or Phishing-resistant MFA for a passwordless group. I would test one case before trusting it in production: a passwordless user with a leaked-credentials detection, since the docs only say the flow depends on both the threat and the authentication method.

Microsoft also documents Microsoft-managed policies here: Require remediation for high-risk users (with its own security group), Block access for high-risk users, and MFA and reauthentication for risky sign-ins. They arrive in report-only and switch on no less than 30 days later unless you set them to On or Off. Given the precedence rules, a managed block policy that switches itself on overrides your self-remediation policy, so decide on each one yourself instead of letting the timer decide.

Nothing breaks when you do this. Detection carries on and sign-ins keep working. The FAQ says low user risk resolves itself after six months, but medium and high user risk is never auto-resolved without a risk policy or an administrator dismissing it. A user whose credentials leaked keeps signing in with that password indefinitely.

Sign-in risk hides the gap well. In a tenant with an all-users MFA policy, ID Protection auto-remediates most risky sign-ins whenever the user completes MFA anyway, so the Risky sign-ins report looks tidy. The gap shows in Risky users, as a slowly growing list of users at High in state At risk. The docs also don't spell out whether legacy policies still enabled on 1 October stop enforcing or disappear, and no automatic conversion is documented. For a tenant that hasn't migrated, both come down to the same thing: no risk policy is enforced.

I haven't found a supported Graph endpoint that returns the legacy policy configuration (Microsoft lists Graph support as one of the reasons to move). In the portal it's ID Protection > Dashboard > User risk policy or Sign-in risk policy, and check Enforce policy. The audit log records changes to these policies as Update Sign-In Risk Policy and Update User Risk and MFA Registration Policy, which helps if someone switched one off recently.

The sign-in logs tell you what actually fired. If they go to Log Analytics, Microsoft's Impact analysis of risk-based access policies workbook has a section for legacy Identity Protection policies. For the raw numbers I use my own query, which looks for the two values above:

Then create the Conditional Access policies in report-only next to the enabled legacy ones and compare the two verdicts for the same risky sign-ins:

Legacy applied combined with reportOnlyNotApplied is a coverage gap, usually an exclusion group or a risk level you didn't tick. Be careful with reportOnlySuccess: report-only counts an MFA requirement as satisfied when the token already holds an MFA claim, so a policy without Every time will look much greener in report-only than it should.

Legacy exclusions don't move across by themselves, so rebuild them on purpose. Break-glass accounts belong outside the risk policies, paired with an alert on every sign-in they make. User accounts used as service accounts can't do MFA or a password change, so a risky one gets blocked; excluding them leaves accounts with no risk control at all, and the real fix is moving them to managed identities or workload identities. Guests need their own decision, because Require risk remediation doesn't support them.

Risk-based Conditional Access needs Microsoft Entra ID P2 (or Entra Suite) for the users in scope, as the legacy policies did. The license usage page now shows "Risk-based Conditional Access users" against your P2 entitlement, so a migrated All users policy makes a licensing gap visible quickly.

This week: run the first query to see which legacy policies actually fire, build separate user risk and sign-in risk policies in report-only with the levels ticked individually and Every time set, compare for a week with the second query, then switch them on and set the legacy policies to Disabled. Afterwards, open Risky users and work through everyone at High who is still At risk.

Update September 2026: Microsoft announced in MC1476122 (21 September) that the Microsoft-managed policy "Require risk remediation for high-risk users" is being created in report-only from the week of 28 September and switches itself On after 30 days unless you set it to On or Off. It was seen in education tenants first; check your policy list for it and its security group.

• Configure and enable risk policies
• Risk-based access policies and the Require risk remediation control
• Microsoft Entra ID Protection FAQ
• Remediate risks and unblock users
• Conditional Access grant controls: Require password change
• Conditional Access session lifetime: Require reauthentication every time
• Microsoft-managed Conditional Access policies
• Conditional Access report-only mode
• authenticationRequirementPolicy resource type (Microsoft Graph beta)
• Impact analysis of risk-based access policies workbook
• Microsoft Entra audit log activities
• License usage insights in Microsoft Entra
• MC1476122: Microsoft-managed policy Require risk remediation for high-risk users