Mastering Microsoft Entra ID Conditional Access Policies: A Comprehensive Guide

 

Introduction

In today’s dynamic digital landscape, crafting a robust Conditional Access (CA) deployment is pivotal for securing your organization’s apps and resources. Microsoft Entra ID's Conditional Access policies offer extensive configuration options, allowing organizations to tailor access controls precisely. However, this flexibility requires meticulous planning to prevent unintended consequences.

Understanding Conditional Access

Source: Microsoft

The modern security perimeter now includes user and device identities, requiring identity-driven signals for access control. Microsoft Entra Conditional Access centralizes these signals to enforce organizational policies, forming the backbone of Microsoft’s Zero Trust policy engine. Conditional Access policies operate on simple if-then logic: if a user wants to access a resource, they must perform a specified action, such as multifactor authentication.

Administrators have two main goals: empower user productivity and protect organizational assets. Conditional Access helps achieve this by applying the right controls at the right time, balancing security with productivity.

Key Point: Conditional Access is crucial to Microsoft’s Zero Trust framework. While Entra Tenant security defaults provide basic protection, Conditional Access offers granular control, allowing for tailored security beyond default settings.

Conditional Access policies are applied after the first factor of authentication is completed. While Conditional Access is not designed to be the primary defense against scenarios like denial-of-service (DoS) attacks, it can utilize signals from such events to inform access decisions.

Prerequisites for Effective Deployment

To set up Conditional Access, ensure you meet the following prerequisites:

1. Microsoft Entra Tenant: A working tenant with Microsoft Entra ID P1, P2, or a trial license. Microsoft Entra ID P2 is essential for integrating Microsoft Entra ID Protection risk into Conditional Access policies. 

2. Administrative Roles:

  - Global Admin or Conditional Access Administrator: For creating or modifying policies.

 - Security Reader: For reading policies and configurations.(Optionally for Policy review without Grading High privileged roles)

3. Required User\Groups: Needs to be identified to Target the policy Assignments/Exclusions 

Core Components of Conditional Access Policies

Conditional Access policies operate on the principle of if-then scenarios:

- If Assignment Met: Apply the access controls.

  - Example: If a HR user accesses the HR app, require multi-factor authentication (MFA) and a compliant device.

  - Example: If a user is not a HR member accessing HR App, block access.

Policies can be designed to grant access, enforce session controls, or block access based on these conditions.

Exclusions to Consider

While you create powerful Conditional Access policies, it should exclude:

- Emergency Access Accounts: Essential for recovering access in case of a tenant-wide lockout.

- Service Accounts and Principals: Typically non-interactive and unable to complete MFA.

Note: Consider replacing these accounts with managed identities or temporarily excluding them from your Tenant baseline CA policies.

Best Practices for Conditional Access in Entra ID

1. Apply Policies to All Apps: Create comprehensive policies for all cloud apps and exclude exceptions. This ensures consistent application and reduces administrative overhead.

2. Minimize Policy Count: Avoid creating excessive individual policies. Group apps with similar requirements into single policies to stay within the 195-policy limit and simplify management.

3. Use Report-Only Mode: Test policies using report-only mode to assess impact before full deployment. Leverage the sign-in logs and Conditional Access insights for evaluation.

4.Set naming standards for your policies: A consistent naming standard makes it easier to identify policies and understand their function without needing to open them in the Entra admin portal. Microsoft suggest naming your policies to include: A sequence number, The cloud apps, The policy applies to, The intended response, The target users or groups, The conditions under which it applies.

Example Policy:

CA01 - Dynamics ERP: Require MFA For Marketing When On External Networks

Syntax:

<CA01> - <Dynamics ERP>: <Require MFA> For <Marketing> When <On External Networks>

In this syntax:

<CA01> represents the unique identifier or name of the policy.

<Dynamics ERP> specifies the cloud application or service the policy applies to.

<Require MFA> indicates the action to be taken, in this case, requiring multi-factor authentication.

<Marketing> identifies the group or role that the policy targets.

<On External Networks> describes the condition under which the policy is enforced.

This format provides a clear and consistent way to document and implement Conditional Access policies.

5. Plan for Disruptions: Develop resilience strategies and naming standards for emergency policies. For instance, policies with names like EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] -Exchange SharePoint Entra hybrid join For VIP users .It helps in identifying and prioritizing emergency actions.

6. Block Unnecessary Regions: Use named locations to block sign-ins from regions where you do not expect legitimate access.

Top 25 Conditional Access policies

CA001-Require MFA for administrators

Accounts with administrative rights are prime targets for attackers. Implementing multifactor authentication (MFA) for these accounts is a straightforward way to reduce the risk of compromise. Microsoft strongly recommends enforcing MFA for at least the following roles:


- Global Administrator
- Application Administrator
- Authentication Administrator
- Billing Administrator
- Cloud Application Administrator
- Conditional Access Administrator
- Exchange Administrator
- Helpdesk Administrator
- Password Administrator
- Privileged Authentication Administrator
- Privileged Role Administrator
- Security Administrator
- SharePoint Administrator
- User Administrator


User Exclusions:

- Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA002-Require phishing-resistant multifactor authentication for administrators

Accounts assigned to privileged administrative roles are often prime targets for attackers. Implementing phishing-resistant multifactor authentication (MFA) for these accounts is a straightforward way to reduce the risk of compromise. Microsoft advises enforcing phishing-resistant MFA for at least the following roles:

