Risk-based Conditional Access Policies in Microsoft Entra ID

On Day 15 of the 20th-anniversary celebration of Cybersecurity Awareness Month, join us as we delve into the realm of risk-based access policies. Learn to migrate these policies from Entra ID protection to Conditional Access to steer clear of compromised accounts and prevent suspicious logins. Stay with us as we reveal profound security insights, impart lesser-known tricks, and offer valuable tips in our M365 Cyber security blog series.

Are you aware that Microsoft blocked 4000 password attacks per second this year? Yes, the latest digital defense report revealed by Microsoft underscores the lightning-fast evolution of cyber threats, emphasizing the pressing need for organizations to adapt in this dynamic environment. With this increasing complexity of threats, organizations face the critical challenge of safeguarding their sensitive data and resources against a multitude of risks. Of course, cybersecurity is now a world of constant risks! But,

The greatest security risk for an organization is the people who work there.

– Kevin Mitnick

Well, the statement made by Kevin in this quote is undeniably accurate! As administrators, you have probably faced a variety of challenges, from dealing with password spray attacks, strange browser logins, leaked credentials, and unusual user behavior. These threats essentially boil down to two main risks: user risk and sign-in risk. These risks are what cyber attackers exploit to create significant threats within your organization.

But fear not! Microsoft has your security covered! Enter risk-based Conditional Access policies in Microsoft Entra, ready to tackle these threats as they arise. This blog post will guide you through risk-based Conditional Access policies.

The blog delves into the following topics:

1. What is user and sign-in risk?
2. What is risk-based Conditional Access policy?
   • User risk based Conditional Access policy
   • Sign-in risk based Conditional Access policy
3. Migrate sign-in risk & user risk policies from Entra ID Protection to Conditional Access
   • Why migrate risk policies from Entra ID Protection to Conditional Access?
4. How to migrate risk policies from Entra ID Protection to Conditional Access?
   • Create user risk-based Conditional Access policy
   • Create sign-in risk-based Conditional Access policy
   • Enable the new risk-based Conditional Access policies
   • Disable the Identity Protection risk policy

Before delving into the intricacies of risk-based Conditional Access policies, it’s crucial to understand the fundamental concept of user and sign-in risks in Microsoft 365.

User risk:

User risk, as evaluated by Microsoft Entra ID Protection, isn’t exclusively linked to a specific malicious sign-in but rather reflects the user’s own behavior. It signifies a potential account compromise, determined through various factors. These risks become apparent when a user’s activity diverges from their usual patterns, often resembling recognized attack methods. This is especially likely when the user’s valid credentials have been compromised or leaked.

Sign-in risk:

Sign-in risk, a critical aspect of authentication security, comes into play when an authentication request lacks approval from the identity owner. This risk is triggered when users try to authenticate from malicious IP addresses, geographically distant locations, or when they employ suspicious browsers. These risks are evaluated to safeguard against unauthorized access and potential security threats.

Risk-based Conditional Access policies in Microsoft Entra are like virtual fire detection systems for security. These policies are designed to safeguard organizations from key security risks that arise when a user or a sign-in activity is deemed potentially risky. This includes scenarios like unfamiliar sign-in properties, mass access to sensitive files, suspicious inbox forwarding, and more. Risk-based Conditional Access also supports external authentication methods in Microsoft Entra.

Risk-based Conditional Access policies provide organizations with three risk levels, namely High, Medium, and Low, to tailor risk policies to their specific needs. Organizations need to balance user experience and security when choosing risk levels.

Selecting a High-risk level reduces policy triggers, lowering user disruptions, but it excludes Low and Medium risks, potentially enabling attackers to exploit compromised identities. On the contrary, opting for a Low risk level increases security but introduces more user interruptions.

Initially, these risk-based policies were housed in Microsoft Entra Identity Protection (formerly known as Azure AD Identity Protection). However, Microsoft recommends migrating them to Conditional Access due to certain compelling reasons which we will discuss later in this blog. As a result, these policies are now known as risk-based Conditional Access policies, and they come in two types.

• User risk-based Conditional Access Policy
• Sign-in risk-based Conditional Access Policy

License Requirements for Risk-based Conditional Access Policies

Typically, setting up Conditional Access policies necessitates Azure AD Premium P1 licenses, whereas risk-based policies in Identity Protection requires P2 licenses.

