Conditional Access

Strengthening Your Azure AD Security

Conditional Access is an advanced Microsoft 365 security feature that protects your organisation by controlling who can access your data — and under what conditions. Using intelligent real-time access policies, it verifies user identity, device compliance, location, and risk level before granting access. As part of a modern Zero Trust security strategy, Conditional Access helps prevent unauthorised access, reduce cyber threats, and ensure secure remote work across your cloud environment.

Conditional Access Questions?

What is Conditional Access?

Conditional Access is a powerful security feature within Microsoft 365 and Microsoft Entra ID that enables organisations to control how users access corporate data and applications. Using an intelligent “if-then” policy engine, access decisions are made in real time based on identity signals, device health, location, application sensitivity, and risk level.

By implementing Conditional Access policies, businesses can strengthen their cybersecurity posture, protect against identity-based attacks, and align with a modern Zero Trust security framework. This ensures that access is only granted when the correct security conditions are met — without disrupting legitimate users.

🔹 Key Benefits of Conditional Access

  • Enforce Multi-Factor Authentication (MFA) for privileged or high-risk accounts
  • Block or restrict access from suspicious countries or locations
  • Require compliant devices managed by Microsoft Intune
  • Protect sensitive data in Exchange Online, SharePoint, and Teams
  • Reduce the risk of phishing and credential compromise
  • Enable secure remote work across cloud applications

For organisations using Microsoft 365 Business Premium or Enterprise, Conditional Access is a critical control for modern cloud security and compliance.

Why a Baseline Matters?

  • Without a baseline, you risk inconsistent policies: some users may enjoy over-privileged access, others may be locked out or using weaker controls.

  • The baseline reflects best practices: It’s based on the work of Claus Jespersen and includes policies that target different personas and access scenarios.

  • It supports segmentation: It breaks down access policies by personas (Global, Admins, Internals, Guests) which aligns with the principle of least privilege.

  • It simplifies deployment: The repo also includes scripts and instructions to import policies, assign groups, and get going quickly. Microsoft 365 Conditional Access Deployment

Personas & Policy Structure

  • The baseline organises policies by four key personas:

    • Global: Applies broadly across the organisation, for scenarios not covered by other personas.
    • Admins: Users with administrative privileges in Entra ID, Microsoft 365, Intune, etc.
    • Internals: Synced employee identities (non-guest, standard end-users).
    • Guests: External users invited into the tenant via guest accounts.

By structuring policies this way, you can tailor access risk controls to the level of privilege and identity-type, avoiding one-size-fits-all which often leads to either overly restrictive or overly permissive controls. Microsoft 365 Conditional Access Deployment

Global Policies

Global policies in this Microsoft 365 Conditional Access baseline are foundational access control rules that apply broadly across the entire tenant. They enforce core security requirements such as requiring multi-factor authentication (MFA) for all users and apps, blocking legacy authentication protocols, restricting access from untrusted locations, and enforcing data protection controls like app protection for unmanaged devices. These policies form a base layer of protection across all user personas before more specific policies (e.g., for admins or guests) are applied.

  • 🔐CA000: Global – IdentityProtection – AnyApp – AnyPlatform – MFA
    Requires MFA for all cloud apps and all platforms for all users not already covered by more specific policies.
    Why this matters: It elevates the baseline for all users, ensuring MFA is the default for login into any app.

  • 🌍CA001: Global – AttackSurfaceReduction – AnyApp – AnyPlatform – BLOCK – CountryWhitelist
    Blocks access from all countries except those listed in a named location (by default Belgium, Luxembourg, Netherlands in the sample).
    Why it matters: Geographic access controls reduce risk of login from unexpected geographies (which may indicate compromised credentials).

  • 🚫CA002: Global – IdentityProtection – AnyApp – AnyPlatform – Block Legacy Authentication
    Blocks legacy authentication (which is often less secure) for all users and all cloud apps.
    Why it matters: Legacy authentication is a common attack vector (less MFA support, higher risk). This policy reduces that risk.

  • 🖥️CA003: Global – BaseProtection – RegisterOrJoin – AnyPlatform – MFA
    Requires MFA when users register or join a device to the tenant.
    Why it matters: Device registration/join is a critical operation—ensuring MFA at that moment helps prevent malicious devices being added.

  • 🔄CA004: Global – IdentityProtection – AuthFlows – AnyPlatform – BLOCK
    Blocks users from transferring authentication flows (such as from browsers to native apps) when the target app does not meet security requirements.
    Why it matters: Blocking risky authentication flow transfers prevents token theft or session hijacking, reducing the chances of compromised credentials being reused across insecure or unmanaged apps.
  • 📁CA005: Global – DataProtection – Office365 – UnmanagedDevices – BLOCK_DOWNLOAD
    Prevents users on unmanaged devices (devices not compliant or enrolled in Intune) from downloading files or syncing data from Office 365 apps like SharePoint, OneDrive, or Teams.
    Why it matters: Protects sensitive corporate information from being downloaded to personal or unmanaged devices, maintaining control over data residency and preventing data leakage.
  • 📱CA006: Global – DataProtection – Office365 – iOS/Android – REQUIRE_APP_PROTECTION
    Requires users accessing Office 365 apps from mobile devices (iOS and Android) to use applications protected by Intune App Protection Policies (APP).
    Why it matters: Ensures mobile devices accessing corporate data are secured through app-level encryption, preventing unauthorized sharing or copying of business information outside managed apps. Microsoft 365 Conditional Access Deployment

