Conditional Access Policies: Zero Trust with Entra ID

Overview

Zero Trust is a security model that assumes breach and verifies every request. Microsoft Entra ID Conditional Access is the Zero Trust policy engine that evaluates signals and enforces access decisions for every authentication attempt.

Who Should Use This Guide:

• Security administrators implementing Zero Trust architecture
• Identity engineers managing Entra ID
• Compliance teams enforcing security policies
• Organizations moving beyond perimeter-based security

Zero Trust Principles:

Conditional Access Signal Evaluation:

┌─────────────────────────────────────────────────────────┐
│              Conditional Access Decision                 │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  SIGNALS                    DECISION       ENFORCEMENT  │
│  ┌────────────┐                                         │
│  │   User     │────┐                                    │
│  │  Identity  │    │        ┌──────────┐               │
│  └────────────┘    │        │          │               │
│  ┌────────────┐    │        │  Allow   │───▶ Access    │
│  │   Device   │────┼───────▶│    or    │    Granted   │
│  │   State    │    │        │  Block   │               │
│  └────────────┘    │        │    or    │               │
│  ┌────────────┐    │        │ Require  │───▶ MFA/      │
│  │  Location  │────┤        │  Grant   │   Compliant  │
│  │   (IP)     │    │        │ Controls │               │
│  └────────────┘    │        └──────────┘               │
│  ┌────────────┐    │                                   │
│  │   Risk     │────┘                                   │
│  │   Level    │                                        │
│  └────────────┘                                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

Requirements

Licensing Requirements:

Planning Prerequisites:

Process

Step 1: Create Break-Glass Accounts

Before implementing Conditional Access, create emergency access accounts to prevent lockout.

Create Emergency Access Accounts:

1. Navigate to Entra admin center → Users → New user
2. Create two accounts:
   • emergency-access-01@domain.com
   • emergency-access-02@domain.com
3. Assign Global Administrator role
4. Use complex, unique passwords (store in secure vault)
5. Do NOT enable MFA on these accounts

Secure the Accounts:

Create Exclusion Group:

1. Navigate to Groups → New group
2. Create: CA-Exclude-BreakGlass
3. Add both emergency access accounts
4. Document this group - it will be excluded from all CA policies

Verification: Sign in with emergency account works without MFA or other restrictions.

Step 2: Configure Named Locations

Define trusted network locations to use in Conditional Access policies.

Navigate to: Entra admin center → Protection → Conditional Access → Named locations

Create Corporate Network Location:

1. Click + Countries location or + IP ranges location
2. For IP ranges:
   • Name: Corporate-Offices
   • Mark as trusted location: Yes
   • IP ranges: Add corporate public IPs

Example IP Ranges:
203.0.113.0/24    (Main office)
198.51.100.0/24   (Branch office)
192.0.2.0/24      (Data center)

Create Country-Based Location:

1. Click + Countries location
2. Name: Allowed-Countries
3. Determine location by: IP address
4. Select countries where your organization operates

Mark Trusted Locations:

Step 3: Create Baseline Policies

Implement foundational Conditional Access policies following Microsoft best practices.

Policy 1: Require MFA for All Users

Navigate to: Conditional Access → Create new policy

Name: CA001-Require-MFA-AllUsers
State: Report-only (initially)
 
Users:
  Include: All users
  Exclude:
    - CA-Exclude-BreakGlass
    - Directory sync accounts
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  Client apps:
    - Browser
    - Mobile apps and desktop clients
 
Grant:
  Require authentication strength: Multifactor authentication

Policy 2: Block Legacy Authentication

Name: CA002-Block-LegacyAuth
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  Client apps:
    - Exchange ActiveSync clients
    - Other clients
 
Grant:
  Block access

Policy 3: Require Compliant Device for Office 365

Name: CA003-Require-CompliantDevice-O365
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: Office 365
 
Conditions:
  Device platforms:
    - Windows
    - iOS
    - Android
    - macOS
 
Grant:
  Require one of the following:
    - Require device to be marked as compliant
    - Require Hybrid Azure AD joined device

Policy 4: Block Access from Untrusted Locations

Name: CA004-Block-UntrustedCountries
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  Locations:
    Include: All locations
    Exclude: Allowed-Countries
 
Grant:
  Block access

Step 4: Implement Risk-Based Policies

Use Identity Protection risk signals to dynamically adjust access requirements.

Requires: Entra ID P2 license

Policy 5: Require MFA for Medium/High Sign-in Risk

Name: CA005-SignInRisk-RequireMFA
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  Sign-in risk:
    - Medium
    - High
 
Grant:
  Require authentication strength: Multifactor authentication
 
Session:
  Sign-in frequency: Every time

Policy 6: Require Password Change for High User Risk

Name: CA006-UserRisk-PasswordChange
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  User risk:
    - High
 
Grant:
  Require password change
  Require multifactor authentication

Risk Level Explanations:

Step 5: Configure Phishing-Resistant MFA

Implement strong authentication methods that resist phishing attacks.

Navigate to: Entra admin center → Protection → Authentication methods

Enable FIDO2 Security Keys:

1. Go to Authentication methods → FIDO2 security key
2. Enable for target groups
3. Configure key restrictions if needed

Enable Windows Hello for Business:

1. Go to Authentication methods → Windows Hello for Business
2. Enable for all users or target groups
3. Configure: Require security key for sign-in: Yes

Enable Passkeys (Microsoft Authenticator):

1. Go to Authentication methods → Microsoft Authenticator
2. Enable for all users
3. Authentication mode: Passkey (preview)