- Global Administrator

- Application Administrator

- Authentication Administrator

- Billing Administrator

- Cloud Application Administrator

- Conditional Access Administrator

- Exchange Administrator

- Helpdesk Administrator

- Password Administrator

- Privileged Authentication Administrator

- Privileged Role Administrator

- Security Administrator

- SharePoint Administrator

- User Administrator

Organizations may choose to customize these recommendations, including or excluding roles based on their specific needs. This policy can be effectively combined with features like Privileged Identity Management (PIM), which allows for MFA to be required upon role activation.

Requiring MFA on Role Activation

You can enhance security by requiring users eligible for a role to authenticate via MFA in Microsoft Entra ID(PIM) before activating their role. MFA adds a critical layer of security by necessitating a second form of authentication, safeguarding access to sensitive data and applications.

However, users might not be prompted for MFA if they have already authenticated with strong credentials or completed MFA earlier in the session.

To ensure users authenticate during role activation, you can leverage Microsoft Entra Conditional Access with authentication context and Authentication Strengths. This ensures that users authenticate using a different method than the one they used to sign in to the machine.

For instance, if users sign in with Windows Hello for Business, you can require passwordless sign-in with Microsoft Authenticator for role activation. After users authenticate with Microsoft Authenticator, they won’t need to authenticate again for subsequent activations in the same session, as the authentication is already part of their session token.

You can refer to my previous blog posts for a detailed guide on configuring Entra ID passwordless authentication methods, including Windows Hello for Business, FIDO2 keys, Microsoft Authenticator, and certificate-based authentication.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals

Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA003-Allow security info registration from All Trusted Locations

Securing the registration process for Microsoft Entra multifactor authentication and self-service password reset can be managed through user actions within a Conditional Access policy. This capability is available to organizations that have enabled combined registration. It allows you to treat the registration process as any other application within a Conditional Access policy, leveraging the full range of Conditional Access features to secure the user experience. This policy also applies to users signing in to the Microsoft Authenticator app or enabling passwordless phone sign-in.

In the past, some organizations relied on trusted network locations or device compliance to secure the registration experience. However, with the introduction of Temporary Access Pass in Microsoft Entra ID, administrators can now issue time-limited credentials that enable users to register from any device or location. These Temporary Access Pass credentials meet Conditional Access requirements for multifactor authentication, ensuring a secure and flexible registration process.

Note: 1.Administrators have to issue Temporary Access Pass credentials to new users so they can satisfy the requirements for multifactor authentication to register.

         2.Organizations might choose to require other grant controls with or in place of Require multifactor authentication. When selecting multiple controls, be sure to select the appropriate radio button toggle to require For multiple controls

• Require all the selected controls
• Require one of the selected controls

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA004-Block Guest/External Users security info registration outside trusted Networks

For guest users who need to register for multifactor authentication in your directory, you may want to block registration from outside trusted network locations. Please note that Temporary Access Pass is not applicable to guest users.

CA005-Block legacy authentication

Due to the heightened risks associated with legacy authentication protocols, Microsoft strongly advises organizations to block authentication requests that use these protocols and enforce modern authentication instead.

The following messaging protocols rely on legacy authentication:

- Authenticated SMTP: Used for sending authenticated email messages.

- Autodiscover: Helps Outlook and Exchange ActiveSync (EAS) clients locate and connect to mailboxes in Exchange Online.

- Exchange ActiveSync (EAS): Used to connect to mailboxes in Exchange Online.

- Exchange Online PowerShell: Connects to Exchange Online with remote PowerShell. If Basic authentication is blocked for Exchange Online PowerShell, the Exchange Online PowerShell Module must be used instead. 

- Exchange Web Services (EWS): A programming interface used by Outlook, Outlook for Mac, and non-Microsoft apps.

- IMAP4: Used by IMAP email clients.

- MAPI over HTTP (MAPI/HTTP): The primary mailbox access protocol used by Outlook 2010 SP2 and later versions.

- Offline Address Book (OAB): A downloadable copy of address list collections used by Outlook.

- Outlook Anywhere (RPC over HTTP): A legacy mailbox access protocol supported by all current Outlook versions.

- POP3: Used by POP email clients.

- Reporting Web Services: Retrieves report data in Exchange Online.

- Universal Outlook: Utilized by the Mail and Calendar app in Windows 10.

User Exclusions 

- Service accounts and service principals(Which is used by any legacy application), such as the Application email relay Account. These are non-interactive accounts that are not associated with any specific user.

Note:  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA006-Require multifactor authentication for guest access

Require guest users perform multifactor authentication when accessing your organization's resources.

CA007-Require MFA for all users

MFA is essential for our users because it adds an extra layer of security beyond just a password. Passwords can be easily compromised through phishing, brute force attacks, or other methods, but MFA requires an additional verification step, such as a code from a mobile app or a biometric scan. This makes it significantly harder for attackers to gain unauthorized access, protecting our sensitive data and systems from breaches. In today's threat landscape, relying on passwords alone is simply not enough to ensure the security of our users and our organization.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

Application Exclusion 

Organizations that utilize the Subscription Activation feature to allow users to upgrade from one version of Windows to another and implement Conditional Access policies to control access should exclude the following cloud app from their Conditional Access policies by using the "Select Excluded Cloud Apps" option. 

• Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f.

This exclusion is crucial because, if a device remains offline for an extended period, it might not automatically reactivate without this Conditional Access exclusion in place. Ensuring this exclusion allows Subscription Activation to function smoothly without interruptions.

Similarly, to ensure that device auto-enrollment scenarios function properly, Microsoft Intune and Microsoft Intune Auto Enrollment must also be excluded from Conditional Access policies. This exclusion is necessary for seamless device auto-enrollment.

Note: Starting with Windows 11, version 23H2 with KB5034848 or later, users will be prompted to authenticate via a toast notification when Subscription Activation requires reactivation. The notification displays the following message:

"Your account requires authentication. Please sign in to your work or school account to verify your information."

Additionally, the Activation pane may show the following message:

"Please sign in to your work or school account to verify your information."

CA008-Require MFA for Azure management

Organizations often use various Azure services and manage them through Azure Resource Manager-based tools such as:

• Azure portal
• Azure PowerShell
• Azure CLI

These tools grant highly privileged access to resources, allowing users to make significant changes, including:

• Modifying subscription-wide configurations
• Adjusting service settings
• Managing subscription billing

To protect these sensitive resources, Microsoft strongly recommends requiring multifactor authentication (MFA) for any user accessing them. In Microsoft Entra ID, these tools are grouped under the Windows Azure Service Management API suite. For Azure Government, the equivalent suite is the Azure Government Cloud Management API app. When you target the Windows Azure Service Management API application, the policy is enforced for tokens issued to a set of services closely integrated with the portal, which includes the application IDs for:

• Azure Resource Manager
• Azure portal, including the Microsoft Entra admin center
• Azure Data Lake
• Application Insights API
• Log Analytics API

Because this policy is applied to the Azure management portal and API, it can indirectly affect services or clients that depend on the Azure API. For example:

• Azure CLI
• Azure Data Factory portal
• Azure DevOps
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• Classic deployment model APIs
• Microsoft 365 admin center
• Microsoft IoT Central
• SQL Managed Instance
• Visual Studio subscriptions administrator portal

Note: The Windows Azure Service Management API application applies to Azure PowerShell, which interacts with the Azure Resource Manager API. However, it does not apply to Microsoft Graph PowerShell, which interacts with the Microsoft Graph API.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA009-Sign-in risk-based multifactor authentication

In most cases, users exhibit consistent behavior that can be tracked. However, when a user deviates from this norm, it may be risky to allow them to sign in without additional verification. In such situations, you might consider blocking the user or requiring them to complete multifactor authentication (MFA) to confirm their identity.

A sign-in risk reflects the likelihood that a specific authentication attempt is not being made by the legitimate identity owner. For organizations with Microsoft Entra ID P2 licenses, Conditional Access policies can be created that incorporate Microsoft Entra ID Protection's sign-in risk detections.

Sign-in risk-based policies help protect users by preventing them from registering for MFA during risky sessions. If users haven’t registered for MFA, their risky sign-ins are blocked, resulting in an AADSTS53004 error message.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA010-User risk-based password change

Microsoft partners with researchers, law enforcement, internal security teams, and other trusted sources to identify leaked username and password combinations. Organizations with Microsoft Entra ID P2 licenses can take advantage of this information by creating Conditional Access policies that incorporate user risk detections provided by Microsoft Entra ID Protection.

Microsoft Entra ID Protection equips organizations with valuable insights into suspicious activities within their tenant, allowing for quick responses to prevent further risks. These risk detections are a powerful tool, capable of identifying suspicious or anomalous activities related to user accounts in the directory.

User risk detections may flag a legitimate account as risky if a threat actor compromises the credentials or if unusual user activity is detected. Sign-in risk detections estimate the likelihood that an authentication attempt is not made by the legitimate account owner. The ability to detect risks at both the user and sign-in levels is crucial for organizations to effectively protect their tenants.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA011-Block access for users with insider risk

In any organization, most users exhibit predictable behavior that can be monitored. However, when a user deviates from their normal pattern, it may pose a security risk. To manage this, you might choose to block the user or require them to review a specific terms of use policy. Microsoft Purview can enhance access control decisions by providing insider risk signals to Conditional Access, which can be especially valuable in managing potential internal threats.

Microsoft Purview's insider risk management (included in M365 E5 license ), which must be enabled to use its signals in Conditional Access, considers data governance, data security, and compliance configurations. These signals, based on factors such as user behavior, historical patterns, and anomaly detection, allow administrators to create Conditional Access policies that respond to insider risks by blocking access, requiring stronger authentication, or mandating terms of use acceptance.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA012-Requires Compliant Device

Microsoft Intune and Microsoft Entra collaborate to enhance your organization’s security through the use of device compliance policies and Conditional Access. Device compliance policies in Intune are essential tools for ensuring that user devices meet the necessary configuration standards before accessing protected services. These policies enforce minimum requirements, such as security settings, OS versions, and more, when users attempt to access services governed by Conditional Access policies.

For Conditional Access policies to function as intended, it is crucial to have a compliance policy in place within Microsoft Intune. Without it, the Conditional Access policy may not enforce the required controls. Therefore, it is recommended to create a compliance policy first and ensure that at least one device is compliant before moving forward with Conditional Access configurations.