Admins Policies

Admin Conditional Access policies in Microsoft 365 are advanced security controls designed to protect privileged accounts with elevated permissions. Because administrators can modify security settings, access sensitive data, and manage identities, they are prime targets for cyber attacks.

These policies enforce mandatory Multi-Factor Authentication (MFA), require compliant or managed devices, block legacy authentication, and apply location-based access restrictions. By implementing dedicated admin controls, organisations strengthen their Zero Trust security model, reduce the risk of privilege escalation, and prevent unauthorised configuration changes. Properly configured Microsoft 365 admin security policies significantly enhance overall cybersecurity posture.

  • 🔐CA100 – Admins – IdentityProtection – AdminPortals – AnyPlatform – MFA
    Requires Multi-Factor Authentication (MFA) for administrators accessing Microsoft 365 admin portals, including Entra, Exchange, and Defender. This ensures privileged access to management interfaces is strongly verified and protected against credential theft or unauthorised administrative changes.

  • 🔑CA101 – Admins – IdentityProtection – AnyApp – AnyPlatform – MFA
    Enforces Multi-Factor Authentication (MFA) for administrative accounts across all cloud applications. This strengthens identity protection by ensuring privileged users must verify their identity regardless of which Microsoft 365 service or third-party app they access.

  • ⏱️CA102 – Admins – IdentityProtection – AllApps – AnyPlatform – Sign-in Frequency
    Forces regular re-authentication for administrator accounts, such as every 12 hours, to limit the duration of privileged sessions. This reduces the risk of session hijacking and ensures ongoing identity verification for elevated access.

  • 🚫CA103 – Admins – IdentityProtection – AllApps – AnyPlatform – PersistentBrowser
    Prevents administrators from using persistent browser sessions or “stay signed in” functionality. By blocking long-lived authentication tokens, this policy reduces the risk of compromised devices maintaining privileged access without re-authentication.

  • 🔄CA104 – Admins – IdentityProtection – AllApps – AnyPlatform – ContinuousAccessEvaluation
    Enables Continuous Access Evaluation (CAE) to provide real-time session validation for administrative users. Access can be revoked instantly if risk conditions change, such as password resets, account compromise, or policy updates.

  • 🛡️CA105 – Admins – IdentityProtection – AnyApp – AnyPlatform – PhishingResistantMFA
    Requires administrators to use phishing-resistant Multi-Factor Authentication methods, such as FIDO2 security keys or certificate-based authentication. This significantly reduces the risk of credential theft through phishing attacks or adversary-in-the-middle techniques.

Internal Policies

Internal Conditional Access policies in Microsoft 365 are designed to protect standard organisational users while maintaining productivity and secure access to business applications. These policies typically enforce Multi-Factor Authentication (MFA), require compliant or managed devices, block legacy authentication, and apply risk-based sign-in controls to reduce exposure to cyber threats.

By strengthening everyday user access with structured Microsoft 365 Conditional Access security controls, organisations minimise credential compromise, prevent lateral movement, and support a modern Zero Trust security model. Properly configured internal policies ensure secure, flexible access across office, remote, and hybrid environments.

👥CA200: Internals – IdentityProtection – AnyApp – AnyPlatform – MFA
Requires multi-factor authentication (MFA) for all internal users accessing any Microsoft 365 or cloud app.
Why this matters: Provides an essential security baseline by ensuring all employees use MFA, greatly reducing the risk of account compromise through stolen or weak passwords.


