Conditional Access Policies: A Complete Implementation Guide for Microsoft Entra

Conditional access is the engine that drives Zero Trust in Microsoft environments. Rather than granting blanket access based on credentials alone, conditional access evaluates every authentication request against a set of signals — user identity, device health, location, risk level, and application sensitivity — before deciding whether to allow, block, or require additional verification.

This guide walks you through designing and deploying conditional access policies in Microsoft Entra ID (formerly Azure Active Directory), from foundational concepts to advanced risk-based automation.

Prerequisites

Before implementing conditional access policies, ensure you have the following in place:

• Microsoft Entra ID P1 or P2 license — P1 provides core conditional access; P2 adds risk-based policies and Identity Protection integration.
• Global Administrator or Security Administrator role in your Entra tenant.
• Multi-factor authentication (MFA) configured for at least your admin accounts.
• Device management through Microsoft Intune or a supported MDM if you plan to enforce device compliance.
• Named locations defined for your corporate offices, VPN exit points, and trusted networks.
• A break-glass account excluded from all conditional access policies, stored securely with monitoring enabled.

Architecture and Core Concepts

How Conditional Access Works

Every time a user authenticates, Microsoft Entra evaluates the request through a policy engine. The evaluation follows this flow:

1. Signal collection — The engine gathers context: who is the user, what device are they on, where are they connecting from, what application are they accessing, and what is their risk level.
2. Policy matching — All enabled policies are evaluated. A policy applies when its conditions (assignments) match the current authentication context.
3. Control enforcement — Matching policies enforce their access controls. If multiple policies apply, the most restrictive combination wins.
4. Session controls — After granting access, session controls can limit what the user can do (sign-in frequency, persistent browser sessions, app-enforced restrictions).

The Policy Structure

Every conditional access policy has two parts:

Assignments (When does this policy apply?)

• Users and groups (include/exclude)
• Cloud apps or actions
• Conditions: device platforms, locations, client apps, user risk, sign-in risk, device state

Access Controls (What happens when it applies?)

• Grant controls: block access, require MFA, require compliant device, require hybrid Azure AD joined device, require approved client app, require app protection policy
• Session controls: sign-in frequency, persistent browser, conditional access app control (MCAS), customize token lifetime

Step-by-Step Implementation

Step 1: Establish Your Baseline Policies

Start with a foundational set of policies that protect your highest-risk scenarios. Deploy these in report-only mode first.

Policy 1: Require MFA for all administrators

Navigate to Microsoft Entra admin center > Protection > Conditional Access > Create new policy.

• Name: CA001 — Require MFA for Admins
• Assignments:
  • Users: Include directory roles — Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Helpdesk Administrator, Billing Administrator, Compliance Administrator
  • Exclude: Your break-glass accounts
  • Cloud apps: All cloud apps
• Grant: Require multifactor authentication
• Session: Sign-in frequency — 4 hours

Policy 2: Require MFA for all users

• Name: CA002 — Require MFA for All Users
• Assignments:
  • Users: All users
  • Exclude: Break-glass accounts, service accounts that cannot perform MFA
  • Cloud apps: All cloud apps
  • Conditions: Client apps — Browser, Mobile apps and desktop clients
• Grant: Require multifactor authentication

Policy 3: Block legacy authentication

Legacy authentication protocols (IMAP, POP3, SMTP, older Office clients) cannot perform MFA and represent a massive attack surface.

• Name: CA003 — Block Legacy Authentication
• Assignments:
  • Users: All users
  • Cloud apps: All cloud apps
  • Conditions: Client apps — Exchange ActiveSync clients, Other clients
• Grant: Block access

Step 2: Implement Location-Based Policies

Define your trusted locations first, then build policies around them.

Creating Named Locations:

1. Go to Protection > Conditional Access > Named locations.
2. Add your corporate office IP ranges as a trusted location.
3. Add any VPN egress IP ranges.
4. Consider marking specific countries as blocked if your organization has no business presence there.

Policy 4: Block access from high-risk countries