Even when you set the Conditional Access policy to "Require device to be marked as compliant" for all users and all cloud apps, it won't block the enrollment of new devices into Intune. This means that you can still enroll devices into Intune, allowing them to become compliant and thereby ensuring that they meet your organization’s security requirements before gaining access to sensitive resources.

By properly setting up and integrating Intune compliance policies with Microsoft Entra Conditional Access, your organization can maintain a robust security posture, ensuring that only compliant devices can access critical resources. This approach provides a seamless and secure user experience while safeguarding your organizational data.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

Application Exclusion 

Organizations that utilize the Subscription Activation feature to allow users to upgrade from one version of Windows to another and implement Conditional Access policies to control access should exclude the following cloud app from their Conditional Access policies by using the "Select Excluded Cloud Apps" option. 

• Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f.

CA013-Require compliant or Microsoft Entra hybrid joined device for administrators

Accounts with administrative rights are prime targets for attackers. To reduce potential exposure, it's advisable to require users with these highly privileged roles to perform actions only from devices that are marked as compliant or Microsoft Entra hybrid joined.

- Global Administrator

- Application Administrator

- Authentication Administrator

- Billing Administrator

- Cloud Application Administrator

- Conditional Access Administrator

- Exchange Administrator

- Helpdesk Administrator

- Password Administrator

- Privileged Authentication Administrator

- Privileged Role Administrator

- Security Administrator

- SharePoint Administrator

- User Administrator

Organizations have the flexibility to include or exclude roles as needed to best fit their security requirements.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

Application Exclusion 

Organizations that utilize the Subscription Activation feature to allow users to upgrade from one version of Windows to another and implement Conditional Access policies to control access should exclude the following cloud app from their Conditional Access policies by using the "Select Excluded Cloud Apps" option. 

• Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f.

CA014-Block access for unknown or unsupported device platform

Users are blocked from accessing company resources if their device type is unknown or not supported.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA015-Require approved client apps or app protection policy

People often use their mobile devices for both personal and work-related tasks. While it's important to ensure that staff remain productive, organizations also need to prevent data loss from applications on devices that may not be fully managed.
With Conditional Access, organizations can restrict access to approved client apps that support modern authentication, using Intune app protection policies. For older client apps that don't support app protection policies, administrators can limit access to only those approved apps. App protection policies are supported on iOS and Android for applications that meet specific requirements. On Windows, these policies are currently in preview and only supported for the Microsoft Edge browser.
It's important to note that not all applications supported as approved apps or those supporting app protection policies will enforce the "Require one of the selected controls" option under grant controls. This option functions as an OR clause within the policy, allowing users to access apps that support either the "Require app protection policy" or "Require approved client app" grant controls. The "Require app protection policy" is enforced when the app supports this specific grant control.

Application Exclusion 

The Microsoft Intune/Intune Enrollment Application should be excluded from this policy.

CA016-Require an app protection policy on Windows devices

App protection policies apply mobile application management (MAM) to specific applications on a device, enabling the secure handling of data within an application, particularly in bring your own device (BYOD) scenarios. This approach allows organizations to enable protected MAM access to organizational data via Microsoft Edge on personal Windows devices, a capability known as Windows MAM. 
Windows MAM leverages Intune Application Configuration Policies (ACP), Intune Application Protection Policies (APP), Windows Security Center client threat defense, and Application Protection Conditional Access to secure data on unmanaged devices. If a device is already managed, Intune MAM enrollment will be blocked, and APP settings will not be applied. Similarly, if a device becomes managed after MAM enrollment, APP settings will cease to apply.
There are two main categories of app protection policy settings for Windows:

• Data protection
• Health checks

Currently this Windows MAM policy applying to the Microsoft Edge browser on devices running Windows 11 and Windows 10 version 20H2 or higher with KB5031445. This includes configuring app protection policies specifically targeting Windows devices.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA017 Require reauthentication and disable browser persistence on Unmanaged Device

To protect user access on unmanaged devices, configure the browser to prevent sessions from remaining signed in after it is closed and set the sign-in frequency to require re-authentication every hour.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA018-Require a compliant device, Microsoft Entra hybrid joined device for all users

Organizations that deploy Microsoft Intune can use device information to identify those that meet specific compliance requirements, such as:

• Requiring a PIN for device unlock
• Requiring device encryption
• Enforcing a minimum or maximum operating system version
• Ensuring the device is not jailbroken or rooted

Compliance information is sent to Microsoft Entra ID, where Conditional Access determines whether to grant or block access to resources. Requiring a Microsoft Entra hybrid joined device depends on the device already being joined to Microsoft Entra hybrid.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

Application Exclusion 

Organizations that utilize the Subscription Activation feature to allow users to upgrade from one version of Windows to another and implement Conditional Access policies to control access should exclude the following cloud app from their Conditional Access policies by using the "Select Excluded Cloud Apps" option. 

• Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f.

CA019-Use application(EXO,SPO,OFB) enforced restrictions for unmanaged devices

Block or limit access to SharePoint, OneDrive, and Exchange content from unmanaged devices.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA020-Require multifactor authentication for device registration

Leverage the Conditional Access user action to enforce policies when users register or join devices to Microsoft Entra ID. This control allows for more granular configuration of multifactor authentication specifically for device registration or joining, rather than applying a blanket tenant-wide policy. Administrators can tailor this policy to meet their organization's specific security requirements.

