Microsoft Entra Conditional Access 101: The Basics, No Frills, All Essentials

Welcome to Microsoft Entra, where Zero Trust, permissions, and the infamous policy change await. Buckle up—this rabbit hole goes deep!

IAM, or Identity & Access Management, is undoubtedly one of the most critical pillars of cybersecurity. The reason for this is simple: we want to trip up adversaries as much as possible while still allowing our end users access to necessary data, applications, and more, all while adhering to the Zero Trust principles—Assume Breach, Verify Explicitly, and Use Least-Privilege Access. To achieve this, as a Microsoft-focused professional, I turn to Microsoft Entra for my IAM needs, where one of the most powerful tools is Identity Protection through Conditional Access.

That said, I often see people in the community asking variations of the same questions: “What Conditional Access policies should I implement?”, "Where should I begin?"

Having worked with IAM and Conditional Access daily for several years, building on Microsoft’s architecture and enriched by my own real-world experiences, I’ll be answering this question—and hopefully any others you might have—throughout my Conditional Access series.

So, let’s get the show on the road with a deep dive into how, why, and what you should focus on as you start building your Conditional Access environment!

Table of content:

1. Identity & Access Management, is it really THAT important?

2. How the Conditional Access Authentication Flow works

3. How to: Microsoft Entra Conditional Access - The basics

   1. Creating the first CAP

4. Microsoft Entra Essentials - The Bare Minimum

   1. Entra Essentials - The Naming

   2. The Miscellaneous - Assignments, Exclusions, etc.

5. The Meat of the Post: The Essential CAPs

   1. Entra Essentials – Conditional Access Policies

6. Wrapping up this CAP-tivating subject

---

Identity & Access Management, is it really THAT important?

This isn't something IT pros usually contest, but for the C-suite and anyone else who needs convincing, let's check the facts.

According to Microsoft's latest cybercrime report, identity-based attacks have skyrocketed, hitting an alarming 4,000 attacks per second. These can include a mix of tactics like Adversary-in-the-Middle (AiTM), MFA interception, token theft, brute force attacks, and phishing (to name just a few).

Even if we assume just 0.1% of these attacks succeed, that’s still 40 compromised identities per second—which could mean serious trouble for your company’s bottom line, and not to mention, a massive headache for you as the admin.

By leveraging Microsoft Entra Conditional Access policies, you can dramatically reduce the chances of a successful attack. In fact, you could even shut down access entirely if needed. But let’s be real—most companies (probably including yours) don’t operate in “no access allowed” mode. Your goal is to find that golden balance between security and business usability.

I’ve spent a lot of time tweaking, testing, and breaking things so you don’t have to.

---

How the Conditional Access Authentication Flow works

So, we’ve covered the why—now let’s get into the how.

If you check out Microsoft’s documentation, you’ll find this simplified diagram that illustrates the Conditional Access authentication flow from a high-level perspective.

Used with permission from Microsoft. Source: Microsoft Learn: What is Conditional Access?

For a deep dive into the nitty-gritty of the authentication flow, check out this blog post.

Quick summary:

When an access attempt is made, various signals come into play. These signals can include (but aren’t limited to) factors like device type, geolocation, network, user risk level, the application in use, the flow type, and how often sign-ins occur.

These signals are evaluated during the sign-in process and checked against the Conditional Access policies set in the target tenant.

Based on that evaluation, access is either granted—or denied.

---

How to: Microsoft Entra Conditional Access - The basics

Now that we understand why managing identities and access is essential, let’s dive into how to do it.

First things first, Microsoft Entra Conditional Access has a few prerequisites you need to meet before you can start tweaking settings.

Requirements:

• Microsoft Entra ID P1

• Microsoft Entra Workload ID Premium (for Workload policies)

• Microsoft Entra ID P2 (for risk-based policies)

• Security Defaults set to Disabled

Good news: You only need one of the licenses to get started! These are often bundled into licenses like Business Premium or Microsoft 365 E3.

Conditional Access is a tenant-wide feature, meaning it’s enabled for the entire tenant. With just a single license, you can configure the necessary policies across your environment.

However, keep in mind that these license requirements must be met for every workload, user, and admin to whom your Conditional Access Policy (CAP from here on out) applies.

For a full breakdown of license requirements, I highly recommend checking out Aaron Dinnage’s M365 Maps.

Creating the first CAP

With the requirements in place, it’s time to create your first Conditional Access Policy. This is done in the Entra Portal, which you can access directly or through the Admin, Purview, Exchange, or Azure portals.

Here’s a step-by-step guide to creating a CAP:

1. Access the Entra portal and navigate to the Conditional Access pane under Protection. Tip: I usually go straight to entra.microsoft.com for quick access!

   

   
   

2. Create a policy from scratch or use one of the templates provided by Microsoft. Templates allow you to preview settings before selecting one.

   

   
   

3. If you choose “Create new policy,” you’ll start with a clean slate. Let’s go with this option for our example.

   

   
   

