Intune & Conditional Access: Enterprise Baseline Policies Every Admin Must Deploy

Conditional Access is the single most powerful — and most dangerous — feature in the Microsoft security stack.

Done right, it enforces Zero Trust across every user, every device, and every application in your organisation. Done wrong, it locks out your entire workforce at 8am on a Monday morning, including the IT team trying to fix it.

I have seen both outcomes. This guide is built to make sure you only ever experience the first one.

We will cover the exact CA baseline every enterprise should have, how to safely test and deploy each policy, what to do before you touch anything, and the critical gotchas that catch even experienced admins off guard.

---

What is Conditional Access and Why Does It Matter?

Conditional Access (CA) is Microsoft Entra ID's policy engine that sits between a user's sign-in attempt and the resource they want to access. Before access is granted, CA evaluates a set of conditions — who is signing in, from what device, from where, with what risk level — and then enforces a grant or block decision.

Think of it as a security checkpoint at the door to every cloud application. The guard checks your identity card (Entra ID), inspects your vehicle (device compliance via Intune), checks you're not on a watchlist (Identity Protection), and only then lets you through.

How CA Fits Into the Zero Trust Model

---

Before You Create a Single Policy — Do These First

These steps are not optional. Skip them and you risk a lockout that no CA policy can fix.

1. Create Break Glass Accounts

A break glass account (also called an emergency access account) is a cloud-only global admin account that is permanently excluded from all CA policies. It exists for one purpose: to recover your tenant if a CA misconfiguration locks out all normal admins.

2. Audit Your Existing Sign-In Landscape

Before creating any CA policies, spend time understanding your current environment:

3. Enable Report-Only Mode — Never Skip This

Every CA policy supports Report-Only mode. In this mode, the policy evaluates sign-ins and logs what it would have done — but takes no action. This is how you safely test any policy before it goes live.

The workflow for every policy you create:

---

The Enterprise CA Baseline — 10 Policies Every Organisation Needs

These policies are organised in three tiers by urgency. Tier 1 should be deployed (in Report-Only first) in your first week. Tier 2 within 30 days. Tier 3 when you have Entra ID P2.

---

Tier 1 — Critical Policies (Deploy Week 1)

CA001 — Require MFA for All Users

Purpose: Every user must verify with MFA for every cloud application sign-in. This single policy stops the majority of credential-based attacks.

---

CA002 — Block Legacy Authentication

Purpose: Legacy authentication protocols (Basic Auth, SMTP AUTH, POP3, IMAP) bypass MFA entirely. An attacker with a password can use these protocols to access email without ever seeing an MFA prompt. This policy shuts that door completely.

---

CA003 — Require MFA for All Admin Roles

Purpose: Admin accounts are the highest-value targets for attackers. This policy adds an additional MFA requirement specifically for accounts holding any directory role — even if CA001 already requires MFA, having a dedicated admin policy gives you more control and better audit visibility.

---

CA004 — Require MFA for Azure Management

Purpose: The Azure portal, PowerShell (Az module), CLI, and REST API give access to your entire Azure infrastructure. A compromised account without this policy could destroy resources, exfiltrate data, or create backdoor accounts in your tenant — all without triggering an MFA prompt if they are already signed in.

---

Tier 2 — Important Policies (Deploy Within 30 Days)

CA005 — Require Compliant Device for Corporate Apps

Purpose: Ensures that only devices enrolled in Intune and passing all compliance policies can access corporate data. A signed-in account on an unmanaged personal device — or a compromised device — cannot reach Exchange, SharePoint, or Teams.

---

CA006 — Block Access for Unknown Locations (Optional)

Purpose: If your organisation's work is location-constrained (e.g., a UK-only company that never has users in South-East Asia), blocking sign-ins from unexpected geographies adds a powerful layer of protection against credential-stuffing attacks from distant threat actors.

---

CA007 — Require Phishing-Resistant MFA for Admin Portals

Purpose: The Microsoft Entra admin centre, Intune admin centre, Microsoft 365 admin centre, and Azure portal are extremely high-value targets. This policy forces phishing-resistant MFA (FIDO2 key or Windows Hello) specifically for these portals — making MFA fatigue and phishing attacks ineffective.

---

CA008 — Require Password Change on Medium+ User Risk

Purpose: Protects accounts whose credentials may have been leaked (password spray, phishing, credential dumps). When Identity Protection detects medium or high user risk, this policy forces the user to change their password before continuing — stopping attackers who already have valid credentials from maintaining access.

---

Tier 3 — Advanced Policies (Requires Entra ID P2)

CA009 — Block High-Risk Sign-Ins

Purpose: Identity Protection assigns a risk score to every sign-in based on signals like impossible travel, anonymous IP, malware-linked IP, atypical travel patterns, and leaked credentials. This policy blocks sign-ins scored as High risk in real-time — before the session is established.

