Muokkaa

Jaa


Configure and enable risk 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:

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 Microsoft Entra ID 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.
    • A secure password change using self-service password reset is the only way to self-remediate user risk, regardless of the risk level.
  • 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.
    • A successful multifactor authentication is the only way to self-remediate the sign-in risk, regardless of the risk level.

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 configure user and sign-in risk-based Conditional Access policies that allow users to self-remediate.

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, password writeback must be enabled. 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.

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 lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and 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. 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.

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 resources (formerly '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, select Grant access.
    1. Select Require authentication strength, then select the built-in Multifactor authentication authentication strength from the list.
    2. Select Require password change.
    3. 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.

Passwordless scenarios

For organizations that adopt passwordless authentication methods make the following changes:

Update your passwordless user risk policy

  1. Under Users:
    1. Include, select Users and groups and target your passwordless users.
  2. Under Access controls > Block access for passwordless users.

Tip

You might need to have two policies for a period of time while deploying passwordless methods.

  • One that allows self-remediation for those not using passwordless methods.
  • Another that blocks passwordless users at high risk.

Remediate and unblock passwordless user risk

  1. Require administrator investigation and remediation of any risk.
  2. Unblock the user.

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 resources (formerly '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, select Grant access.
    1. Select Require authentication strength, then select the built-in Multifactor authentication authentication strength from the list.
    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.

Passwordless scenarios

For organizations that adopt passwordless authentication methods make the following changes:

Update your passwordless sign-in risk policy

  1. Under Users:
    1. Include, select Users and groups and target your passwordless users.
  2. Under Select the sign-in risk level this policy will apply to, select High.
  3. Under Access controls > Block access for passwordless users.

Tip

You might need to have two policies for a period of time while deploying passwordless methods.

  • One that allows self-remediation for those not using passwordless methods.
  • Another that blocks passwordless users at high risk.

Remediate and unblock passwordless sign-in risk

  1. Require administrator investigation and remediation of any risk.
  2. Unblock the user.

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.

Migrate to Conditional Access

  1. Create equivalent user risk-based and sign-in risk-based policies 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.