This conditional access baseline is based on the Microsoft Conditional Access Baseline by Claus Jespersen. This one is slightly minimized and less difficult to understand but still protects almost everything you could wish for. Use this baseline to start off with and expend or modify where needed.
Tip
This baseline is intended to be deployed through CIPP Conditional Access templates and Standards.
Important
Do not forget to add your break the glass/emergency access accounts to the exclusion group. When using this baseline that would be CA-BreakGlassAccounts - Exclude.
- Conditional access Baseline
- Table of Contents
- Resources
- Prerequisites
- Roadmap
- Version history
- Changelog
- Persona's
- Conditional access policies
- CA000-Global-IdentityProtection-AnyApp-AnyPlatform-MFA
- CA001-Global-AttackSurfaceReduction-AnyApp-AnyPlatform-BLOCK-CountryWhitelist
- CA002-Global-IdentityProtection-AnyApp-AnyPlatform-Block-LegacyAuthentication
- CA003-Global-BaseProtection-RegisterOrJoin-AnyPlatform-MFA
- CA004-Global-IdentityProtection-AnyApp-AnyPlatform-AuthenticationFlows
- CA005-Global-DataProtection-Office365-AnyPlatform-Unmanaged-RequireAppProtection
- CA006-Global-DataProtection-Office365-iOSenAndroid-RequireAppProtection
- CA100-Admins-IdentityProtection-AdminPortals-AnyPlatform-MFA
- CA101-Admins-IdentityProtection-AnyApp-AnyPlatform-MFA
- CA102-Admins-IdentityProtection-AllApps-AnyPlatform-SigninFrequency
- CA103-Admins-IdentityProtection-AllApps-AnyPlatform-PersistentBrowser
- CA104-Admins-IdentityProtection-AllApps-AnyPlatform-ContinuousAccessEvaluation
- CA105-Admins-IdentityProtection-AnyApp-AnyPlatform-PhishingResistantMFA
- CA200-Internals-IdentityProtection-AnyApp-AnyPlatform-MFA
- CA202-Internals-IdentityProtection-AllApps-WindowsMacOS-SigninFrequency-UnmanagedDevices
- CA203-Internals-AppProtection-MicrosoftIntuneEnrollment-AnyPlatform-MFA
- CA204-Internals-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms
- CA205-Internals-BaseProtection-AnyApp-Windows-CompliantorAADHJ
- CA206-Internals-IdentityProtection-AllApps-AnyPlatform-PersistentBrowser
- CA207-Internals-AttackSurfaceReduction-SelectedApps-AnyPlatform-BLOCK
- CA208-Internals-BaseProtection-AnyApp-MacOS-Compliant
- CA209-Internals-IdentityProtection-AllApps-AnyPlatform-ContinuousAccessEvaluation
- CA300-ServiceAccounts-IdentityProtection-AnyApp-AnyPlatform-MFA
- CA301-ServiceAccounts-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUntrustedLocations
- CA400-GuestUsers-IdentityProtection-AnyApp-AnyPlatform-MFA
- CA401-GuestUsers-AttackSurfaceReduction-AllApps-AnyPlatform-BlockNonGuestAppAccess
- CA402-GuestUsers-IdentityProtection-AllApps-AnyPlatform-SigninFrequency
- CA403-Guests-IdentityProtection-AllApps-AnyPlatform-PersistentBrowser
- CA404-Guests-AttackSurfaceReduction-SelectedApps-AnyPlatform-BLOCK
- Named locations
- Considerations
- Troubleshooting
- Deploying with CIPP
➡ Microsoft Learn: https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-framework
➡ Framework documentation by Claus Jespersen: https://github.com/microsoft/ConditionalAccessforZeroTrustResources/blob/main/ConditionalAccessGovernanceAndPrinciplesforZeroTrust%20October%202023.pdf
➡ Framework resources: https://github.com/microsoft/ConditionalAccessforZeroTrustResources
➡ idPowerToys for CA documentation: https://idpowertoys.merill.net/
- Security Defaults must be disabled before importing Conditional Access policies.
- Make sure Microsoft Intune Enrollment (App id: d4ebce55-015a-49b5-a083-c84d1797ae8c) app exists in your tenant. Otherwise, create manually by using
New-MgServicePrincipal -AppId d4ebce55-015a-49b5-a083-c84d1797ae8c
- Feedback and enhancement requests can be provided by opening a repository issue.
| Version nr | Release date |
|---|---|
| 2024.4.1 | Released 10-04-2024 |
| 2024.6.1 | Released 26-06-2024 |
| 2025.2.1 | Released 01-02-2025 |
| 2025.2.2 | Released 06-02-2025 |
| 2025.2.3 | Released 13-02-2025 |
| 2026.2.1 | Released 13-02-2026 |
- CA208: Added this policy to require MacOS device compliance
- CA207: Added this policy to explicitly block certain apps on any platform for the internals persona.
- CA404: Added this policy to explicitly block certain apps on any platform for the guest persona.
- CA103: Added this policy to have never persistent browser sessions on any platform for admins persona
- CA206: Added this policy to have never persistent browser sessions on any platform for internals persona
- CA403: Added this policy to have never persistent browser sessions on any platform for admins persona
- CA006: Added this policy to require App Protection for iOS and Android devices when accessing Exchange Online and SharePoint Online.
- CA100: Added a few Admin roles to require MFA.
- CA101: Added a few Admin roles to require MFA.
- CA104: Added Continuous Access Evaluation for admins
- CA105: Added Phishing Resistant MFA for admins
- CA209: Added Continuous Access Evaluation for internals
- CA206: Wrong exclusion group was assigned. Has been fixed.
- Removed risk-based policies from this baseline because they require Microsoft Entra ID P2.
- Risk-based agent policies are not included because they require Microsoft Entra ID P2.
- CA005: Modified policy from Require approved client app to RequireAppProtection as this is being retired per March 2026.
Global is a persona/placeholder for policies that are general in nature or do not only apply to one persona. So it is used to define policies that apply to all personas or don't apply to one specific persona. The reason for having this persona is to be able to have a model where we can protect all relevant scenarios. It should be used to hold policies that apply to all users or policies that enforce protection on scenarios not covered by policies for other personas
We define admins in this context as any non-guest identity (cloud or synced) that have any Azure AD or other Microsoft 365 admin Role (like in MDCA, Exchange, Defender for Endpoints or Compliance). As guests who have such roles are covered in a separate persona, guests are excluded from this persona.
Internals cover all users who have an AD account synced to Azure AD who are employees of the company and work in a standard end-user role.
Guests holds all users who have an Azure AD guest account that has been invited into the customer tenant
This policy requires MFA for all cloud apps, from every platform. It captures all authentications in scope not captured by other MFA policies.
This policy blocks all countries, to all cloud apps, from every platform except for the countries configured in the named location ALLOWED COUNTRIES. This named location is excluded in this policy.
Important
Modify the named location with your approved countries. By default only Belgium, Luxembourgh and Netherlands are allowed to have access from.
This policy blocks legacy authentication for all users, to all cloud apps, from any platform.
This policy requires MFA for all users, to register or join a device to your tenant/environment.
Tip
Make sure to disable Require Multifactor Authentication to register or join devices with Microsoft Entra. This can be found under https://portal.azure.com -> Entra ID -> Devices -> Device settings.
This policy prevents all users from transfering authentication flows from PC to mobile for example. This feature is currently in preview.
This policyrequires App Protection Policies on unmanaged devices.
Note: This policy will be modified or removed soon as there is some overlap with CA005.
This policy requires App Protection policies for all users when accessing Office 365 data from iOS or Android devices. Admin roles are excluded to make sure the Microsoft 365 App's on the iOS and Android devices do work. This one is designed on the principle that admin roles are only assigned to admin accounts!
This policy requires MFA for certain admin roles when they access the access Admin Portals. This one is designed on the principle that admin roles are only assigned to admin accounts!
This policy requires MFA for certain admin roles when they access the any cloud app. This one is designed on the principle that admin roles are only assigned to admin accounts!
This policy sets a Sign-in frequency for certain admin roles to a maximum of 12 hours. Admins need to re-authenticate of logon after 12 hours.
Note
Some organizations assign key roles to their primary identity (which is not ideal), leading to frequent forced sign-ins. It's recommended to assign additional roles based on your personal requirements instead.
This policy prevents having persistent browser sessions for admins from every device.
This policy allows Microsoft Entra ID to re-evaluate a user's access to resources in near real-time, rather than waiting for the typical token expiration time (which could be up to an hour). Read the Microsoft documentation here: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation#conditional-access-policy-evaluation-preview
Important
This CA rule cannot be created in Report-only mode. Supported modes are ON or OFF.
This policy requires Phishing Resistant MFA for admins. It does exclude Microsoft Graph Command Line Tools (cause i needed it) but you are free to remove it from your policy. It's slightly different from the Template policy. We also include Global Reader and Intune Administrators into the admin role selection.
This policy requires MFA for all internal identities, for all cloud applications, from any platform.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy sets a Sign-in frequency to a maximum of 12 hours for internals, to all cloud apps, using unmanaged Windows or MacOS devices.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy requires MFA for internals when enrolling their devices in Intune.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
Important
Autopilot Device Preparation (v2) enrollment can fail under this policy, resulting in devices getting stuck during OOBE. This happens because the automated enrollment process is unable to fulfill the MFA requirement. To avoid this issue, add Autopilot Device Preparation users to the exclusion group for this policy.
This policy blocks unknown/unsupported device platforms for internals.
Note
Currently only Windows, MacOS, Android and iOS are supported. If (for example) Linux or Windows Phone is allowed you need to modify the policy.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy requires internals to make use of a Windows device that is compliant or AADHJ (Azure AD Hybrid Joined / Entra ID Hybrid Joined) while accessing any cloud app.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy prevents having persistent browser sessions for internals from unmanaged devices. Managed and compliant devices are excluded from the policy.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy prevents internals from accessing specific apps. In this example i've blocked a random app. You should review the included and excluded apps. Excluding office 365 is not necessary if its not included. This is just an example.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy requires MacOS devices to be compliant for internals.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
This policy allows Microsoft Entra ID to re-evaluate a user's access to resources in near real-time, rather than waiting for the typical token expiration time (which could be up to an hour). Read the Microsoft documentation here: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation#conditional-access-policy-evaluation-preview.
Important
Verify the included group(s) and/or add your custom groups which have all internals in it. CA-Internals is used as the standard tenant-local target group for internal users.
Important
This CA rule cannot be created in Report-only mode. Supported modes are ON or OFF.
This policy requires ServiceAccounts to use MFA, from any platform when accessing any cloud app.
Important
Verify the included group(s) and/or add your custom groups which have all service accounts in it. CA-ServiceAccounts is used as the standard tenant-local target group for service accounts.
This policy prevents service accounts from logging in from untrusted countries.
Important
Verify the Named Location which is part of this policy. Add or Remove countries from the imported Named Location.
This policy requires guest to use MFA, from any platform when accessing any cloud app.
This policy blocks access for guests to all cloud apps (except for those excluded), from any device.
Important
Make sure to exclude additional cloud apps if any guest needs access to these apps.
Note
If you're not working with an MSP (Microsoft Partner) that requires access to your tenant, you can also block "Service Provider Users."
This policy sets a Sign-in frequency to a maximum of 12 hours for guests, to all cloud apps, using any device.
This policy prevents guest from having persistent browser sessions.
This policy prevents guests from accessing specific apps. In this example i've blocked a random app. You should review the included and excluded apps. Excluding office 365 is not necessary if its not included. This is just an example.
| Name | Location type | Assigned to policy |
|---|---|---|
| ALLOWED COUNTRIES | Countries (IP) | CA001-Global-AttackSurfaceReduction-AnyApp-AnyPlatform-BLOCK-CountryWhitelist |
| ALLOWED COUNTRIES - SERVICE ACCOUNTS | Countries (IP) | CA301-ServiceAccounts-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUntr |
- You might want to remove the "CA - BreakGlassAccounts - Exclude" group from Admin MFA policies (CA101, CA102) if they use MFA and/or only exclude 1 single BreakGlass account.
- If you encounter an error when importing policies CA203/CA205/CA208, it may be due to the absence of the "Microsoft Intune Enrollment" app in your tenant. To resolve this, recreate it using PowerShell with the following commands:
Connect-MgGraph
New-MgServicePrincipal -AppId d4ebce55-015a-49b5-a083-c84d1797ae8c
-
Error: Policy contains invalid applications: ServicePrincipalNotFound. Some ServicePrincipals might be missing in your tenant. You can manually create these by using
New-MgServicePrincipal -AppId *****-*****-******| -
Windows first sign-in restore fails with error You can’t get there from here. This application contains sensitive information and can only be accessed from devices or client applications that meet management compliance policy.. This is blocked by policy CA205 (CA205-Internals-BaseProtection-AnyApp-Windows-CompliantorAADHJ). Add an exclusion for Microsoft Activity Feed Service (d32c68ad-72d2-4acb-a0c7-46bb2cf93873) in this policy.
Use CIPP's CA Templates page to browse/import templates, deploy a template, edit a template, save templates to GitHub, or review template sync logs. Use CA Policies when reviewing a tenant's live policies or when creating a CIPP template from an existing policy.
There are two practical deployment modes:
-
One-off deployment: Deploy a template from Tenant Administration > Conditional Access > CA Templates. The wizard can set deployment state, exclusions, and replacement behavior. For cross-tenant templates, CIPP calls out
Replace IDs with Display Namesas the safe replacement method so tenant-specific object IDs do not break the deployment. -
Standards deployment: Add the CA template to Tenant Administration > Standards & Drift. Standards are for desired-state management: CIPP reapplies the configured standard on a schedule and can overwrite out-of-band admin changes. CIPP's docs describe Standards as reapplying/evaluating every 12 hours in the Standards & Drift page, while the Standards Setup guide currently mentions 3 hours. Treat the exact interval as version-dependent and check the live docs or CIPP logs for your instance. In Standards, CIPP always uses
Replace IDs with Display Names.
Required tenant groups:
Deploy the tenant-local Entra security groups before deploying Conditional Access templates. CIPP can deploy reusable groups from Group Templates and Deploy Group Templates. Do this as a separate prerequisite step so CA policy deployment can resolve the group display names consistently.
In CIPP group templates, Username is the group's mailNickname / alias, not the Entra object ID. Use a stable lowercase alias such as ca-internals, ca-serviceaccounts, or ca-breakglassaccounts-exclude. Conditional Access templates still contain source-tenant object IDs internally, but CIPP deployment translates those references by display name when using Replace IDs with Display Names; Standards always use that replacement mode. The display name is the part that must match exactly.
Minimum group structure per tenant:
CA-Internals: include standard internal users who should receive the Internals CA policies. Use dynamic membership if the tenant has a reliable rule; otherwise keep it assigned and managed by onboarding/offboarding.CA-ServiceAccounts: include only interactive service/shared accounts that cannot yet be replaced with better workload identity patterns. Keep empty if there are none.CA-BreakGlassAccounts - Exclude: include emergency access accounts before turning policies on.- Per-policy
... - Excludegroups: deploy these empty by default. Use them for tenant-specific exceptions instead of editing the CA policy directly.
Recommended order:
- Create/import CIPP group templates for the required group names.
- Deploy the group templates to the target tenants.
- Populate
CA-Internals,CA-ServiceAccounts, andCA-BreakGlassAccounts - Exclude. - Leave per-policy exclude groups empty unless there is a documented exception.
- Deploy CA templates in Report-only and confirm CIPP resolves group names as expected.
Recommended CIPP rollout flow:
- Confirm tenant prerequisites first: Security Defaults off, break-glass account created, emergency exclusions ready, MSP/GDAP access exclusions ready, and the Microsoft Intune Enrollment service principal present if using enrollment/device-compliance policies.
- Deploy the required tenant groups and populate the target/exclusion groups.
- Import or create the CA templates in CIPP.
- Review every template before deployment, especially included users/groups, excluded users/groups, named locations, app targets, authentication strengths, and policy state.
- Deploy to a pilot tenant or pilot user group in Report-only where supported. CIPP's user-level Conditional Access test page can test application, country, IP address, platform, and client-app scenarios and shows whether a policy applies.
- Move low-risk controls on first, such as legacy-auth blocking and MFA, then add higher-friction controls like device compliance, location blocks, and strict session controls.
- After the pilot is clean, either deploy one-off to selected tenants or attach the template to a Standards template for ongoing enforcement.
MSP/GDAP lockout checks:
- Client tenants: these templates include the CIPP variable
%msptenantid%as a Guest or external users > Service Provider Users > Selected exclusion. Before deployment, create a CIPP global variable namedmsptenantidwith your MSP tenant ID. - Direct tenant mode: exclude the CIPP service account in that tenant instead of the MSP tenant exclusion.
- Partner tenant: do not leave the CIPP service account broadly unprotected. CIPP recommends excluding it from other existing CA policies, then protecting it with a dedicated all-cloud-apps MFA policy and sign-in frequency every time.
- CA401 guest blocking: verify MSP/GDAP service-provider access still works before enabling tenant-wide. It is intended to block non-approved guest access, and this is exactly the kind of policy that can create partner-admin surprises if exclusions are wrong.
- Post-deployment proof: test CIPP actions and GDAP/AOBO portal access after each blocking policy moves from Report-only to On. Do this before adding the policy to a recurring Standard.
Important CIPP gotchas:
- Standards are enforcement, not just deployment. If a technician edits a policy directly in Entra, a CIPP Standard can reapply the template later. Deselecting or disabling remediation stops future enforcement but does not undo changes already made.
- Specific Standards win over broad Standards. CIPP precedence is individual tenant over tenant group over All Tenants. When two standards conflict at the same specificity, the newer one wins.
- Named locations travel with templates created from policies. CIPP says templates include policy settings such as named locations and authentication strengths. Still verify country/IP values in Named Locations, especially for CA001 and CA301.
- CIPP exclusions are not optional hygiene. Keep break-glass accounts excluded where appropriate. Add service-provider/MSP exceptions only where they are genuinely needed and understood.
- Continuous Access Evaluation templates are special. CA104 and CA209 cannot be created in Report-only mode according to this repo's policy notes, so do not include them in a first-pass SMB Standard unless you are ready for direct enable/disable testing.
- Companion policies matter. App protection and compliant-device CA policies only work as intended when the matching Intune app protection, enrollment, and compliance policies exist.
- Back up before broad changes. CIPP's Configuration Backup page can schedule or download tenant configuration backups; its restore wizard warns that selected categories are replaced during restore.
- Use CIPP reports after deployment. Policies and Settings Deployed, Applied Standards Report, CA policy logs, and CA template logs are the places to verify what CIPP deployed and what Standards are maintaining.
Current CIPP documentation entry points:
- CIPP documentation index for agents and current page discovery: llms.txt
- Conditional Access overview: Tenant Administration > Conditional Access
- CA policies: CA Policies
- CA templates: CA Templates
- Named locations: Named Locations
- Standards: Standards & Drift
- Standards setup: Standards Setup
- Group templates: Group Templates
- Deploy group templates: Deploy Group Templates
- Conditional Access testing: User Conditional Access test
- CIPP service account and GDAP CA guidance: Conditional Access Configuration
- Configuration backup: Configuration Backup
- Deployed policies report: Policies and Settings Deployed