• Name: CA004 — Block Access from Restricted Countries
• Assignments:
  • Users: All users (exclude break-glass)
  • Cloud apps: All cloud apps
  • Conditions: Locations — Include selected locations (countries you want to block), Exclude trusted locations
• Grant: Block access

Policy 5: Require compliant device from untrusted locations

• Name: CA005 — Require Compliant Device Off-Network
• Assignments:
  • Users: All users
  • Cloud apps: Office 365 (or specific sensitive apps)
  • Conditions: Locations — Exclude trusted locations (so this fires only off-network)
• Grant: Require device to be marked as compliant OR require multifactor authentication

Step 3: Deploy Risk-Based Policies (Requires Entra P2)

Microsoft Entra Identity Protection assigns risk scores to users and sign-ins based on behavioral analysis, threat intelligence, and anomaly detection.

Sign-in risk levels:

• High — Strong indicators of compromise (impossible travel + credential stuffing pattern)
• Medium — Suspicious but not definitive (unfamiliar location + anonymous IP)
• Low — Mildly unusual behavior

User risk levels:

• High — Leaked credentials confirmed or multiple high-risk sign-ins
• Medium — Some indicators of account compromise
• Low — Minor anomalies

Policy 6: Respond to high sign-in risk

• Name: CA006 — High Sign-in Risk Response
• Assignments:
  • Users: All users (exclude break-glass)
  • Cloud apps: All cloud apps
  • Conditions: Sign-in risk — High
• Grant: Require multifactor authentication
• Session: Sign-in frequency — every time

Policy 7: Respond to high user risk

• Name: CA007 — High User Risk Response
• Assignments:
  • Users: All users (exclude break-glass)
  • Cloud apps: All cloud apps
  • Conditions: User risk — High
• Grant: Require multifactor authentication AND require password change

Step 4: Device Compliance Policies

For organizations using Intune or another MDM, device compliance adds a powerful security layer.

Define compliance requirements in Intune first:

• OS version minimums (e.g., Windows 11 23H2+, macOS 14+, iOS 17+)
• Encryption required
• Firewall enabled
• Antivirus active and up to date
• No jailbreak/root detection

Policy 8: Require compliant device for sensitive apps

• Name: CA008 — Require Compliant Device for Sensitive Apps
• Assignments:
  • Users: All users
  • Cloud apps: Select your sensitive applications (HR systems, finance apps, admin portals)
  • Conditions: Device platforms — Windows, macOS, iOS, Android
• Grant: Require device to be marked as compliant

Step 5: Application-Specific Policies

Different applications warrant different levels of protection.

Policy 9: Restrict Azure portal access

• Name: CA009 — Restrict Azure Management
• Assignments:
  • Users: All users (exclude admins group, break-glass)
  • Cloud apps: Microsoft Azure Management, Microsoft Graph PowerShell
• Grant: Block access

This ensures only designated administrators can access Azure management interfaces.

Best Practices

Policy Naming Convention

Adopt a consistent naming scheme. A proven pattern:

CA[NNN] — [Action] [Target] [Condition]

Examples:

• CA001 — Require MFA for Admins
• CA004 — Block Access from Restricted Countries
• CA008 — Require Compliant Device for Sensitive Apps

Report-Only Mode Is Non-Negotiable

Never deploy a conditional access policy directly to enforcement. Always:

1. Create the policy in report-only mode.
2. Monitor the Conditional Access insights workbook for 1-2 weeks.
3. Review the sign-in logs to identify affected users and potential disruptions.
4. Adjust exclusions if necessary.
5. Move to on only after validating impact.

Exclusion Hygiene

Every exclusion is a potential security gap. For every excluded user or group:

• Document the business justification.
• Set a review date (quarterly at minimum).
• Use a dedicated security group for exclusions rather than excluding individual accounts.
• Monitor excluded accounts more aggressively.

Policy Ordering and Conflicts

Conditional access policies do not have explicit ordering. All matching policies apply simultaneously, and the most restrictive grant controls win. This means:

• If Policy A requires MFA and Policy B requires a compliant device, the user must satisfy both.
• If any matching policy blocks access, access is blocked regardless of other policies.