Identity Protection evaluates user account data and calculates a risk score that signifies the likelihood of a user compromise. When a user exhibits risky behavior, such as trying to access a Primary Refresh Token (PRT), or leaked credentials, Entra Identity Protection combines these factors to determine the user’s risk level. Administrators can then implement risk-based Conditional Access policies to manage users at risk according to their risk level.

By integrating risk policy functionality into Microsoft Entra Conditional Access, you not only automate responses to security threats but also empower users to take corrective actions when risks are detected. This can be achieved through the following measures:

• Blocking Access: In cases of high-risk events, access can be outright blocked.
• Allowing Access with Mandatory Secure Password Change or MFA: Users may be allowed access but prompted to change their password securely or undergo multi-factor authentication (MFA) to mitigate the identified risk.

The use of MFA or a secure password change mitigates user risk and clarifies risk events, thereby reducing unnecessary alerts and disturbances for admins.

Similar to user risk level, Identity Protection continuously monitors and assesses the risk associated with user sign-ins in real-time by analyzing a multitude of signals. The goal is to determine the likelihood that a specific authentication request is unauthorized.

Administrators have the ability to apply access controls based on the assessed sign-in risk level using sign-in risk-based Conditional Access policies. They can take the following actions:

• Block Access: If a sign-in is deemed highly risky, administrators can prevent access to the resources in question to protect the organization’s security.
• Allow Access: In cases where the sign-in is considered low risk or unproblematic, access can be granted without additional restrictions.
• Require Multifactor Authentication (MFA): For sign-ins with a moderate risk level, administrators may mandate the requirement of multifactor authentication as an extra layer of security.

Furthermore, users themselves can play a role in ensuring secure access. They can engage in the necessary access controls, such as initiating multifactor authentication, in order to address and resolve potential risks. This self-remediation process helps prevent unnecessary disruptions for administrators by dismissing the risk state and updating the risk detail to “AI confirmed sign-in safe,” no longer affecting the user’s overall risk status.

NOTE: To enable the sign-in risk policy with MFA controls in Conditional Access, users must have previously registered for Microsoft Entra multi-factor authentication.

Indeed, risk policies existing in Identity Protection enable users to address potential issues by responding to enforced conditions determined through risk assessments. However, Microsoft advises the transition of sign-in risk and user risk policies from Entra ID Protection to Conditional Access. This recommendation stems from Microsoft’s announcement of the retirement of the UX for these risk policies in Entra ID Protection on October 1, 2026.

Beyond the retirement, there exist numerous compelling reasons for transitioning risk-based access policies from Microsoft Entra Identity Protection to Conditional Access. They are,

1. Visibility into Applied Risk-Based Policies: Gain insights into the specific risk-based policies applied in Sign-in Logs, allowing you to assess their effectiveness within your organization.
2. Advanced Conditional Access Features: Access enhanced options for Conditional Access, including the ability to configure policies based on sign-in frequency, providing greater control over user access.
3. Unified Access Policy Management: Centralize the management of all access policies under a single umbrella, streamlining administrative tasks and improving efficiency.
4. Report-Only Mode and Graph API Integration: Implement a report-only mode for policies and seamlessly integrate with the Graph API for comprehensive policy monitoring and data retrieval.
5. Enhanced Flexibility in Access Control: Extend your control over access by incorporating various risk conditions, such as location-based criteria, to ensure a more robust security framework.

In this section we are going to migrate risk policies in Identity Protection to risk-based Conditional Access policies in Microsoft Entra. The following steps are encompassed within this:

1. Create user risk-based Conditional Access policy
2. Create sign-in risk-based Conditional Access policy
3. Enable the new risk-based Conditional Access policies
4. Disable the Identity Protection risk policy

When it comes to setting up user risk-based Conditional Access policies in Microsoft Entra, organizations have the flexibility to implement these policies through individual steps or by utilizing predefined Conditional Access templates. Now, let’s explore the process of creating a user risk policy in Conditional Access in this section.

Note: Before configuring it, you need to analyze the impact it will make on users. To do it, you can use the risk-based access policies workbook in Entra ID. It gives you different user risk and sign-in risk scenarios. So, you can analyze and tweak your planned risk policies based on the requirement.

