Migrate legacy Entra ID Protection risk policies to Conditional Access

The legacy user risk and sign-in risk policies in Microsoft Entra ID Protection had a retirement date of 1 October 2026, so the automatic response to risky users and risky sign-ins now has to come from Conditional Access. To migrate, create one Conditional Access policy with the User risk condition set to High and the Require risk remediation grant, and a second policy with the Sign-in risk condition set to Medium and High, an MFA authentication strength and sign-in frequency Every time. Run both in report-only mode, turn them on, then disable the old policies under ID Protection > Dashboard.

Who this is for and what you will have at the end

This guide is for identity and security administrators in tenants licensed for Microsoft Entra ID P2 or Microsoft Entra Suite who still have, or recently had, the user risk policy or sign-in risk policy enabled on the ID Protection blade. It also helps if you inherited a tenant and are not sure where risk is being enforced today.

At the end you will have:

• An inventory of the legacy settings and of any risk-based Conditional Access policies that already exist.
• A user risk policy and a sign-in risk policy in Conditional Access that follow Microsoft's current recommendations.
• Report-only results you have reviewed before enforcement.
• The legacy policies disabled, and a short list of failure modes with their fixes.

If you are designing Conditional Access more broadly, the risk policies are one layer of the identity controls described in the zero trust remote access architecture.

What changed and why it matters

ID Protection is not going away. Risk detections, the Risky users and Risky sign-ins reports and the Graph APIs keep working. What retired is the older place where you configured an automatic response to that risk. Microsoft's guidance is to create equivalent risk-based policies in Conditional Access, confirm them in report-only mode, and then disable the legacy policies.

Moving the policies to Conditional Access also gives you features the legacy blade never had. Microsoft lists these benefits:

• One place to manage all access policies.
• Report-only mode and Graph APIs.
• Sign-in frequency set to require reauthentication every time.
• Risk combined with other conditions such as location.
• Several risk policies targeting different groups or risk levels.
• Sign-in logs that show which risk-based policy applied.
• Support for the backup authentication system.

How the old policies map to Conditional Access

Require risk remediation is the newer option for user risk. ID Protection chooses the flow based on the threat and the user's authentication method: users with a compromised password perform a secure password change and their previous sessions are revoked; passwordless users have their sessions revoked and are prompted to sign in again; if Microsoft threat intelligence flags an attacker-added device, that device object is disabled and sessions are revoked. The older Require password change control still exists, but it only covers password users.

Prerequisites

• Licensing: Microsoft Entra ID P2 or Microsoft Entra Suite. Risk-based access policies require P2.
• Roles: Conditional Access Administrator to create or edit Conditional Access policies. Security Administrator is the least privileged role for creating or editing the legacy risk-based policies in ID Protection, which you need to disable them. Security Operator can dismiss user risk; User Administrator can reset passwords.
• MFA registration: users must be registered for Microsoft Entra MFA before a risk policy asks them to remediate. Unregistered users are blocked and need an administrator.
• Hybrid users: password writeback must be enabled so synced users can complete a secure password change in the cloud.
• Emergency access accounts identified, so you can exclude them from both policies.

Step 1: Record what you have today

Before you change anything, document the legacy configuration. In the Microsoft Entra admin center, browse to ID Protection > Dashboard and open the User risk policy and the Sign-in risk policy in turn. For each, write down:

• Whether Enforce policy is enabled.
• Included and excluded users and groups.
• The risk level that triggers the policy.
• The access control it applies.

Then check whether Conditional Access already contains risk-based policies, so you don't create duplicates or conflicting controls. Microsoft Graph PowerShell can list them:

Connect-MgGraph -Scopes 'Policy.Read.All'
 
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.Conditions.UserRiskLevels -or $_.Conditions.SignInRiskLevels } |
    Select-Object DisplayName, State,
        @{ N = 'UserRisk';     E = { $_.Conditions.UserRiskLevels -join ',' } },
        @{ N = 'SignInRisk';   E = { $_.Conditions.SignInRiskLevels -join ',' } },
        @{ N = 'Grant';        E = { $_.GrantControls.BuiltInControls -join ',' } },
        @{ N = 'AuthStrength'; E = { $_.GrantControls.AuthenticationStrength.Id } } |
    Format-Table -AutoSize