When configuring a Conditional Access policy with the "Register or join devices" user action, it's important to set Identity > Devices > Overview > Device Settings - Require Multifactor Authentication to register or join devices with Microsoft Entra to No. Otherwise, the Conditional Access policies tied to this user action will not be properly enforced.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA021-Block access based on network location

The location condition in Conditional Access allows you to manage access to your cloud apps based on a user's network location. This condition is often used to block access from countries or regions where your organization does not expect traffic.

Note: Conditional Access policies are applied after the first-factor authentication is completed. While Conditional Access is not designed as the primary defense against scenarios like denial-of-service (DoS) attacks, it can utilize signals from such events to inform access decisions.

Follow these steps to setup Named Locations

Sign in to the Microsoft Entra admin center with at least Conditional Access Administrator privileges.

Navigate to Protection > Conditional Access > Named locations

Select the type of location you want to create:

- Countries/Regions location 

Name your location.

or IP ranges location.

Enter the IP ranges or select the Countries/Regions for the specified location.

- If you select IP ranges, you have the option to mark it as a trusted location.

- If you choose Countries/Regions, you can also opt to include unknown areas.

Finally, click Create.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA022-Require an authentication strength for external users

Authentication strength is a Conditional Access control that allows you to specify a combination of multifactor authentication (MFA) methods that external users must complete to access your resources. This control is particularly useful for securing sensitive apps from external access. For example, you can create a Conditional Access policy that requires a phishing-resistant authentication strength and apply it to guests and external users.

Microsoft Entra ID offers three built-in authentication strengths:

- Multifactor authentication strength

- Passwordless MFA strength

- Phishing-resistant MFA strength

You can choose one of these built-in strengths or create a custom one based on your required authentication methods.

For external users, the acceptable MFA methods vary depending on whether the user is completing MFA in their home tenant or the resource tenant. Currently, authentication strength policies apply only to external users authenticating with Microsoft Entra ID. For users using email one-time passcodes, SAML/WS-Fed, or Google federation, use the MFA grant control instead.

Authentication strength policies work with MFA trust settings in your cross-tenant access configuration to determine where and how external users perform MFA. When an external user signs in with their account in their home tenant and then tries to access your resources, Microsoft Entra ID checks the authentication strength Conditional Access policy and the MFA trust setting:

• If MFA trust is enabled, Microsoft Entra ID verifies if the user’s home tenant session has a claim that MFA was completed.
• If MFA trust is disabled, the resource tenant requires the user to complete MFA in the resource tenant using an approved method.

Before creating a Conditional Access policy, review your cross-tenant access settings to ensure your inbound MFA trust settings are correctly configured.

To create Authentication Strength ,Sign in to the Microsoft Entra admin center with Conditional Access Administrator privileges.

Navigate to Protection > Authentication methods > Authentication strengths.

Review the available built-in authentication strengths to determine if any meet your needs.

If you require a different combination of authentication methods, create a custom authentication strength.

CA023-Require terms of use to be accepted before accessing Microsoft Admin Portals

Organizations may want to require users\Admins to accept terms of use (ToU) before accessing specific applications within their environment. i will guide you through creating a policy that requires administrators to accept the terms of use during the initial sign-in process for any Microsoft Admin Portals.

Note: You can add up to 40 terms of use per tenant.

1. Create a new terms of use document and save it as a PDF file.

2. Sign in to the Microsoft Entra admin center with minimum Conditional Access Administrator privileges.

3. Navigate to Protection > Conditional Access > Terms of use.

4. Click on New terms at the top of the menu.

5. Enter a name for your terms of use policy in the Name textbox.

6. Upload your terms of use PDF file.

7. Select your default language.

8. In the Display name textbox, enter the name you want to be displayed.

9. Set Require users to expand the terms of use to On.

10. For Enforce with Conditional Access policy templates, choose Create Conditional access policy Later

11. Click Create to finalize your policy.

Status of Terms of Use

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA024-Block Device Code flows for All users

To enhance your security posture, Microsoft strongly recommends blocking or restricting device code flow wherever possible. Ideally, organizations should aim to implement a near-universal block on device code flow. It’s advisable to create a policy to audit the current usage of device code flow and assess its necessity.

Microsoft Entra ID supports a wide range of authentication and authorization flows to ensure a seamless experience across various applications and device types. However, some of these flows pose a higher risk than others. To give organizations more control over their security posture, Microsoft is introducing the ability to manage specific authentication flows through Conditional Access, starting with device code flow.

Device code flow is commonly used for signing into devices that lack local input devices, such as shared devices or digital signage. However, it is considered a high-risk authentication flow and can be exploited in phishing attacks or to access corporate resources from unmanaged devices. You can configure the device code flow control within your Conditional Access policies alongside other security controls. For instance, if device code flow is necessary for Android-based conference room devices, you might block it universally except for Android devices within a specific network location.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA025-Block Authentication transfer flows for All users

Authentication transfer is a new flow that allows users to seamlessly transfer their authenticated state from one device to another. For example, users can scan a QR code in the desktop version of Outlook with their mobile device to transfer their authenticated session to the mobile device, providing a smooth and intuitive user experience.

The ability to control authentication transfer is currently in preview. You can manage this feature using the Authentication flows condition in Conditional Access.

Note: Starting in early September 2024, Microsoft will enforce authentication flow policies on the Device Registration Service, but only for policies that target all resources in the resource picker. If your organization uses Device Code Flow for device registration and has a policy targeting all resources, you'll need to exempt the Device Registration Service to avoid any disruption.