4. Name your policy and configure the necessary settings. You can set the policy state to:

   • Off (disabled)

   • On (enabled)

   • Report only (for logging)

   

   
   

   Note: Report only is a great option if you want to monitor the impact of a policy without enforcing it right away. I recommend testing new policies on a subset of users and gradually rolling them out.

   
   

5. Once the policy is created, you can always go back and edit both the configurations and the state.

   

   
   

---

Microsoft Entra Essentials - The Bare Minimum

By now, we know why identity management matters, how the authentication flow works, and how to create Conditional Access policies. But we’re still left with the question: What exactly should we implement?

As a consultant, I ensure that every recommendation, setting, policy, and product I work with is built with a Zero Trust mindset—because that’s how it should be! This philosophy extends to the Conditional Access Policies (CAPs) I implement.

Without diving too deep just yet, the following recommendations are based on the Enterprise Access Model.

For a more detailed breakdown, I recommend checking out Claus Jespersen’s Persona-Based Conditional Access for Zero Trust Architecture.

I’ve created several CAPs in importable JSON format, available on my GitHub. Let’s walk through these policies and explore why they should be implemented, along with their expected business impact. Keep in mind, the impact outlined here is a general guideline—not an absolute!

Entra Essentials - The Naming

When managing Conditional Access Policies (CAPs), having a clear and structured naming convention is key for usability and reporting (i.e., Kusto queries). Here’s the naming convention I recommend using:

<CANumber>-<GrantControl>-<PolicyType>-<Persona>-<App>-<Platform>-<OptionalDescription>

Each component provides quick insight into the policy’s purpose, making management and querying easier.

Component	Description/Example
CA Number	Identifies and groups CAPs by persona and block/allow policies. Example: CA000-CA099.
Grant Control	Explains what is configured for the Grant control (e.g., block, MFA, CompliantOREntraHJ).
Policy Type	Describes the type of policy (e.g., AppProtection, IdentityProtection, AttackSurfaceReduction).
Persona	Indicates who/what the policy applies to (e.g., Global, Admin, Guest, Workload & Service Accounts, Specific Users/Groups).
App	Specifies the app the policy applies to (e.g., AllApps, O365, ServiceNow).
Platform	Describes the platform (e.g., AnyPlatform, WindowsPhone, macOS, iOS, Android, iOS & Android).
Description	Optional—provides additional context or version number (e.g., v2.34).

Number Scheme

Instead of grouping by persona alone, I’ve split the number scheme into two sections: one for blocking policies and another for granting access. Here’s the matrix:

Grant	Persona	Number Range
	Global	CA000-CA099
	Admin	CA100-CA199
BLOCK POLICIES	Guest	CA200-CA299
	Workload & ServiceAccounts	CA300-CA399
	Specific Users or Groups	CA400-CA499
	Global	CA500-CA599
	Admin	CA600-CA699
ALLOW POLICIES	Guest	CA700-CA799
	Workload & ServiceAccounts	CA800-CA899
	Specific Users or Groups	CA900-CA999

Streamlined Management

I’ve slightly altered some of the personas suggested in Microsoft’s recommendations by merging a few for more streamlined management. This approach provides a clearer overview, making it easier to manage CAPs effectively.

The Miscellaneous - Assignments, Exclusions, etc.

There's a few miscellaneous points I'd like to highlight. Let’s start with a bit of context:

Conditional Access policies are always evaluated during authentication attempts in an AND context. This means all policies undergo their own evaluation and are combined with other policies before granting or denying access.

When evaluating a Conditional Access Policy (CAP), exclusions are prioritized. So, if you include a group where a specific user is a member but also exclude that user, the exclusion will take precedence.

Now, with that in mind, let’s dive into assignments and my recommendations!

I recommend using All users for as many policies as possible, while excluding groups that should be left out. Here’s why:

1. Avoid leaving users unprotected, which could lead to security compromises.

2. Group membership limits (2056 memberships per user) and processing time.

For policies targeting specific user groups, using static or dynamic group memberships makes sense depending on your needs—but keep those limits in mind!

For Persona-based CAPs, create dynamic groups for specific Personas like admins, guest users, and so on. This allows for more granular control. My CAPs follow these principles for assignments.

Now, let’s talk about exclusions.

• If you're using Microsoft Intune, make sure to exclude the Microsoft Intune Enrollment cloud app. This app is crucial during Autopilot deployment, and if it’s not excluded, you risk breaking the enrollment flow.

  
  

  Haven’t used Intune before? You might find that the application isn’t available for exclusion yet. No problem—you can add it manually using PowerShell:

Connect-AzureAD -Identity minimumcloudapplicationadmin@yourdomain.com New-AzureADServicePrincipal -AppId d4ebce55-015a-49b5-a083-c84d1797ae8c Disconnect-AzureAD

• Another common exclusion: if you use Azure Virtual Desktop (AVD), make sure to exclude your AVD hosts in your CAPs. Without this, you'll end up stuck in an authentication loop! But don’t worry, we can set up a separate policy to manage MFA at sign-in so that authentication still happens before users reach the AVD host.

  
  

That wraps up the key points on assignments and exclusions. In a future post, I'll share some "out-of-bounds" policies I’ve had to create over the years, so stay tuned!