riskRemediation is an evolvable enum value in Graph. Microsoft documents that you need the Prefer: include-unknown-enum-members request header to get it back, so a policy that uses Require risk remediation can show up as unknownFutureValue in tools that don't send that header. Confirm such policies in the portal.

Finally, check the Risky users report and deal with users who are already at risk. Microsoft recommends investigating and remediating active risk before you enable new risk policies; otherwise everyone with a stale high risk level is challenged the moment enforcement starts.

Step 2: Create the user risk policy

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access and select New policy.
3. Give it a name that follows your naming standard, for example CA-Risk-User-High-Remediate.
4. Under Assignments > Users or workload identities, include All users. Under Exclude, select Users and groups and add your emergency access accounts.
5. Under Target resources > Include, select All resources (formerly 'All cloud apps').
6. Under Conditions > User risk, set Configure to Yes, select High and select Done.
7. Under Access controls > Grant, select Grant access, then Require risk remediation. Require authentication strength is selected automatically; choose the strength that suits your organization.
8. Under Session, Sign-in frequency - Every time is applied automatically and can't be removed.
9. Set Enable policy to Report-only and select Create.

Points to respect when you design this policy:

• Microsoft's Graph documentation says a policy using riskRemediation or passwordChange must contain userRiskLevels, should target all applications without exclusions, and can't contain any condition other than users, applications and user risk. Don't add location or platform conditions to it.
• riskRemediation and passwordChange can't be used together. passwordChange must be paired with mfa using AND; riskRemediation must be paired with an authentication strength using AND.
• Require risk remediation isn't supported for external and guest users, because Microsoft Entra ID can't revoke their sessions. Exclude guests from this policy and decide separately how you handle risky guests.
• If a user falls into several user risk policies, Block wins over everything, and Require risk remediation wins over Require password change. Assign each user to only one of these policies.

Step 3: Create the sign-in risk policy

1. In Entra ID > Conditional Access, select New policy and name it, for example CA-Risk-SignIn-MediumHigh-MFA.
2. Under Users or workload identities, include All users and exclude your emergency access accounts.
3. Under Target resources > Include, select All resources (formerly 'All cloud apps').
4. Under Conditions > Sign-in risk, set Configure to Yes, select High and Medium, then Done.
5. Under Grant, select Grant access, then Require authentication strength, and choose the built-in Multifactor authentication strength.
6. Under Session, select Sign-in frequency, make sure Every time is selected, and select Select.
7. Set Enable policy to Report-only and select Create.

A successful strong authentication, usually MFA or passwordless sign-in, is the only way a user can self-remediate sign-in risk. Unremediated sign-in risk feeds into user risk, so this policy also keeps the user risk policy quieter.

Passwordless users

For groups that already sign in without passwords, Microsoft recommends a variant of the sign-in risk policy: target those users, keep the same risk levels and session control, and require the built-in Passwordless MFA or Phishing-resistant MFA strength, depending on the methods they have.

Users who rely on external MFA

Microsoft documents that external MFA providers don't satisfy authentication strengths, including the built-in MFA strength; they satisfy only the Require multifactor authentication grant. If some users complete MFA with an external provider such as Duo, test them in report-only before enforcing either risk policy. The custom controls migration is covered in replacing Conditional Access custom controls with external MFA.

Using templates instead

Both policies exist as templates under Entra ID > Conditional Access > Create new policy from templates: Require multifactor authentication for risky sign-ins and Require password change for high-risk users, each marked as requiring P2. Template policies are created in report-only mode, but they exclude only the administrator who creates them, so add your emergency access accounts afterwards. You can also export a template's JSON definition and import it with Upload policy file.

Step 4: Review report-only results

Report-only policies are evaluated at sign-in but not enforced. Leave them running long enough to see real risky sign-ins, then review the results three ways:

• Sign-in logs: open a sign-in and check the Report-only tab. Report-only: User action required means the user would have been prompted, for example for MFA. Report-only: Failure means a non-interactive control would have failed. Report-only: Not applied means the conditions weren't met, for example the user was excluded.
• Policy impact: available to roles from Security Reader up, it shows the likely effect of a policy on interactive sign-ins over the past 24 hours, 7 days or 1 month.
• Conditional Access insights and reporting workbook: requires Microsoft Entra ID P1 and a Log Analytics workspace receiving sign-in logs.

Look specifically for users who would be prompted but aren't registered for MFA, hybrid users without password writeback, guest accounts, and service accounts that sign in interactively.

Step 5: Enforce and disable the legacy policies

When the results look right:

1. Open each new policy and move Enable policy from Report-only to On.
2. Browse to ID Protection > Dashboard, select the User risk policy, set Enforce policy to Disabled and save. Repeat for the Sign-in risk policy.
3. Create any additional risk policies you need in Conditional Access, for example a stricter policy for administrators.

If you need Microsoft's help, the support request path documented for this migration is New support request with the summary Migrate legacy ID Protection policy, problem type Identity Protection and subtype Configure risk policies.

Verify

• In Risky sign-ins, sign-ins that met the policy show risk state Remediated with risk detail User passed multifactor authentication.
• In Risky users, users who completed a secure password change show Remediated with risk detail User performed secured password reset. Despite the wording, that label means a secure password change, not self-service password reset.
• In sign-in logs, the Conditional Access tab names the risk policy that applied.
• In ID Protection > Dashboard, both legacy policies show as disabled.

Troubleshooting

A risky user is blocked and can't self-remediate. The user isn't registered for MFA, so the required control can't be completed. An administrator must step in: generate a temporary password from Risky users or the user's page (User Administrator, plus Security Operator when you start from ID Protection), or dismiss the risk after investigation. Close the gap with an MFA registration campaign.

A hybrid user can't change their password during remediation. Password writeback isn't enabled. Alternatively, with password hash synchronization, an administrator can turn on Allow on-premises password change to reset user risk in ID Protection settings so that a password change made on-premises remediates the risk. Microsoft notes this is opt-in and recommends securing the on-premises change process, for example with MFA.

Error 50053 with "Sign-in was blocked by built-in protections due to high confidence of risk". This isn't your policy. ID Protection blocks sign-ins with very high confidence of risk, most often legacy authentication. Move the client to modern authentication or, for a known company location, add its IP addresses to trusted locations.

Risk returns after users pass MFA. Detections related to token theft and verified threat actor IPs, such as Anomalous token and Attacker in the Middle, are no longer auto-remediated by MFA. With a user risk policy in place, affected users must complete a secure password change and reauthenticate.

The portal won't let you add conditions to the user risk policy. Policies with Require risk remediation or Require password change accept only users, applications and user risk. Use a separate policy for location-based rules.

You can't select both Require multifactor authentication and Require authentication strength. The two can't be combined in one policy, because the built-in MFA strength is equivalent to the MFA grant. Pick one.

Checklist

• Legacy user risk and sign-in risk settings recorded.
• Existing risk-based Conditional Access policies inventoried.
• Active risky users investigated and remediated.
• User risk policy: High, Require risk remediation, all resources, emergency accounts and guests excluded.
• Sign-in risk policy: Medium and High, MFA authentication strength, sign-in frequency Every time.
• Separate policy for passwordless users if needed; external MFA users tested.
• Report-only results reviewed in sign-in logs, policy impact or the workbook.
• Both policies set to On.
• Legacy policies set to Disabled under ID Protection > Dashboard.
• MFA registration and password writeback in place for everyone in scope.

References

• Risk policies - Microsoft Entra ID Protection
• Microsoft Entra ID Protection risk-based access policies
• Remediate risks and unblock users
• Require remediation for risky users
• Conditional Access templates
• Conditional Access policy insights: report-only mode
• Overview of Conditional Access authentication strengths
• conditionalAccessGrantControls resource type
• conditionalAccessConditionSet resource type
• Create conditionalAccessPolicy
• Microsoft Entra external MFA method provider reference