Azure Conditional Access Policy Design: Complete Guide with Baselines, Templates & Patterns

Microsoft Entra ID Conditional Access is the central technology of modern enterprise identity management. It evaluates conditions such as user, group, app, sign-in risk, device state, and location to dynamically control access, sitting at the heart of the Identities pillar of Zero Trust strategy. This article walks through how Conditional Access works, the recommended baseline policies, implementation templates, operational best practices, and the common pitfalls.

How Conditional Access Works

A Conditional Access policy is defined with the structure "Conditions → Controls".

Conditions

• Users / Groups: Target users, groups, guests, and specific roles
• Cloud apps or actions: Microsoft 365, Azure, and third-party SaaS apps
• Conditions: Sign-in Risk, User Risk, device platform, location (Named Locations), client app, device state (Compliant / Hybrid Joined), and filters

Controls

• Grant Controls: Block / Grant access, with additional requirements on grant (MFA, compliant device, Hybrid Azure AD Join, approved app, password change, terms of use acceptance)
• Session Controls: Sign-in Frequency, Persistent Browser Session, App Enforced Restrictions, Conditional Access App Control (CASB), and customized continuous access evaluation

Prerequisites: Licensing and Initial Setup

Enabling Conditional Access requires the following:

• Microsoft Entra ID Premium P1 or higher (Microsoft 365 E3 / Business Premium / standalone Entra ID P1)
• Premium P1 license assigned to every targeted user (e.g., 1,000 P1 licenses for 1,000 targeted users)
• Additional features with Premium P2: risk-based Conditional Access (Identity Protection) and PIM integration
• Cannot be used alongside Security Defaults (enabling Conditional Access auto-disables Security Defaults)

Seven Recommended Baseline Policies

Here is the Conditional Access baseline (the recommended starter set) published by Microsoft. The standard playbook for a new Conditional Access deployment is to introduce these policies one by one in Report-only mode.

1. Require MFA for admin roles: Covers 14 roles including Global Admin and Privileged Role Admin. The first line of defense for privileged access.
2. Require MFA for all users: Org-wide rollout. The single highest-impact control against account compromise.
3. Block known risky sign-ins: Block High Risk sign-ins via Identity Protection integration (requires Premium P2).
4. Block legacy authentication: POP/IMAP/SMTP/Basic Auth — the classic MFA bypass paths.
5. Require MFA for admin portal access: Target apps like azure-portal, admin-portal, and microsoft-intune-portal.
6. Block access from non-compliant devices: Integrated with Microsoft Intune Compliance Policies.
7. Country-based access restrictions: Block access from China, Russia, North Korea, etc. using Named Locations.

Using Report-only Mode

Report-only mode is a test mode that does not actually enforce the Conditional Access policy and only logs the result of applying it.

• When rolling out a new policy, always run it in Report-only for 1-2 weeks and check Sign-in Logs for unintended blocks
• A misconfigured policy (e.g., requiring iOS devices for all users) enforced in production would lock out every Windows user
• Check for the 'Failure - Reported only' status in the Report-only column of Sign-in Logs
• The What If tool also lets you simulate policy outcomes in advance

Break Glass Accounts (Emergency Access)

The single most important prerequisite for Conditional Access operations is excluding Break Glass accounts.

1. Always create two Break Glass accounts (one excluded from Conditional Access, the second as an additional safety net)
2. Cloud-only accounts (no on-prem AD sync, no AD FS / federation)
3. 16+ character ultra-strong passwords, stored physically separated in a password manager
4. Global Administrator role assigned permanently (Active, not PIM Eligible)
5. Excluded from every single Conditional Access policy
6. Sign-in alerts configured to notify the CISO / IT security team whenever the account is used

If you forget to set up Break Glass accounts, a Conditional Access misfire can lock every admin in the organization out — a catastrophic failure scenario.

Designing Named Locations

Named Locations let you define IP address ranges (CIDR) or countries as named entities that Conditional Access Conditions can reference.

Using Session Controls

Session Controls govern session behavior after authentication.

Sign-in Frequency

• Sensitive data access → re-authenticate every 1 hour
• Admin portals → every 4 hours
• General users → every 8 hours (one business day)
• High-security environments → re-authenticate every time the browser closes (set Persistent Browser Session to Never)

Other Controls

• Persistent Browser Session: Toggle between Always and Never. Never is recommended for shared-computer environments.
• App Enforced Restrictions: Restrictions like 'web browser only, no downloads' for SharePoint / OneDrive
• Conditional Access App Control: Integrates with Microsoft Defender for Cloud Apps (CASB) for inline monitoring of third-party SaaS

Testing and Operations Best Practices

1. Run in Report-only for 1-2 weeks and review Sign-in Logs for applied results
2. A scoped Pilot Group enforces for one week ahead of broader rollout (e.g., 50 people in the IT department only)
3. Use the What If tool to simulate expected behavior for individual users
4. Expand the target user base in stages (Pilot → 100 → 500 → org-wide)
5. Aggregate Sign-in Logs into Microsoft Sentinel for anomaly detection
6. Review policies regularly (quarterly, checking Microsoft Secure Score)

Conditional Access Pitfalls

1. Forgetting to exclude Break Glass accounts from Conditional Access: The most catastrophic failure mode. Always create two and add them as exclusions.
2. Enforcing in production without Report-only first: The textbook scenario for a full-org lockout incident.
3. Marking Named Locations as Trusted: Risk policies stop firing. Use Trusted only when you truly need it.
4. Missing CA configuration for Service Principals / Managed Identities: Conditional Access for Workload Identities is now supported.
5. Legacy authentication in third-party apps: If Basic Auth remains in Slack, Salesforce, etc., CA cannot enforce.
6. Mobile-app App Password bypass: Apps using legacy protocols can bypass MFA.

Related Certification Exams

• SC-300 (Identity and Access Administrator Associate): Goes deep on Conditional Access.
• MS-102 (Microsoft 365 Administrator Expert): Domain 2 (Identity and Access).
• SC-100 (Cybersecurity Architect Expert): Core to Zero Trust strategy.
• SC-200 (Security Operations Analyst): Sentinel integration and Identity Protection.

Frequently Asked Questions

The technical content in this article is based on the Microsoft Entra Conditional Access Documentation. This article is not an official Microsoft Corporation product, and there is no partnership or sponsorship of any kind. Microsoft, Azure, and Microsoft Entra are trademarks of the Microsoft group of companies. Information reflects official public documentation as of May 24, 2026. Always check the official pages for the latest details.