🚫CA201: Internals – IdentityProtection – AnyApp – AnyPlatform – BLOCK – HighRisk
Blocks internal users who are flagged as “high risk” from signing into any cloud application.
Why this matters: Automatically prevents compromised accounts from accessing your environment until their risk status is remediated, minimizing potential breach impact.


⏱️CA202: Internals – IdentityProtection – AllApps – Windows/MacOS – Sign-in Frequency – UnmanagedDevices
Requires internal users on unmanaged Windows or macOS devices to re-authenticate periodically (for example, every 12 hours).
Why this matters: Frequent sign-in validation helps ensure unmanaged or personal devices cannot maintain long-term access without verification, lowering exposure to hijacked sessions.


📲CA203: Internals – AppProtection – MicrosoftIntuneEnrollment – AnyPlatform – MFA
Requires MFA when users enroll their devices into Microsoft Intune or other management platforms.
Why this matters: Protects the enrollment process to ensure only legitimate, authenticated users can add devices to your organisation’s managed fleet.


🚫CA204: Internals – AttackSurfaceReduction – AllApps – AnyPlatform – BLOCK – UnknownPlatforms
Blocks access from unrecognised or unsupported device platforms.
Why this matters: Prevents risky or obsolete systems (for example, Linux, old OS versions, or jailbroken devices) from connecting, reducing the attack surface.


🪟CA205: Internals – BaseProtection – AnyApp – Windows – Compliant or AAD Joined
Allows access to cloud apps only from Windows devices that are compliant or Azure AD joined.
Why this matters: Enforces the use of trusted, managed devices that meet corporate compliance standards, strengthening endpoint security posture.


🌐CA206: Internals – IdentityProtection – AllApps – AnyPlatform – PersistentBrowser
Disables persistent browser sessions for internal users on unmanaged devices.
Why this matters: Stops users from remaining signed in indefinitely on shared or personal devices, reducing risks from unattended or stolen hardware.


🚫CA207: Internals – AttackSurfaceReduction – SelectedApps – AnyPlatform – BLOCK
Blocks access to selected high-risk or legacy applications for internal users.
Why this matters: Restricts use of applications known to present security or compliance risks, helping prevent accidental data leakage or shadow IT usage.


🍎CA208: Internals – DeviceCompliance – macOS – RequireCompliantDevice
Ensures macOS devices used by internal users meet Intune compliance policies before accessing cloud applications.
Why this matters: Applies the same compliance rigor to Apple macOS endpoints as Windows, maintaining consistency across your organisation’s device ecosystem.


🔄CA209: Internals – IdentityProtection – AllApps – AnyPlatform – ContinuousAccessEvaluation (CAE)
Enables Continuous Access Evaluation for internal users to re-evaluate session access in real time.
Why this matters: Provides instant reaction to risky events such as password changes, account disablement, or location anomalies—significantly enhancing your zero-trust posture.

Guest Users Policies

Guest Conditional Access policies in Microsoft 365 are designed to securely manage external users such as partners, contractors, and third-party collaborators. These policies enforce Multi-Factor Authentication (MFA), apply session controls, restrict access to approved applications, and block high-risk sign-ins to protect sensitive business data.

By implementing structured Microsoft 365 guest access security controls, organisations reduce the risk of data leakage, unauthorised exposure, and compromised external accounts. Strong Conditional Access policies for guest users enable secure collaboration while maintaining compliance and supporting a modern Zero Trust security model.

Guest Users Policies

👤CA400: Guests – IdentityProtection – AnyApp – AnyPlatform – MFA
Requires multi-factor authentication (MFA) for all guest users accessing any cloud application.
Why this matters: Extends MFA protection beyond your internal workforce, ensuring that external collaborators, contractors, or partners verify their identity before accessing your organisation’s resources.


🚫CA401: Guests – BaseProtection – AllApps – AnyPlatform – BLOCK – Default
Blocks guest users from accessing all cloud apps unless those apps are explicitly excluded or permitted by policy.
Why this matters: Reduces the exposure of your tenant by ensuring guests can only access resources that have been deliberately shared with them, preventing accidental overexposure of sensitive data.


⏱️CA402: Guests – IdentityProtection – AllApps – AnyPlatform – Sign-in Frequency
Enforces a maximum sign-in session length for guest users (for example, 12 hours), requiring periodic re-authentication.
Why this matters: Limits the duration of access for external accounts, helping to mitigate risks from session hijacking or shared credentials over time.


🌐CA403: Guests – IdentityProtection – AllApps – AnyPlatform – PersistentBrowser
Blocks persistent (remembered) browser sessions for guest users.
Why this matters: Prevents long-term sessions on devices not managed by your organisation, ensuring external users must authenticate again when returning—an important safeguard against unauthorized reuse.


