Edit

Configure and enable risk policies

  • Article

As we learned in the article, Risk-based access policies, there are two types of risk policies in Microsoft Entra Conditional Access you can set up. You can use these policies to automate the response to risks allowing users to self-remediate when risk is detected:

  • Sign-in risk policy
  • User risk policy

Screenshot of a Conditional Access policy showing risk as conditions.

Choosing acceptable risk levels

Organizations must decide the level of risk they want to require access control on balancing user experience and security posture.

Choosing to apply access control on a High risk level reduces the number of times a policy is triggered and minimizes friction for users. However, it excludes Low and Medium risks from the policy, which might not block an attacker from exploiting a compromised identity. Selecting a Low risk level to require access control introduces more user interrupts.

Configured trusted network locations are used by Identity Protection in some risk detections to reduce false positives.

The policy configurations that follow include the sign-in frequency session control requiring a reauthentication for risky users and sign-ins.

Microsoft's recommendation

Microsoft recommends the following risk policy configurations to protect your organization:

  • User risk policy
    • Require a secure password change when user risk level is High. Microsoft Entra multifactor authentication is required before the user can create a new password with password writeback to remediate their risk.
  • Sign-in risk policy
    • Require Microsoft Entra multifactor authentication when sign-in risk level is Medium or High, allowing users to prove it's them by using one of their registered authentication methods, remediating the sign-in risk.

Requiring access control when risk level is low introduces more friction and user interrupts than medium or high. Choosing to block access rather than allowing self-remediation options, like secure password change and multifactor authentication, affect your users and administrators even more. Weigh these choices when configuring your policies.

Risk remediation

Organizations can choose to block access when risk is detected. Blocking sometimes stops legitimate users from doing what they need to. A better solution is to allow self-remediation using Microsoft Entra multifactor authentication and secure password change.

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 to cloud, password writeback must have been enabled on them. Users not registered are blocked and require administrator intervention.

Password change (I know my password and want to change it to something new) outside of the risky user policy remediation flow does not meet the requirement for secure password change.

Migrate risk policies to Conditional Access

If you have legacy risk policies enabled in Microsoft Entra ID Protection, you should plan to migrate them to Conditional Access:

Warning

The legacy risk policies configured in Microsoft Entra ID Protection will be retired on October 1, 2026.

Migrating to Conditional Access

  1. Create an equivalent user risk-based and sign-in risk-based policy in Conditional Access in report-only mode. You can create a policy with the previous steps or using Conditional Access templates based on Microsoft's recommendations and your organizational requirements.
    1. After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On.
  2. Disable the old risk policies in ID Protection.
    1. Browse to Protection > Identity Protection > Select the User risk or Sign-in risk policy.
    2. Set Enforce policy to Disabled.
  3. Create other risk policies if needed in Conditional Access.

Enable policies

Organizations can choose to deploy risk-based policies in Conditional Access using the following steps or use Conditional Access templates.

Before organizations enable these policies, they should take action to investigate and remediate any active risks.

Policy exclusions

Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies:

  • Emergency access or break-glass accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant to take steps to recover access.
  • Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals.
    • If your organization has these accounts in use in scripts or code, consider replacing them with managed identities. As a temporary workaround, you can exclude these specific accounts from the baseline policy.

User risk policy in Conditional Access

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Browse to Protection > Conditional Access.
  3. Select New policy.
  4. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
  5. Under Assignments, select Users or workload identities.
    1. Under Include, select All users.
    2. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.
    3. Select Done.
  6. Under Cloud apps or actions > Include, select All cloud apps.
  7. Under Conditions > User risk, set Configure to Yes.
    1. Under Configure user risk levels needed for policy to be enforced, select High. This guidance is based on Microsoft recommendations and might be different for each organization
    2. Select Done.
  8. Under Access controls > Grant.
    1. Select Grant access, Require multifactor authentication, and Require password change.
    2. Select Select.
  9. Under Session.
    1. Select Sign-in frequency.
    2. Ensure Every time is selected.
    3. Select Select.
  10. Confirm your settings and set Enable policy to Report-only.
  11. Select Create to create to enable your policy.

After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On.

Sign-in risk policy in Conditional Access

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Browse to Protection > Conditional Access.
  3. Select New policy.
  4. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
  5. Under Assignments, select Users or workload identities.
    1. Under Include, select All users.
    2. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.
    3. Select Done.
  6. Under Cloud apps or actions > Include, select All cloud apps.
  7. Under Conditions > Sign-in risk, set Configure to Yes.
    1. Under Select the sign-in risk level this policy will apply to, select High and Medium. This guidance is based on Microsoft recommendations and might be different for each organization
    2. Select Done.
  8. Under Access controls > Grant.
    1. Select Grant access, Require multifactor authentication.
    2. Select Select.
  9. Under Session.
    1. Select Sign-in frequency.
    2. Ensure Every time is selected.
    3. Select Select.
  10. Confirm your settings and set Enable policy to Report-only.
  11. Select Create to create to enable your policy.

After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On.

Related content