CA010 — Block High-Risk Users

Purpose: Blocks sign-ins for user accounts that Identity Protection has assessed as High risk — typically due to confirmed credential compromise, suspicious activity patterns, or admin-flagged accounts.

---

Full Baseline Policy Summary

---

Testing Protocol Before Every Policy Goes Live

Use this checklist before switching any CA policy from Report-Only to On.

---

Critical Gotchas That Catch Even Experienced Admins

Gotcha 1 — "All Users" Includes Guests

When you target "All users" in a CA policy, that includes B2B guest users in your tenant. A policy requiring a compliant Intune device will block all guests, since guest devices are not enrolled in your Intune. Always add a guest user exclusion to CA005 and any device-compliance policy.

Gotcha 2 — Service Accounts Cannot Do MFA

Automated scripts, Power Automate connections, third-party sync tools, and scheduled tasks that authenticate as a user account cannot respond to an MFA prompt — they will silently fail or throw an error. Before CA001 goes live, audit all service accounts and either:

• Migrate them to Workload Identities (service principals / managed identities) — these have their own CA policies and do not require MFA
• Add them to a service account exclusion group — document every exclusion with a justification

Gotcha 3 — Conditional Access Policies Apply at Sign-In, Not at Session Level

Once a user has an active session (authentication token), changing a CA policy does not immediately kick them out. The policy is re-evaluated at the next sign-in or token refresh. For most apps this is every 1 hour; for some it can be up to 24 hours. If you need immediate enforcement (e.g., blocking a compromised account), use the Revoke Sessions button in Entra ID alongside enabling the CA policy.

Gotcha 4 — The "Block" Grant Overrides Everything

If any CA policy evaluates to "Block" for a user's sign-in, that user is blocked — even if three other policies would grant access. A single misconfigured block policy can lock out an entire group. Always test block policies in Report-Only with extra care.

Gotcha 5 — CA Does Not Apply to On-Premises Resources

Conditional Access only controls access to Entra ID-integrated (cloud) applications. It does not apply to on-premises Active Directory authentication, on-premises applications that use Kerberos/NTLM, or SMB file shares. For on-premises protection, you need additional controls (Network Policy Server, AD FS claims rules, or Microsoft Entra Application Proxy).

Gotcha 6 — Named Locations Must Be Maintained

If you use Named Locations in any policy, you must keep them up to date. New office, new VPN exit node, ISP change — any of these can cause legitimate users to suddenly appear as "outside trusted locations" and get blocked. Assign ownership of Named Locations to a specific admin and review them quarterly.

---

How Intune and CA Work Together

CA and Intune are most powerful when combined. CA005 (Require Compliant Device) is only useful if Intune has meaningful compliance policies. Here is how the combined enforcement works:

Minimum Intune compliance policy for CA005 to be meaningful:

---

Why CA Is So Critical for Enterprise Environments

Organisations that do not have CA deployed are operating with a fundamental security gap that no other control can fully compensate for. Here is why:

Passwords alone are not enough. According to Microsoft's threat intelligence, over 99% of compromised accounts do not have MFA enabled. A username and password is routinely for sale on dark web markets for under £5. CA001 closes this gap by making stolen credentials alone worthless.

Perimeter-based security is dead. In a cloud-first environment, there is no network perimeter. Users sign in from home, coffee shops, hotels, and airports. The only meaningful perimeter is the identity layer — and CA is how you enforce it.

Regulatory and compliance requirements. ISO 27001, Cyber Essentials Plus, SOC 2, and most cyber insurance policies now explicitly require MFA and access controls equivalent to what CA provides. Failing to deploy CA baseline policies is increasingly a compliance failure, not just a security gap.

The blast radius of a breach is enormous. A single compromised Global Admin account without CA protection gives an attacker full control of your Microsoft 365 tenant — the ability to read every email, access every SharePoint document, exfiltrate every Teams message, reset every user's password, and cover their tracks by deleting audit logs. CA003 and CA007 are specifically designed to protect these accounts.

---

Recommended Deployment Timeline

---

Summary

Conditional Access is not a set-and-forget feature. It is a living security control that needs regular review as your environment evolves. New applications, new user types, office moves, and new threat patterns all require policy adjustments.

The baseline I have described — 10 policies across three tiers — represents the minimum for a well-secured enterprise Microsoft 365 environment. It is not the most restrictive possible configuration, but it is the right balance of security and usability.

The three rules that will keep you safe:

1. Always create break glass accounts before creating any CA policy
2. Always use Report-Only mode and review logs before enabling any policy
3. Never enable CA005 (device compliance) before your devices are actually compliant

Follow these, and CA will protect your organisation. Ignore them, and CA will protect your organisation from itself — by locking everyone out.

---

Deploying Conditional Access in your organisation? Drop a comment below with your environment details — happy to help you work through the right policy design for your specific situation.