This repository contains a comprehensive set of Microsoft Entra ID (Azure AD) Conditional Access policies designed to secure organizational access to cloud applications and resources.

PDF contains visual representation created by Conditional Access Documenter created by @Merril - https://idpowertoys.merill.net/ca

• Overview
• Policy Categories
• Policy Naming Convention
• Policy Inventory
  • Device Compliance Policies (CAD)
  • Location-Based Policies (CAL)
  • Protocol and Authentication Policies (CAP)
  • User and Risk-Based Policies (CAU)
• Policy Structure
• Deployment Guidelines

These Conditional Access policies provide a layered security approach to protect organizational resources by enforcing access controls based on:

• Device platform and compliance status
• Geographic location and trusted networks
• Authentication protocols (prerequisite controls)
• User identity and risk levels
• Client application types
• Multi-factor authentication requirements

All policies are exported in JSON format compatible with Microsoft Graph API for easy deployment and version control.

These policies have been exported using the IntuneManagement tool by Micke-K, which can be found here:
https://github.com/Micke-K/IntuneManagement/

This PowerShell-based tool provides a comprehensive interface for managing and exporting Microsoft Intune and Entra ID configurations, including Conditional Access policies. The same tool can also be used to import these policies into your environment.

The policies are organized into four main categories:

Policy names follow a structured format for easy identification:

[PREFIX][NUMBER]-[SCOPE] [ACTION] [DESCRIPTION]-v[VERSION]

Components:

• PREFIX: Policy category (CAD, CAL, CAP, CAU)
• NUMBER: Sequential identifier (001-999)
• SCOPE: Target applications (O365, All, Selected, etc.)
• ACTION: Grant, Block, Session, or Require
• DESCRIPTION: Clear description of policy intent
• VERSION: Semantic version (v1.0, v1.1, etc.)

Examples:

• CAD001-O365 Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1
• CAU008-All Grant Require Phishing Resistant MFA for Admins when Browser and Modern Auth Clients-v1.4

These policies enforce device compliance and platform-specific access controls.

These policies control access based on geographic location and trusted networks.

These are foundational policies that manage authentication protocols and methods. They should be deployed first as prerequisites for other policies.

These policies focus on user identity, MFA requirements, and risk-based access controls.

Devices must be managed with Microsoft Intune and Compliance Policies should be assigned.

Devices must be managed with Microsoft Intune and Compliance Policies should be assigned.

Either iOS or Android device must be managed using Microsoft Intune, with a compliance policy assigned, or the device is not managed (BYOD) and the app must be protected using an Intune App Protection Policy. See the following article for more info: https://www.vansurksum.com/2025/02/11/mam-vs-mdm-choosing-the-right-mobile-management-approach/

Requires MFA to access Office 365 when working on a browser on a non-compliant device. Note that we only allow browser access on non-compliant devices, which could be either managed or unmanaged.

Block all the platforms which are not covered by a Conditional Access policy.

This prevents downloads from Office 365 on non-compliant devices. Users cannot download attachments, and cannot print attachments. In order for this to work you need to configure the mailbox policy, and SharePoint global settings. For SharePoint you can also define Purview Sensitivity Labels to provide more granular settings. See: https://www.vansurksum.com/2020/06/26/limit-access-to-outlook-web-access-and-sharepoint-online-and-onedrive-using-conditional-access-app-enforced-restrictions/ and https://www.vansurksum.com/2020/12/04/defining-more-granularity-for-your-conditional-access-app-enforced-restrictions-using-sensitivity-labels/

Sets the sign-in frequency to 7 days for non-compliant devices when using Modern Authentication Clients, which is basically for Apps installed on iOS and Android.

This sets the sign-in frequency of 1 day for the browser on non-compliant devices.

This makes sure that when the browser is properly closed, the session cookies are removed as well.

Requires MFA when a device is either joined, or registered in Entra ID.

Even though there are no Modern Authentication Clients for Linux, this policy is there for consistency with macOS, iOS/iPadOS, Android and Windows policies.

This optional policy is there if you only want admins to be able to access the environment coming from a compliant device. Keep in mind that in the browser the admin account must be signed-in for CA to recognize the compliance status of the device.

Use this policy if you want to allow (some) users only access from a compliant device.

Use this policy to enforce MAM for Windows (which is basically to force users to sign-in to the Edge Web browser). You can create an App Protection Policy to protect what can be done with the data in the browser session. You can also use the Edge Cloud Policy service to configure the security in that browser session on unmanaged devices.

