Conditional Access in Entra ID: Building a Zero Trust Foundation

Table of Contents

Zero Trust & Conditional Access
Anatomy of a Conditional Access Policy
The 5 Baseline Policies Every Tenant Needs
Named Locations & Country Blocking
Requiring Device Compliance
Testing with the What If Tool
Rollout Order & Break-Glass Accounts

Zero Trust & Conditional Access

The classic perimeter model — trust everything inside the network — is dead. With remote work, BYOD, and SaaS applications, the network boundary no longer exists. Zero Trust replaces it with a simple principle: never trust, always verify.

In Microsoft's implementation, Conditional Access (CA) is the policy engine that enforces Zero Trust at the authentication layer. Every sign-in request — whether from a managed laptop in the office or a personal phone in a coffee shop — is evaluated against your CA policies before access is granted or denied. CA sits between the user's authentication and the target resource, evaluating signals like:

Who is the user? (identity, role, risk level)
What device are they on? (managed, compliant, hybrid-joined)
Where are they signing in from? (country, IP, named location)
What application are they accessing? (Exchange, SharePoint, custom app)
What is the sign-in risk score? (Entra ID Protection)

Conditional Access requires Azure AD Premium P1 at minimum. Risk-based policies (sign-in risk, user risk) require P2 (included in M365 E5 or EMS E5). Before enabling CA, confirm licences are assigned to all users in scope.

Anatomy of a Conditional Access Policy

Every CA policy is built from the same three blocks: Assignments (who and what), Conditions (context signals), and Access Controls (the decision).

Block	Options	Notes
Users/Groups	All users, specific groups, directory roles	Always exclude your break-glass account
Target Resources	All cloud apps, specific apps, user actions	Use "All cloud apps" for MFA baseline
Conditions: Device Platform	Windows, iOS, Android, macOS	Useful to create platform-specific policies
Conditions: Locations	Named locations, trusted IPs, countries	Build an allow-list or block-list
Conditions: Sign-in risk	High, Medium, Low, None	Requires Entra ID P2
Grant: Require MFA	Yes/No	Most common control
Grant: Require compliant device	Yes/No	Requires Intune enrollment
Session: Sign-in frequency	Hours/Days, Every time	Use "Every time" for high-sensitivity apps

The 5 Baseline Policies Every Tenant Needs

Start with these five policies in Report-only mode first, then enable them progressively after reviewing the sign-in logs.

Policy 1 — Require MFA for All Users

The most impactful single policy. Blocks the vast majority of identity-based attacks.

Users: All users (exclude break-glass group)
Target resources: All cloud apps
Grant: Require multifactor authentication

Policy 2 — Require MFA for Administrators

Admin accounts are the highest-value targets. Enforce MFA for all directory roles regardless of location or device.

Users: Directory roles → select all admin roles
Target resources: All cloud apps
Grant: Require MFA + require compliant device

Policy 3 — Block Legacy Authentication

Legacy protocols (SMTP, IMAP, POP3, basic auth) cannot complete MFA challenges. They must be blocked at the CA layer.

Users: All users
Conditions → Client apps: Exchange ActiveSync clients + Other clients (tick both)
Grant: Block access

Before blocking legacy auth, run the sign-in logs query below to identify any service accounts, printers or shared mailboxes still using basic authentication. Migrating those first prevents an outage.

KQL — Azure AD Sign-in Logs

SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Exchange ActiveSync","IMAP4","POP3","SMTP","Authenticated SMTP","Other clients")
| summarize Count=count(), LastSeen=max(TimeGenerated) by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by Count desc

Policy 4 — Require Compliant Device for M365 Apps

After Intune compliance policies are live, enforce device compliance for access to Exchange Online, SharePoint, and Teams.

Users: All users (exclude service accounts)
Target resources: Office 365
Grant: Require compliant device OR hybrid Azure AD joined device (use OR to support both managed and hybrid paths)

Policy 5 — Block Risky Sign-ins (P2)

Users: All users
Conditions → Sign-in risk: High
Grant: Block access
Create a parallel policy for Medium risk that requires MFA + password change

Named Locations & Country Blocking

Named Locations let you define trusted IP ranges (office egress IPs, VPN exit nodes) or trusted countries. Use them to reduce MFA friction for on-site users or to block sign-ins from regions where you have no operations.

In Entra ID → Security → Conditional Access → Named Locations, click + IP ranges location.

Add your office/VPN public IP ranges in CIDR notation (e.g. 203.0.113.0/24). Tick "Mark as trusted location".

Create a separate Countries location listing only the countries where your organization operates.

Create a CA policy: All users → All cloud apps → Conditions: Locations = Any location, exclude Selected locations (your allowed countries) → Grant: Block access.

For organizations with staff travelling internationally, use Entra ID Protection travel anomaly (impossible travel) rather than hard country blocks. This avoids blocking legitimate travel while still flagging suspicious sign-ins.

Requiring Device Compliance

Once Intune compliance policies are deployed (see the Compliance vs Configuration Profiles article), you can gate access to corporate resources on device compliance. The key decision is the grant operator:

Grant Combination	Behaviour	Use Case
Require compliant device AND MFA	Both required	Maximum security — admin portals
Require compliant device OR MFA	Either satisfies	Allows BYOD with MFA fallback
Require hybrid joined OR compliant	Either satisfies	Mixed managed/hybrid environments

Testing with the What If Tool

Never enable a CA policy without simulating it first. The What If tool in Entra ID lets you replay any sign-in scenario against your current policy set before it goes live.

Go to Entra ID → Security → Conditional Access → What If.

Select a user, target application, IP address / location, and device platform.

Click What If. The tool shows which policies apply, which are excluded, and the final access decision (Grant / Block / MFA required).

Test at least: your break-glass account (should bypass all policies), an admin user, a regular user on a compliant device, a regular user on an unmanaged device.

After enabling policies in Report-only mode, check Entra ID → Sign-in logs → Conditional Access tab on any sign-in event to see which policies would have triggered. Use this data for 2–4 weeks before switching policies to On.

Rollout Order & Break-Glass Accounts

A poorly sequenced rollout can lock you out of your own tenant. Follow this order:

Create two break-glass accounts before doing anything else. These are cloud-only, permanently MFA-exempt, Global Admin accounts stored in a vault. Exclude them from every CA policy via a dedicated group.

Set all new policies to Report-only initially. Monitor sign-in logs for 2–4 weeks.

Enable policies for a pilot group first (IT team). Enable for all users after the pilot confirms no breakage.

Communicate to end users before enabling MFA enforcement — provide Microsoft Authenticator setup instructions and a self-service MFA registration link.

Enable the legacy auth block policy last, after confirming no legacy auth traffic remains in your sign-in logs.

Break-glass accounts must use very long, complex passwords stored in a physical vault (not a password manager). Enable an alert when they sign in: Entra ID → Diagnostic settings → send sign-in logs to Log Analytics → create an alert rule on break-glass UPNs.

Badra Ali Diakite

Senior IT Consultant specialising in Microsoft 365, Intune, Zero Trust architecture and network infrastructure. 15+ years across 28+ countries in both military and enterprise environments.