To exempt the Device Registration Service in the Conditional Access settings, go to Target Resources -> Exclude -> Select excluded cloud apps -> Device Registration Service. If you're using an API, update your policy by excluding the Client ID for the Device Registration Service: 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.

If you're unsure whether your organization uses Device Code Flow with the Device Registration Service, you can check the Microsoft Entra Sign-in logs. Filter by the Device Registration Service client ID in the Resource ID filter, and use the Device Code option within the Authentication Protocol filter to identify any relevant usage.

User Exclusions 

 -Emergency access or break-glass accounts to prevent a tenant-wide lockout.
- Service accounts and service principals, such as the Microsoft Entra Connect Sync Account. These are non-interactive accounts that are not associated with any specific user.

 Note: 1. Calls made by service principals are not blocked by Conditional Access policies scoped to users. To secure service principals, use Conditional Access for workload identities, which requires an Entra Workload Identities License, to define policies targeting these identities.

        2.  Using separate Conditional Access policies, service account access should be allowed only from trusted network locations where the services are genuinely authenticating. This ensures that service accounts are only allowed to connect from secure and verified environments.

CA Policy Deployment and Testing

Phased Deployment: Implement policies gradually to monitor their impact and ensure they work as intended. Utilize the CA policy Report-Only Mode to assess potential effects, using Entra Sign-in logs, which can be forwarded to Log Analytics. The Conditional Access insights and reporting workbook helps you understand the long-term impact of these policies in your organization.

Testing: Conduct comprehensive testing with test users, covering various scenarios such as risky sign-ins and device management. Compare the actual results with your expected outcomes.

Roll Back: If necessary, disable or exclude users from policies. Use exclusions carefully, and aim to re-enable policies as quickly as possible.

To create a Conditional Access policy, sign in to the Microsoft Entra Admin Center, navigate to Protection > Conditional Access, and then select Policies

At the top of the menu, you will find options for New Policy, New Policy Template, and Upload Policy File. You can use any of these methods to create a Conditional Access policy.

If you select New Policy, you will need to configure each setting according to your specific requirements, as highlighted in the screenshot below.

Lets Check each CA Policy options

1. Policy Name: Follow the policy naming standards we discussed at the beginning of the blog.

Example:

2.Users or Workload Identities

Identities in the directory that the policy applies to ,including users ,groups and service principals

Note: Entra Workload identity license is required for configuring CA policy for Workload identities

In the example below, Directory Roles have been selected, but you can also choose to apply the policy to users, groups, and even guest and external users. Similarly, you can make selections in the Exclude tab as well.

The option shown below will become visible if you choose Workload Identities, allowing you to add your Service Principals.

3.Target Resources 

This section is where you can target your Cloud Apps, User Actions, Global Secure Access, and Authentication Context according to your policy requirements.

You can choose All Cloud Apps or select required cloud Apps

Under User Actions, you have options such as Register security information and Register or Join Devices.

Under Global Secure Access, there are three traffic profiles available:

- Microsoft 365 Traffic

- Internet Traffic

- Private Traffic

Under Authentication Context, any authentication context created for specific needs will appear here. In our case, we don't have any created at this time.

4. Network: The Network section is where you typically select your trusted network locations, GPS coordinates, IP ranges, and other relevant Network settings.

Previously, the Network section was part of the policy conditions, but with the recent launch of Global Secure Access, Microsoft has moved this option to be directly visible in the main policy menu.

The configuration of Network IP Ranges was discussed earlier in this blog. For guidance on creating Trusted Network ranges, you can refer to those steps.

5. Conditions: The Conditions section is a crucial part of configuring Conditional Access policies, offering various condition types to tailor policies to specific needs. These conditions include:

I. User Risk: Based on User Risk signal level, policy will be applied.

II. Sign-in Risk: Based on User Sign-in Risk signal level, policy will be applied

III. Insider Risk: Insider risk assesses the user's risky data-related activity in Microsoft Purview Insider Risk Management.

IV. Device Platforms:  To Target policy to different device platforms

V. Client Apps: Control user access to target specific client applications

VI. Filter for Devices: Configure a filter to apply policy to specific devices

VII. Authentication Flows (Preview): Control how your organization uses certain authentication and authorization protocols and grants

6. Grant: This is the policy option where you determine the final outcome—whether to block access or select additional requirements that must be met to allow access.

Here are the Conditional Access Policy Grant options:

- Require multifactor authentication :

User must complete additional security requirements like phone call, text

- Require authentication strength

Users must use specific authentication methods, based on the authentication strength policies applied

- Require device to be marked as compliant

Device must be Intune compliant. If the device is non-compliant, the user will be prompted to bring the device under compliance

- Require Microsoft Entra hybrid joined device

Devices must be Microsoft Entra hybrid joined

- Require approved client app

