Microsoft Entra Baseline Conditional Access Policies

A list of baseline Conditional Access Policies to help secure your Microsoft environment

Whoa there! Show me your badge…and your location…and now your device…oh, and approve this notification I send to your phone…oh, sorry, do you mind removing your shoes before you come in?

What this article covers:

• Why you should use Microsoft’s Conditional Access features
• Recommended Baseline Conditional Access Policies

Why use Conditional Access

Conditional access isn’t anything new, but I find that it’s not the easiest concept to grasp (as is the case with a lot of Microsoft’s products). If you’re reading this, I’m assuming you have a general understanding of what a Conditional Access Policy (CAP) is already. At a high level, it’s the “who, what, when, where, and how” someone can log in to your Microsoft cloud resources. However, it gets a lot more complex than just “require MFA for everyone!” (although that is a policy you should have in place). They function like “if–then” statements: if certain conditions are met — such as the user’s identity, device state, location, or risk level — then a specific action is enforced, like allowing access, blocking access, or requiring additional controls such as multi-factor authentication.

Baseline Policies

To start, here are a set of baseline policies to get started. There are additional policies recommended by Microsoft that this article will discuss as well along with reasons for them to not be included in our baseline list.

Naming Convention

Implement a strong naming convention for your policies.

Being able to look at the policy name and understand the resources and users that it targets, along with the conditions and what actions it takes, makes it easier to view your policies holistically at a glance.

Microsoft provides a recommended naming convention. You can find more regarding that here: Microsoft — Set naming standards for your policies.

TIP: Use gaps in numbering for this, since policies are subject to change. This makes it easier to add new policies and organize them later on.

CA00 — All Apps: Require MFA for All Users

• What this policy does This policy requires MFA for all users. This is the single most important CAP you can enable, but it can be modified slightly depending on your needs.
• Why this policy is important Enabling MFA is one of the simplest and most effective ways to secure accounts. Are there bypasses? Absolutely, and we’ll cover those with other policies, but this needs to exist first and foremost.

CA10 — Register Security Info: Require MFA for All Users

• What this policy does Microsoft allows users to manage their own security information (aka.ms/mysecurityinfo). This means self-service password resets, phone number updates, or modifying authentication methods. This policy requires users to satisfy a current MFA method before adding or changing methods.
• Why this policy is important One of the first steps a threat actor will take after gaining access to a user’s account is find a way to maintain persistence. Adding their own MFA method does just that. While they may have bypassed the initial MFA CAP and gained access to a user’s session, if they have to find a way to bypass a second MFA prompt to add their own authentication method, then it will slow them down significantly.

Note: This policy will require a Temporary Access Pass workflow to allow users to register security info if they do not already have a method set up. This may not be plausible depending on your scenario or onboarding process.

CA20 — All Apps: Block for All Users when On Travel Advisory List

• What this policy does This only applies if your country maintains a travel advisory list, or if you reference the U.S. travel advisory list. This policy prevents logins from countries on that list (typically only the higher level countries).
• Why this policy is important This is only applicable if you do not conduct business outside of your country OR you only conduct business within a certain range of countries. In the U.S., for example, if you know your user base is purely inside of the U.S., blocking level 3 and 4 countries on the travel advisory list is a good idea. No, this doesn’t prevent logins over anonymous IPs / VPNs, but I always advise blocking that activity as well.

CA30 — All Apps: Block for All Users when Using Legacy Authentication

• What this policy does Old protocols like SMTP still exist, and yes, certain Microsoft products still support these. Microsoft started to disable these protocols by default, but you will see a Microsoft Managed CAP in your list for this. I typically disable their policies in favor of ones I have more control over, but having a policy in place is the most important piece.
• Why this policy is important Based on Microsoft’s analysis, more than 97 percent of credential stuffing attacks use legacy authentication and more than 99 percent of password spray attacks use legacy authentication protocols.

CA40 — All Apps: Block for All Users when Not in US

• What this policy does Blocks access outside of the U.S.
• Why this policy is important These policies are being applied in the U.S.; if you are outside of the U.S., you should consider restricting access to your home country. Again, this only applies if you do not conduct business outside of your location.

CA50 — All Apps: Block for All Users when in IncidentResponse-BlockSignIn Group

• What this policy does Blocks access for any users in a specific group.
• Why this policy is important One of the quickest ways to handle a compromised account is to throw them into a group that blocks their access. The key to making this work is to ensure that session control is used, continuous access evaluation is used, and sign-in frequency is set to “every time.”

CA60 — All Apps: Require MFA for All Users when Sign-In is Risky

• What this policy does Requires users to satisfy a new MFA prompt if the sign-in is seen as risky.
• Why this policy is important Microsoft has built-in detections for suspicious sign-in behavior on a user’s account. This is called a Risky Sign-In Detection. If a user’s sign-in appears to be risky, it will ideally require them to satisfy a new MFA prompt.

Note: Taking action on risky users in Microsoft Entra requires P2 licensing for any user targeted with that policy.

CA70 — All Apps: Require Risk Remediation for All Users when Risk is Medium or High

• What this policy does Requires flagged “risky users” to have been remediated prior to signing back in. This could be an admin password reset, SSPR, and/or an MFA reset.
• Why this is important In the same way that Microsoft flags a risky sign-in, it can also correlate other factors to determine if a user’s account has been compromised, at which point it labels them as a “Risky User.”

Optional, but recommended: If your specific workflow or scenario supports it, blocking users labeled as Medium or High risk and requiring admin interaction through an admin-driven password reset or dismissal is a more secure way of managing risky users.

Reminder: Taking action on risky users in Microsoft Entra requires P2 licensing for any user targeted with that policy.

CA80 — Azure Management: Block for All Users when Not in Azure Admins Group

• What this policy does Requires users to be added to a specific managed cloud-only group before they can log in to any Azure management portal.
• Why this is important This policy allows you to prevent any user from logging in to the Azure management portal, but more importantly, it allows you to keep better track of who can log in and who your admins are as a whole, regardless of privilege level.

CA90 — Azure Management: Require Strong MFA for All Users when in Azure Admins Group

• What this policy does Requires users in the Azure Admins Group to use a strong MFA method (Passkey or Security Key) when signing in to the Azure Management portal.
• Why this is important Passkeys and Security Keys are less susceptible to being stolen or phished than traditional MFA methods. Pair these with cloud-only admin accounts without email access for additional benefits.

CA91 — Azure Management: Require MFA for All Users when Activating PIM Roles

• What this policy does Requires accounts with assigned admin roles to satisfy an MFA prompt when activating that role.
• Why this is important If an admin account is compromised, you do not want those privileges being readily available. This helps reduce risk by requiring that account to satisfy a new MFA prompt before a PIM role is activated.

Remember, these are baseline policies. This is not a comprehensive list of what can be done with conditional access, and new recommended policies will be added by Microsoft over time.

Thanks for reading! Please be on the lookout for new articles explaining how to configure these policies going forward.