1. Navigate through the path below as at least with a Conditional Access Administrator role.

Microsoft Entra admin center 🡢 Identity 🡢 Protection 🡢 Conditional Access 🡢 Create new policy

2. Give an identifiable name to your policy.
3. In the Assignments section, choose “Users.”
   • In the “Include” category, select “All users.”
   • For the “Exclude” option, go with “Users and groups” and then specify your organization’s emergency access or break glass accounts.
4. Navigate to “Target and resources” and select “All cloud apps.”
5. In the “Conditions” section, enable the Configure option to “Yes.”
6. Set the “Configure user risk levels needed for policy to be enforced” to “High,” and then click “Done.”

7. Under “Access Controls,” select “Grant.”
8. Check the box for “Grant access” and choose either “Require multi-factor authentication” or “Require password change.” Click “Select.”
9. In the “Session” panel, you can set the “Sign-in frequency.”
10. Select “Every time” for the sign-in frequency, and make sure to click “Select.”
11. Review your policy settings and enable the policy in “Report-only mode.” Conditional Policy state known as “Report-only mode” enables administrators to evaluate the potential effects of CA policies before activating them within the environment.
12. Finally, click the “Create” button to create the user risk-based Conditional Access policy.

Under this section, let’s explore how to create a sign-in risk policy in Conditional Access.

1. Follow the path below as at least with a Conditional Access Administrator role.

Microsoft Entra admin center 🡢 Identity 🡢 Protection 🡢 Conditional Access 🡢 Create new policy

When creating the policy:

2. Give your policy a descriptive and meaningful name.
3. In the “Assignments” section, select “Users.”
4. Include “All users.”
5. Exclude “Users and groups” and specify your organization’s break glass accounts.
6. Under “Target and resources,” choose “All cloud apps.”
7. In the “Conditions” section, enable the “Configure” option to “Yes.”
8. Specify the sign-in risk level by setting the “Select the sign-in risk level this policy will apply to” into the “High and medium” value and then click “Done.”

In the “Access Controls” section:

9. Choose “Grant.”
10. Check the box for “Grant access” and select “Require multi-factor authentication.”
11. Click “Select.”

In the “Session” panel:

12. Set the “Sign-in frequency” to “Every time.”
13. Click “Select.”

Review your policy settings and:

14. Enable the policy in “Report-only mode.”
15. Finally, click the “Create” button to create the user sign-in risk-based Conditional Access policy.

NOTE: Once you’ve verified and set your policy to run in the report-only mode state, an administrator has the option to switch the policy toggle from “Report-only” to “On” to activate it.

Before activating the recently established risk-based Conditional Access policy, it’s crucial to validate its functionality by testing it in report mode. Additionally, you can simultaneously run both Identity Protection and Conditional Access policies to ensure that the new policies operate as intended before deactivating the risk policies within Identity Protection.

• Once all verifications have been completed, return to the Protection section and navigate to Conditional Access.
• Choose the newly created risk policy for editing under Policies.
• Subsequently, change the “Enable policy” setting to “On” to activate the respective Conditional Access risk policies.

Furthermore, organizations have the option to investigate and remediate any existing risks before activating these remediation policies.

Now, it’s time to deactivate the previous risk policies in Identity Protection.

• Navigate to the Identity 🡢 Protection 🡢 Conditional Access.
• Choose the User risk and Sign-in risk policy.
• Switch the “Policy enforcement” setting to “Disabled.”

In conclusion, we have effectively transitioned our risk policies to risk-based Conditional Access policies, offering us the flexibility to configure Conditional Access policies for both risky users and risky sign-in attempts. Furthermore, you can fortify your security measures by implementing device-based Conditional Access policies, enhancing your overall Microsoft 365 security posture. More importantly, it is needed to stay aware of the CA policy changes. So, you can monitor Conditional Access policies with M365DSC. It will help you to get alerts instantly about policy changes, and also you can make use of it to auto-correct the modified policy.

Additionally, to tighten your protection, consider activating the security features in Microsoft Entra. We hope this blog has provided you with a comprehensive understanding of risk-based Conditional Access policies and the migration process from Entra Identity Protection to Conditional Access. If you have any questions or insights to share, please don’t hesitate to reach out in the comments section. Your feedback is greatly appreciated!