---

The Meat of the Post: The Essential CAPs

Let’s finally get to the essential policies! Below are the bare minimum CAPs I recommend every organization implement—regardless of size. These are all created from an objective viewpoint, so be sure to modify them to fit your organization’s specific needs!

Entra Essentials – Conditional Access Policies

CAP 01: Block Legacy Authentication

CA000-Block-BaselineProtection-Global-AllApps-AnyPlatform-Block legacy authentication v1.0

JSON | MITRE ATT&CK Technique ID: T1078

Disables older, less secure authentication methods, such as Exchange ActiveSync or basic Auth.

CAP 02: Block Unknown platforms

CA001-Block-DeviceProtection-Global-AllApps-WindowsPhone-Block Unknown platforms v1.0

JSON | MITRE ATT&CK Technique ID: T1098

Blocking unknown platforms ensures that only verified and secure devices can access corporate resources, preventing potential breaches from unsecured devices.

CAP 03: Block countries without business

CA002-Block-AttackSurfaceReduction-Global-AllApps-AnyPlatform-Block non-business countries v1.0

JSON | MITRE ATT&CK Technique ID: T1627.001

Blocking access from non-business countries reduces the attack surface by preventing unnecessary exposure to regions where no legitimate business activities occur.

CAP 04: Enable MFA for all users

CA500-MFA-BaselineProtection-Global-AllApps-AnyPlatform-Require MFA for all users v1.0

JSON | MITRE ATT&CK Technique ID: T1098

Ensures a strong layer of protection across the board by requiring multi-factor authentication for every user.

CAP 05: Require MFA for registering security info

CA501-MFA-BaselineProtection-Global-CombinedRegistration-AnyPlatform-Require MFA for registering security info v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Requiring MFA to register or update security information ensures that only the legitimate account owner can modify these settings, protecting accounts from unauthorized changes.

CAP 06: Require App Protection Policy for mobile applications

CA502-APP-Data&AppProtection-Global-O365-iOS&Android-Require App Protection Policy v1.0

JSON | MITRE ATT&CK Technique ID: T1636

Requiring an App Protection Policy ensures that business data remains protected on mobile devices by enforcing security measures such as encryption and data wipe if certain conditions are met (e.g., device compromise).

NOTE: Modify applications depending on the affected apps in your App Protection Policy.

CAP 07: Session lifetime for managed devices

CA503-SessionControl-DataProtection-Global-AllApps-AnyPlatform-8H session lifetime for managed devices v1.0

JSON | MITRE ATT&CK Technique ID: T1185

Limiting session lifetime to 8 hours ensures that users have to re-authenticate periodically, reducing the window for unauthorized access while balancing productivity for managed devices.

CAP 08: Session lifetime for unmanaged devices

CA504-SessionControl-DataProtection-Global-AllApps-AnyPlatform-3H session lifetime for unmanaged devices v1.0

JSON | MITRE ATT&CK Technique ID: T1185

Setting a 3-hour session lifetime for unmanaged devices minimizes the risk of extended unauthorized access, as users must re-authenticate frequently, reducing exposure from less secure devices.

CAP 09: Enable Phishing-resistant MFA for Admins

CA600-AuthStr-IdentityProtection-Admins-AllApps-AnyPlatform-Require Phishing-Resistant MFA for Admin roles v1.0

JSON | MITRE ATT&CK Technique ID: T1098 & T1566

As admins have privileged access, it's paramount to secure their access. Phishing-resistant authentication adds an extra layer of security to protect the admin accounts from phishing attempts and credential-based attacks.

CAP 10: Enable MFA for all externals

CA700-MFA-BaselineProtection-Guests-AllApps-AnyPlatform-Require MFA for all guest users v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Requiring MFA for guest users, reduces the risk of unauthorized access to your corporate sensitive data.

CAP 11: Require Term of Use acceptance by guest users for Security info registration

CA706-TOU-ComplianceProtection-Guests-CombinedRegistration-AnyPlatform-Require TOU for security info for Guests v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Requiring Terms of Use (TOU) acceptance for updating security information ensures compliance with the corporate policies, while raising the guest users awareness for the security obligations that's placed upon them.

---

Wrapping up this CAP-tivating subject

So, there you have it!

We’ve taken a solid journey through Microsoft Entra’s Conditional Access essentials, uncovering why these policies matter, how they work, and—most importantly—what you should implement to protect your environment. Identity and Access Management is no small task, but with the right strategies in place, you can strike the perfect balance between usability and airtight security, hopefully these help with the first few steps on the road.

Remember, Conditional Access isn’t just a set-it-and-forget-it deal. These policies should evolve as your organization grows, your risks change, and new threats emerge. But by sticking to Zero Trust principles and the CAPs outlined here, you’re already off to a strong start.

And now, I’ll leave you with a little joke to lighten the load after all that tech talk:

What did the password say to Conditional Access?

You complete me, but without MFA, I’m just insecure. 😎

Stay tuned for the next post, where we’ll dive into the next "tier" of Conditional Access including P2 features and explore device and risk-based policies. Until then, happy configuring!