🛑CA404: Guests – AttackSurfaceReduction – SelectedApps – AnyPlatform – BLOCK
Blocks guest access to specific high-risk or internal-only applications.
Why this matters: Protects confidential or business-critical systems by ensuring that external users cannot access apps or services intended solely for internal employees, supporting least-privilege and zero-trust principles.

How to Use the Baseline in Your Environment

Here are practical steps and tips:

  1. Review the baseline: Understand which policies apply to which personas and how they align with your organisation’s groups, roles and device landscape.

  2. Map your groups/personas: Align your internal user groups (admins, internals, guests) with the baseline personas. You may need to define or refine groups like “All Admins”, “BreakGlassAccounts”, “Internals”, etc.

    • Note: The baseline emphasises the need to exclude “break-glass/emergency access accounts” from some policies (so you don’t lock yourself out).

  3. Adjust the Named Locations: For example the policy CA001 uses a named location “ALLOWED COUNTRIES” to allow only certain geographies. You’ll need to modify the countries to reflect your approved list.

  4. Import the policies: The repo provides PowerShell/Intune scripts (using MSAL, Microsoft Graph, Azure Management APIs) to export/import policies and assignments.

  5. Start in Report-Only mode: Before enabling policies live, use report‐only mode to assess impact (especially for legacy authentication blocks, device compliance, etc). The baseline notes caution: “Be careful activating the policies! … Enable the policies one by one or start with report-only.”

  6. Enable gradually: Roll in the policies in phases rather than all at once, to monitor user impact, exception handling, support tickets.

  7. Monitor and iterate: After enabling, monitor sign-in logs, conditional access insights, risk detections. Adjust exclusions, group scopes, app inclusions/exclusions as needed.

  8. Keep current: The baseline has a version history and changelog (e.g., February 2025 updates added CA210 and fixed grouping). You should likewise keep your policy set up to date with evolving threats and MS­-platform capabilities.

Key Considerations & Pitfalls

  • Break-glass access: Make sure you have an emergency account excluded from strict policies, so you don’t accidentally lock out admin access.

  • Legacy authentication blocks: Be aware of any legacy apps your organisation uses that may break if legacy auth is blocked. Plan for migration.

  • Friendly names vs. actual assignments: The baseline uses example groups (e.g., APP_Microsoft365_E5). Ensure your groups actually represent the intended personas.

  • Device compliance and platform coverage: For device-based policies (e.g., macOS compliance, unmanaged device controls), your organisation needs to have device management in place (e.g., via Microsoft Intune).

  • Named locations and geography: Using country-based blocks helps reduce exposure but must be managed carefully (traveling users, VPNs, cloud-providers).

  • Persistent sessions and CAE: Enabling things like persistent browser session restrictions and CAE (continuous access evaluation) adds security but may change user experience—communication is key.

  • Guest/external user access: Guest accounts are often overlooked yet provide access into your tenant. The baseline gives them specific policies.

  • Customisation is required: This is a solid baseline but not a turnkey one-size. You’ll still need to tailor it to your identity, apps, device estate, risk appetite and regulatory/compliance requirements.

Final Thoughts

Final Thoughts

Implementing a strong conditional access strategy is a cornerstone of zero-trust. The ConditionalAccessBaseline repository offers a pragmatic, structured policy set that you can use to jump-start your controls. By mapping your personas, aligning to the policies, importing carefully, and monitoring impact, you’ll reduce the risk of credential compromise, lateral movement, and unauthorized access.

While no policy set will eliminate all risk, having this baseline means you’re no longer starting from scratch — you’re building on a foundation that aligns with industry guidance and common threat scenarios.

If you’re ready to move your identity access controls from “we should do more” to “we are doing this”, then using this kind of baseline (and adapting it to your organisation) is a strong step forward Microsoft 365 Conditional Access Deployment.

Conditional Access

For Microsoft 365

Conditional Access in Microsoft 365 is a critical security feature that enables organizations to control access to resources based on specific conditions. It evaluates various factors such as user identity, location, device compliance, application being accessed, and risk level before granting access. By applying Conditional Access policies, organizations can enforce multi-factor authentication (MFA), block access from untrusted locations, restrict access to compliant devices, and tailor access requirements to different user roles. This helps protect against unauthorized access, reduces the risk of data breaches, and ensures that only the right users have the right level of access to corporate resources. Conditional Access for Microsoft 365.

Recommended Policy’s

Cyber Security Questions?