Create Authentication Strength:

1. Navigate to Protection → Authentication methods → Authentication strengths
2. Click + New authentication strength
3. Create: Phishing-Resistant-MFA
4. Select:
   • FIDO2 security key
   • Windows Hello for Business
   • Passkey in Microsoft Authenticator

Apply to Sensitive Apps:

Name: CA007-PhishResistant-SensitiveApps
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include:
    - Azure portal
    - Microsoft 365 admin center
    - Microsoft Intune
 
Grant:
  Require authentication strength: Phishing-Resistant-MFA

Step 6: Protect Privileged Accounts

Apply enhanced controls to administrative accounts.

Policy 8: Require Compliant Device for Admin Portals

Name: CA008-AdminPortals-CompliantDevice
State: Report-only
 
Users:
  Include:
    - Directory roles: All privileged roles
 
Cloud apps:
  Include:
    - Microsoft Azure Management
    - Microsoft 365 admin center
    - Microsoft Intune
    - Microsoft Entra admin center
 
Grant:
  Require all of the following:
    - Require authentication strength: Phishing-Resistant-MFA
    - Require device to be marked as compliant
 
Session:
  Sign-in frequency: 4 hours
  Persistent browser session: Never persistent

Policy 9: Block Admin Access from Non-Trusted Locations

Name: CA009-AdminPortals-TrustedLocations
State: Report-only
 
Users:
  Include: Directory roles (all privileged roles)
 
Cloud apps:
  Include: Microsoft Azure Management
 
Conditions:
  Locations:
    Include: All locations
    Exclude:
      - Corporate-Offices
      - Trusted VPN IPs
 
Grant:
  Block access

Step 7: Configure Session Controls

Implement session-based controls for additional security.

Sign-in Frequency:

Persistent Browser Sessions:

Name: CA010-Session-Controls
State: Report-only
 
Users:
  Include: All users
  Exclude: CA-Exclude-BreakGlass
 
Cloud apps:
  Include: All cloud apps
 
Conditions:
  Device state:
    Exclude: Devices marked as compliant
 
Session:
  Sign-in frequency: 1 day
  Persistent browser session: Never persistent

Continuous Access Evaluation (CAE):

CAE is automatically enabled for supported apps and provides near real-time policy enforcement:

• Token revocation on password change
• Token revocation on user disable
• Location policy changes enforced immediately

Step 8: Test in Report-Only Mode

All policies should be tested in Report-only mode before enforcement.

Analyze Policy Impact:

1. Navigate to Conditional Access → Insights and reporting
2. Select date range and specific policies
3. Review:
   • Users who would be blocked
   • Users who would be required to complete grant controls
   • Success/failure breakdown

What-If Tool:

1. Navigate to Conditional Access → What If
2. Enter test parameters:
   • Select user
   • Select cloud app
   • Set conditions (location, device, risk)
3. Click What If
4. Review which policies would apply

Phased Rollout:

Step 9: Enable Policies

After successful testing, enable policies in production.

Enabling Checklist:

• Report-only data reviewed for each policy
• No unexpected blocks or failures
• Break-glass accounts tested and excluded
• Help desk briefed on expected user experience
• Communication sent to affected users
• Rollback plan documented

Enable Policies:

1. Navigate to each policy
2. Change Enable policy from Report-only to On
3. Save changes
4. Monitor for issues in first 24-48 hours

Enable Order (Recommended):

1. CA002 - Block Legacy Auth (low user impact)
2. CA001 - Require MFA All Users
3. CA003 - Require Compliant Device
4. CA004-CA010 - Additional policies

Troubleshooting

Common Issues:

Diagnostic Steps:

# View user's sign-in logs
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userId eq '<user-id>'" -Top 10
 
# Check Conditional Access policy application
Get-MgAuditLogSignIn -Filter "userId eq '<user-id>'" | Select-Object -ExpandProperty AppliedConditionalAccessPolicies

Sign-in Log Analysis:

Navigate to: Entra admin center → Monitoring → Sign-in logs

1. Filter by user or application
2. Click specific sign-in event
3. Review Conditional Access tab
4. Check Report-only vs Applied policies

Security Considerations

Policy Naming Convention:

Use consistent naming for easier management:

CA[###]-[Action]-[Target]
Examples:
CA001-Require-MFA-AllUsers
CA002-Block-LegacyAuth
CA003-Require-Compliance-O365

Regular Policy Review:

Avoid Common Mistakes:

Verification Checklist

Configuration:

• Break-glass accounts created and secured
• Named locations configured (corporate IPs, countries)
• Authentication methods enabled (FIDO2, WHfB)
• Custom authentication strengths created
• Device compliance policies in Intune

Policies Implemented:

• Require MFA for all users
• Block legacy authentication
• Require compliant device for Office 365
• Block untrusted countries
• Risk-based policies (sign-in and user risk)
• Phishing-resistant MFA for sensitive apps
• Privileged account protections

Validation:

• All policies tested in Report-only mode
• What-If tool validated for key scenarios
• Break-glass accounts can sign in without CA
• Help desk trained on user experience
• Rollback procedures documented

Next Steps

After implementing Conditional Access:

1. Enable Identity Protection - Configure risk remediation policies
2. Implement PIM - Just-in-time privileged access
3. Deploy Certificate-Based Auth - Enterprise certificate authentication
4. Configure Access Reviews - Regular entitlement reviews

References

• Conditional Access Documentation
• Zero Trust Deployment Guide
• Authentication Strengths
• Identity Protection Risk Policies
• Break-Glass Account Best Practices

Last Updated: February 2026