Device must use approved client applications from Microsoft

  [The approved client app grant is retiring in early March 2026. Organizations must transition all current Conditional Access policies that use only the Require Approved Client App grant control to Require Approved Client App or Application Protection Policy by March 2026. Additionally, for any new Conditional Access policy, only apply the Require application protection policy grant.

After March 2026, Microsoft will stop enforcing require approved client app control, and it will be as if this grant isn't selected. Use the following steps before March 2026 to protect your organization’s data.]

- Require app protection policy 

Device must use policy protected apps from Intune applicable to iOS,Android, Windows Edge in preview(BYOD)

- Require password change

Require password change to lower user risk. This option also requires multifactor authentication or authentication strength controls. Other controls can't be used

- M365 Demo (Terms of use, Admin created)

Organization Custom Terms of Use for user to Accept

Admin can choose Require all the selected Controls or Require on of the selected controls while defining the policy

These options define the conditions that must be met to grant access under the policy.

7.Session: Control access based on session controls to enable limited experiences within specific cloud applications

- Use app enforced restrictions

Require password change to lower user risk. This option also requires multifactor authentication or authentication strength controls. Other controls can't be used

 This control works only with supported apps. Currently, Office 365, Exchange Online, and SharePoint Online are the only cloud apps that support app enforced restrictions.

- Use Conditional Access App Control

To control Cloud Apps using Defender for Cloud Apps

- Sign-in frequency

Time period before a user is asked to sign-in again when attempting to access a resource. The default setting is a rolling window of 90 days, i.e. users will be asked to re-authenticate on the first attempt to access a resource after being inactive on their machine for 90 days or longer.

- Persistent browser session

A persistent browser session allows users to remain signed in after closing and reopening their browser window.

• This setting works correctly when "All cloud apps" are selected.
• This does not affect token lifetimes or the sign-in frequency setting.
• This will override the "Show option to stay signed in" policy in Company Branding.
• "Never persistent" will override any persistent SSO claims passed in from federated authentication services.
• "Never persistent" will prevent SSO on mobile devices across applications and between applications and the user's mobile browser.

- Customize continuous access evaluation

Continuous Access Evaluation (CAE) allows access tokens to be revoked based on critical events and policy evaluation in real time rather than relying on token expiration based on lifetime.

• "Disable" works correctly when "All cloud apps" is selected, and no condition has been chosen.
• This setting does not work with report-only mode, but there are pre-published workbooks with data insights.

- Disable resilience defaults

During an outage, Microsoft Entra ID will extend access to existing sessions while enforcing Conditional Access policies. If a policy cannot be evaluated, access is determined by resilience settings. If resilience defaults are disabled, access is denied once existing sessions expire.

- Require token protection for sign-in sessions (Preview)

A secure sign-in session requires all long-lived tokens (the Microsoft Entra session cookie and refresh token) to be bound to the device using software key binding or hardware security module binding where available.

- Use Global Secure Access security profile

Use this option to apply a policy profile for Global Secure Access targeted resources

These session controls allow you to fine-tune how sessions are managed and secured in your organization.

8.Enable Policy: In the Enable Policy section, you can set the Entra ID Conditional Access Policy to Report-only mode. This allows you to validate the policy's impact by reviewing users' sign-in logs without actually enforcing the policy. If you want to activate the policy, select On. To disable the policy, you can choose Off.

Conditional Access policy templates

Conditional Access templates offer a convenient way to deploy new policies that align with Microsoft's best practices. These templates are designed to deliver maximum protection based on commonly used policies across different customer types and locations. The templates are organized into the following categories:

• Secure foundation
• Zero Trust
• Remote work
• Protect administrator
• Emerging threats

You can find these templates in the Microsoft Entra admin center by navigating to Protection > Conditional Access > Create new policy from templates. Select Show more to view all available templates in each category.

Select the Required Template and choose Review and Create

Create the policy in Report-only mode first, allowing you to validate its impact without enforcement. After reviewing the results, you can then customize the policy according to your specific needs.

You can also create the CA policy by Uploading JSON-formatted Conditional Access policy file as mentioned in the below screenshots.

Select the JSON file, set the Policy State to Off, and then click Review and Create to finalize the policy.

Top 25 Conditional Access Policy Samples

Policy Name	Users or workload identities	Users or workload identities Excluded	Target Resources	Conditions	Access Controls Grant	Session	Enable Policy
CA001 - Require MFA for administrators	Directory roles	Emergency\Break-Glass access accounts	All cloud apps	None	Grant access Require multifactor authentication	None	Report-Only
CA002 - Require phishing-resistant MFA for administrators	Directory roles	Emergency\Break-Glass access accounts	All cloud apps	None	Grant access Require authentication strength Phishing-resistant MFA	None	Report-Only
CA003 - Securing security info registration	All users	All guest and external users Emergency\Break-Glass access accounts	User actions: Register security information	Locations: Configure Yes Include: Any location Exclude: All trusted locations	Grant access Require multifactor authentication	None	Report-Only
CA004 - Block Guest/External Users security info registration outside trusted Networks	All guest and external users	None	User actions: Register security information	Locations: Configure Yes Include: Any location Exclude: All trusted locations	Block access	None	Report-Only
CA005 - Block legacy authentication	All users	Users and groups that require legacy authentication At least one account to prevent lockout	All cloud apps	Client apps: Configure Yes Check: Exchange ActiveSync clients, Other clients	Block access	None	Report-Only
CA006 - Require MFA for guest and external users	All guest and external users	Emergency\Break-Glass access accounts Applications that don't require MFA	All cloud apps	None	Grant access Require multifactor authentication	None	Report-Only
CA007 - Require MFA for all users	All users	Emergency\Break-Glass access accounts Applications that don't require MFA	All cloud apps	Locations: Configure Yes Include: Any location Exclude: All trusted locations (Optional)	Grant access Require multifactor authentication	None	Report-Only
CA008 - Require MFA for Azure management	All users	Emergency\Break-Glass access accounts	Select apps: Windows Azure Service Management API	None	Grant access Require multifactor authentication	None	Report-Only
CA009 - Sign-in risk-based multifactor authentication	All users	Emergency\Break-Glass access accounts	All cloud apps	Sign-in risk: Configure Yes Levels: High and Medium	Grant access Require multifactor authentication	Sign-in frequency: Every time	Report-Only
CA010 - User risk-based password change	All users	Emergency\Break-Glass access accounts	All cloud apps	User risk: Configure Yes Level: High	Grant access Require multifactor authentication Require password change	Sign-in frequency: Every time	Report-Only
CA011 - Block access for users with insider risk	All users	Emergency\Break-Glass access accounts B2B direct connect users Service provider users Other external users	All cloud apps	Insider risk: Configure Yes Level: Elevated	Block access	None	Report-Only
CA012 - Require compliant device	All users	Emergency\Break-Glass access accounts	All cloud apps	None	Require device to be marked as compliant	None	Report-Only
CA013 - Require compliant or Microsoft Entra hybrid joined device for administrators	Directory roles	Emergency\Break-Glass access accounts	All cloud apps	None	Require device to be marked as compliant Require Microsoft Entra hybrid joined device Require one of the selected controls	None	Report-Only
CA014 - Block access for unknown or unsupported device platform	All users	Emergency\Break-Glass access accounts Android, iOS, Windows, and macOS	All cloud apps	Device platforms: Configure Yes Include: Any device Exclude: Android, iOS, Windows, macOS	Block access	None	Report-Only
CA015 - Require approved client apps or app protection policy	All users	Emergency\Break-Glass access accounts At least one account to prevent lockout	All cloud apps	Device platforms: Configure Yes Include: Android, iOS	Grant access Require approved client app Require app protection policy Require one of the selected controls	None	Report-Only
CA016 - Require an app protection policy on Windows devices	All users	Emergency\Break-Glass access accounts	Office 365	Device platforms: Configure Yes Include: Windows Client apps: Configure Yes Select: Browser only	Grant access Require app protection policy Require device to be marked as compliant Require one of the selected controls	None	Report-Only
CA017 - Require reauthentication and disable browser persistence on Unmanaged Device	All users	Emergency\Break-Glass access accounts	All cloud apps	Filter for devices: Configure Yes Rule syntax: device.trustType -ne "ServerAD" -or device.isCompliant -ne True	Sign-in frequency: Periodic reauthentication Persistent browser session: Never persistent	Sign-in frequency: 1 hour	Report-Only
CA018 - Require a compliant device, Microsoft Entra hybrid joined device for all users	All users	Emergency\Break-Glass access accounts Specific applications (if needed)	All cloud apps	None (unless specific apps are excluded)	Grant access Require multifactor authentication Require device to be marked as compliant Require Microsoft Entra hybrid joined device Require one of the selected controls	None	Report-Only
CA019 - Use application (EXO, SPO, OFB) enforced restrictions for unmanaged devices	All users	Emergency\Break-Glass access accounts	Select apps: Office 365	None	Use app enforced restrictions	None	Report-Only
CA020 - Require multifactor authentication for device registration	All users	Emergency\Break-Glass access accounts	User actions: Register or join devices	None	Grant access Require authentication strength Require multifactor authentication	None	Report-Only
CA021 - Block access based on network location	All users	Emergency\Break-Glass access accounts	All cloud apps	Network: Configure Yes Include: Selected networks and locations Select: Blocked location	Block access	None	Report-Only
CA022 - Require an authentication strength for external users	Guest or external users	Emergency\Break-Glass access accounts	Select apps: Selected apps or all apps (as needed)	None	Grant access Require authentication strength Select: Built-in or custom authentication strength	None	Report-Only
CA023 - Require terms of use to be accepted before accessing Microsoft Admin Portals	All users	Emergency\Break-Glass access accounts	Select apps: Microsoft Admin Portals	None	Grant access Require terms of use acceptance	None	Report-Only
CA024 - Block Device Code flows for All users	All users	Emergency\Break-Glass access accounts	All cloud apps or selected apps	Authentication Flows: Configure Yes Device code flow	Block access	None	Report-Only
CA025 - Block Authentication transfer flows for All users	All users	Emergency\Break-Glass access accounts	All cloud apps or selected apps	Authentication Flows: Configure Yes Authentication transfer	Block access	None	Enabled

- Required User/Group/Service Account Exclusions should be added to the template according to the organization's needs.

- Required Network Locations should be included as necessary.

- Required Application Exclusions should be configured.

- Authentication Strengths can be created and customized based on the organization's requirements.

- A minimum of at least 2 Break Glass/Emergency accounts should be excluded from the Conditional Access policy.

- Terms of Use documents should be prepared as per the organization’s standards and updated in the Conditional Access policy.

- The What If tool available on the Conditional Access page can be used to validate the policy's impact before full enforcement.

Conclusion

Implementing Microsoft Entra ID Conditional Access policies requires careful planning and execution. By following best practices, testing policies thoroughly, and having a clear communication strategy, you can effectively balance security and productivity, protecting your organization’s resources while ensuring a smooth user experience.