Only allow access when coming from a compliant Windows or macOS device.

Make sure that defined resources can only be accessed from a compliant device or app protected using an app protection policy on iOS and Android.

Only allow access to Cloud PC from iOS or Android device.

When registering device in Microsoft Intune, make sure that MFA is asked every time.

Define the countries as locations you want to block so that users cannot work from these countries. There are many caveats with this policy since nowadays the internet breakout location can be very different from where the user actually is (VPN/eSIM etc.).

Only allow MFA to be registered from trusted locations. This is an optional policy.

This policy is to make sure that non-personal accounts (service accounts) can only sign in from certain locations. In order for this to work, we also should exclude these accounts from the following policies: CAD002, CAD005, CAU002, CAU008, CAU009, CAU011, CAD012, CAL004, CAU011.

Optional policy, to use if you want admins only to be able to access the environment from specified locations.

Define your less trusted countries as a location, so that when applicable users can only work on compliant devices while in that country.

Restricts specific accounts to designated locations only.

Make sure that legacy authentication is fully blocked. Legacy authentication is capable of bypassing Conditional Access.

Make sure that Exchange ActiveSync is blocked.

Block device code authentication. When temporarily needed (for example to register Teams Rooms devices) add user doing the registration to the exclude group.

Block authentication transfer. When needed add user to exclude group.

Require MFA for guest users for All Resources except for the Microsoft Rights Management resource. See blog from Tony Redmond: https://office365itpros.com/2024/02/12/conditional-access-mfa-email/

Because we exclude one app in CAU001, we must protect Azure Active Directory resource per recommendation from Microsoft. See: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#conditional-access-behavior-when-an-all-resources-policy-has-an-app-exclusion

Require MFA for all users for all resources, guests excluded. In the past there used to be exclusions here for accessing the Windows Store so that devices could receive licenses, but this issue has been fixed by Microsoft.

In this policy you can define the apps which you don't want guest users to access. You can also do it the other way around, then you need to configure CAU019. Please read the following blog post for more information: https://www.vansurksum.com/2025/10/12/configuring-conditional-access-for-guest-users-allowing-only-office-365-and-essential-apps/

Make sure that selected apps are sent to Microsoft Defender for Cloud Apps, so that we can configure policies for them.

Configure apps which must be monitored by Microsoft Defender for Cloud Apps on compliant devices.

When medium or high risk is detected, this is a direct copy of the default identity protection policy. High risk sign-ins must be blocked nowadays so also configure CAU015.

When medium or high risk is detected, this is a direct copy of the default identity protection policy. High risk users must be blocked nowadays so also configure CAU016. This policy excludes guest users (per recommendation from Microsoft) since user risk is coming from their tenant and we cannot dismiss that.

Today, this is a must have policy. Make sure that Administrators have phishing resistant MFA configured before enabling though. Roll out new Administrators using TAP.

Requires MFA for management portal access.

Has exclusions for Intune Enrollment (since not supported).

Be very careful with this policy. Make sure that you first identify all your legit users/personas and exclude them first before enabling this policy.

This should be the default method for users to register phishing resistant MFA, like FIDO2 or passkeys in the Authenticator app.

This policy should eventually replace CAU002, once all your users have phishing resistant MFA configured.

Make sure that you have at least one Workload Identity license in your tenant to properly import this policy. Blocks access when risk is medium or high. You should include all your service principals having risky rights in the environment.

Indeed, with the current phishing using AiTM (Adversary-in-the-Middle) this is becoming a must have.

Same remark as CAU015 - with current phishing using AiTM this is becoming a must have.

Make sure that Admin browser sessions have a sign-in frequency. Configure the sign-in frequency in harmony with things like PIM etc.

Make sure that browser sessions are non-persistent.

This policy could replace the CAU003 policy, only allowing access to Office 365 and other services needed for guest users. See also: https://www.vansurksum.com/2025/10/12/configuring-conditional-access-for-guest-users-allowing-only-office-365-and-essential-apps/

Each policy JSON file contains the following key components:

• displayName: Human-readable policy name
• state: Policy status (enabled/disabled/enabledForReportingButNotEnforced)
• createdDateTime: Policy creation timestamp
• modifiedDateTime: Last modification timestamp

Defines when the policy applies:

• users: Target users, groups, roles, and external users
• applications: Target cloud apps and user actions
• clientAppTypes: Browser, mobile apps, desktop clients, etc.
• platforms: Device platforms (Windows, macOS, iOS, Android, Linux)
• locations: Named locations and IP ranges
• devices: Device filter rules and compliance requirements
• signInRiskLevels: Low, medium, high risk levels
• userRiskLevels: User risk assessment levels

Defines what happens when conditions are met:

• mfa: Require multi-factor authentication
• compliantDevice: Require device compliance
• domainJoinedDevice: Require hybrid Azure AD joined device
• approvedApplication: Require approved client app
• appProtectionPolicy: Require app protection policy
• passwordChange: Require password change
• authenticationStrength: Custom authentication strength policies

• applicationEnforcedRestrictions: Enforce app-based restrictions
• cloudAppSecurity: Use Conditional Access App Control
• signInFrequency: Control sign-in frequency
• persistentBrowser: Control browser session persistence

1. Microsoft Entra ID P1 or P2 license
2. Global Administrator or Conditional Access Administrator role
3. Microsoft Graph API access (for automated deployment)

The easiest method is to use the same IntuneManagement tool that was used to export these policies:

1. Download and launch the IntuneManagement tool
2. Connect to your tenant
3. Navigate to Conditional Access > Import
4. Select the JSON files to import
5. Review settings and configure exclusions
6. Import the policies

This method provides a user-friendly interface and handles policy dependencies automatically.

1. Navigate to Azure AD > Security > Conditional Access
2. Click New policy > Create policy from JSON
3. Upload the JSON file
4. Review settings and exclusions
5. Set to Report-only mode initially
6. Monitor impact before enabling

# Import policy using Microsoft Graph
$policyJson = Get-Content -Path "CAD001-O365 Grant macOS access for All users when Modern Auth Clients and Compliant-v1.1.json" | ConvertFrom-Json
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Body ($policyJson | ConvertTo-Json -Depth 10)

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# Import all policies
$policies = Get-ChildItem -Path ".\ConditionalAccess" -Filter "*.json"
foreach ($policy in $policies) {
    $json = Get-Content -Path $policy.FullName -Raw | ConvertFrom-Json
    New-MgIdentityConditionalAccessPolicy -BodyParameter $json
}

1. Test in Report-Only Mode

   • Deploy policies in report-only mode first
   • Monitor sign-in logs for 7-14 days
   • Identify potential user impact

2. Configure Exclusions

   • Create break-glass admin accounts
   • Exclude emergency access accounts from all policies
   • Document all exclusion groups

3. Phased Rollout

   • Start with pilot groups
   • Gradually expand to broader user base
   • Monitor helpdesk tickets and user feedback

4. Regular Review

   • Review policies quarterly
   • Update exclusion groups as needed
   • Adjust based on security incidents

5. Documentation

   • Maintain change log for policy modifications
   • Document business justification for each policy
   • Keep exclusion group membership documented

• Group IDs: Update excluded group GUIDs before deployment to match your environment
• Named Locations: Configure named locations before deploying location-based policies
• Authentication Strengths: Create custom authentication strength policies if referenced
• App Protection Policies: Ensure Intune app protection policies are configured
• Compliance Policies: Configure device compliance policies before deploying device-based CA

• Policy versions follow semantic versioning (MAJOR.MINOR)
• Version increments indicate policy changes
• Review change history in commit logs

Monitor policy effectiveness using:

• Azure AD Sign-in Logs: Review applied policies and results
• Conditional Access Insights: Built-in reporting
• Azure Monitor: Advanced analytics and alerting
• Microsoft Sentinel: Security information and event management

Common issues and solutions:

• Users locked out: Check exclusion groups and break-glass accounts
• Policy not applying: Verify user/group scope and conditions
• MFA not triggered: Review authentication strength settings
• Compliant devices blocked: Check device compliance status in Intune

When modifying or adding policies:

1. Update the version number in the policy name
2. Document changes in commit messages
3. Update this README with new policies
4. Test thoroughly in non-production environment

These policies are provided as-is for reference and adaptation to your organizational needs. Review and modify according to your security requirements.

• Microsoft Conditional Access Documentation
• Conditional Access Best Practices
• Microsoft Graph API Reference
• Zero Trust Security Model

Last Updated: October 2025
Total Policies: 48
Policy Categories: 4 (CAD, CAL, CAP, CAU)