Design your policies with this additive model in mind.

Testing Your Policies

Use the What If Tool

The What If tool in the Entra admin center lets you simulate policy evaluation without actually signing in.

1. Navigate to Protection > Conditional Access > What If.
2. Select a user, an application, and optionally set conditions (IP address, device platform, risk level).
3. Click "What If" to see which policies would apply and what controls would be enforced.

Test every policy against these scenarios:

• Admin signing in from a corporate device on the trusted network
• Regular user signing in from a personal device off-network
• User signing in from a blocked country
• User with elevated risk score
• Service account authenticating via API

Sign-In Log Analysis

After enabling report-only policies, regularly check:

1. Sign-in logs — Filter by conditional access status (success, failure, report-only)
2. Conditional Access insights workbook — Provides aggregated views of policy impact
3. Risky sign-ins report — Shows whether risk-based policies would have caught actual threats

Common Pitfalls

Locking Yourself Out

The most dangerous mistake is creating a policy that blocks all users from all apps without a break-glass exclusion. Always:

• Maintain at least two break-glass accounts excluded from all policies
• Store break-glass credentials in a physical safe or hardware security module
• Monitor break-glass account usage with alerts
• Test break-glass accounts quarterly

Forgetting Service Accounts

Service accounts and automated processes often cannot perform MFA. If you apply an MFA policy to all users without excluding service accounts, automated workflows will break. Identify all service accounts, place them in a dedicated group, and exclude that group from MFA policies while applying compensating controls (IP restrictions, specific app restrictions).

Over-Relying on Location

IP-based location policies are useful but imperfect. Users on VPNs, mobile hotspots, or traveling may trigger unexpected blocks. Always pair location-based policies with alternative grant options (MFA instead of block when off-network) unless you have a strong business reason to hard-block.

Ignoring Guest and B2B Users

External users (B2B guests) are subject to conditional access policies in your tenant. If you require MFA for all users, guests will need to perform MFA too. Consider whether your partners can satisfy this requirement and create appropriate guest-specific policies.

Not Planning for Failure

If your MFA provider experiences an outage, every user could be locked out. Plan for this by:

• Enabling multiple MFA methods (authenticator app + phone + FIDO2 key)
• Having a documented emergency procedure to temporarily disable MFA policies
• Monitoring MFA service health proactively

Conclusion

Conditional access policies are the linchpin of modern identity security in Microsoft environments. They transform authentication from a binary yes/no gate into a dynamic, context-aware decision engine. Start with the foundational policies — MFA for all users, blocking legacy authentication, and location-based controls — then layer on risk-based policies and device compliance as your maturity grows.

The key to success is disciplined deployment: always use report-only mode first, maintain break-glass accounts, document every exclusion, and review policy effectiveness quarterly. Conditional access is not a set-and-forget technology. It requires ongoing tuning as your organization, threat landscape, and user behaviors evolve.

Frequently Asked Questions

Q: Can I use conditional access with non-Microsoft applications? A: Yes. Any application registered in Microsoft Entra ID (including SAML and OIDC apps) can be targeted by conditional access policies. This includes thousands of pre-integrated SaaS applications in the Entra gallery.

Q: What happens if a user matches multiple policies with conflicting controls? A: All matching policies are evaluated together. Grant controls are combined with AND logic — the user must satisfy all required controls from all matching policies. If any policy blocks access, the block takes precedence.

Q: Do conditional access policies apply to mobile apps? A: Yes, conditional access applies to modern authentication flows on mobile devices. You can target specific device platforms (iOS, Android) and require app protection policies or compliant devices for mobile access.

Q: How do I handle the transition period when deploying MFA for all users? A: Use a phased rollout. Start with report-only mode, then enable enforcement for IT staff first, followed by department-by-department rollout over 4-8 weeks. Provide clear communication and support resources at each phase.

Q: Can conditional access detect if a device is compromised? A: Through integration with Microsoft Intune and Microsoft Defender for Endpoint, conditional access can evaluate device risk level and compliance status. A device flagged as compromised by Defender would fail compliance checks, triggering additional controls or access denial.