Conditional Access Design

Focused skills. One capability. Production-ready.

Design Conditional Access policy sets that form a coherent zero-trust enforcement layer. Build baseline policies, risk-based policies, and break-glass accounts with a testing methodology that prevents lockouts and a troubleshooting workflow for sign-in failures.

Start Skill See Full Curriculum + Pricing

Text-based · Persistent labs on your own hardware · 2 free modules available now · Content last updated: May 2026

What you'll deploy

✓ Conditional Access policy designs for common attack paths

✓ Policy testing and validation methodology

✓ Gap analysis framework for existing CA configurations

The problem this solves

Conditional Access evaluates every authentication request against a set of policies. Each policy says: for these users, accessing these apps, from these conditions, require these controls — or block. The framework is simple. The implementation is where organizations fail: policies that overlap and conflict, exclusions that create invisible gaps, device compliance requirements that block legitimate users, and risk-based policies that either fire constantly or never fire at all.

This skill builds CA as a design discipline. You'll build a complete policy set from scratch, test it in report-only mode, deploy incrementally, and troubleshoot failures from sign-in logs.

What you will be able to do

1. Design a CA policy set that covers every authentication scenario — internal users, external users, guests, service accounts, admin accounts, unmanaged devices, and risky sign-ins — with no gaps and no conflicts.

2. Configure named locations, device compliance policies, and authentication strength requirements that adapt access based on context — not just block or allow.

3. Deploy risk-based policies using Entra ID Protection sign-in risk and user risk signals, with appropriate thresholds that catch attacks without blocking legitimate travel.

4. Implement the break-glass pattern: emergency access accounts that bypass all CA policies, with monitoring and alerting to detect their use.

5. Troubleshoot CA failures from sign-in logs — read the Conditional Access evaluation, identify which policy blocked, which condition failed, and fix the root cause in under 5 minutes.

Skill at a glance

Format: Ridgeline Skill — focused, practical, one topic

Sections: 6 content sections + guided lab

Tier: Premium subscription

Prerequisites: Basic Entra ID familiarity (you know what a user, group, and application registration are). The Entra ID Security course provides the full identity security context.

Typical pace: 1-2 weeks at a few hours per week

What you leave with

Policy design template: A baseline CA policy set covering 8 scenarios (admin MFA, user MFA, device compliance, guest access, risky sign-in, risky user, block legacy auth, break-glass) — ready to adapt for your environment.

Testing methodology: The report-only → targeted group → full deployment workflow that prevents lockouts.

Troubleshooting playbook: Sign-in log analysis for CA failures — which policy, which condition, which fix.

Sections

Six focused sections plus a guided design lab. Every policy targets the Northgate Engineering environment.

CA0.1

How Conditional Access Works — The evaluation model: assignments (users, apps, conditions) and access controls (grant, block, session). Policy precedence — why "most restrictive wins" matters. The three policy states: on, off, report-only. How CA interacts with Security Defaults, per-user MFA, and authentication methods. Common misconceptions that cause gaps.

CA0.2

The Baseline Policy Set — Eight policies every organization needs: require MFA for admins, require MFA for all users, require compliant device for corporate apps, block legacy authentication, restrict guest access, require MFA for Azure management, require MFA for risky sign-ins, and the break-glass exclusion. Each policy built step by step with exact configuration.

CA0.3

Conditions, Named Locations, and Device Compliance — Named locations (trusted IPs, countries). Device platforms and compliance states. Client apps (browser, mobile, desktop). Sign-in risk and user risk levels. Authentication strength (phishing-resistant MFA vs any MFA vs passwordless). Combining conditions for context-aware access: "from a trusted location on a compliant device = no MFA, from an unknown location on an unmanaged device = MFA + limited session."

CA0.4

Risk-Based Policies and Break-Glass Accounts — Entra ID Protection: sign-in risk (real-time) and user risk (cumulative). Risk levels: low, medium, high. Configuring risk-based CA: require MFA for medium risk, block for high risk, force password change for high user risk. False positives: VPN, travel, new devices. Break-glass accounts: creation, securing (FIDO2 key in a safe), monitoring with a Sentinel alert, and testing quarterly.

CA0.5

Testing and Deployment Without Lockouts — The deployment methodology: report-only mode for 14 days → apply to pilot group → monitor sign-in logs → expand to all users. Reading the CA evaluation in sign-in logs: which policies applied, which conditions matched, which control was enforced. The What If tool for pre-deployment testing. Rollback strategy when a policy breaks something.

CA0.6

Troubleshooting CA Failures — Ten real-world CA failure scenarios: user locked out by overlapping policies, service account blocked by device compliance, guest can't access shared resources, VPN triggers risky sign-in, new device fails compliance check, legacy app uses basic auth, CA policy doesn't apply to expected users, break-glass account accidentally included in a policy, authentication strength blocks a valid MFA method, session policy causes repeated prompts. Diagnosis from sign-in logs and fix for each.

Lab

Guided Lab: Design CA for Northgate Engineering — NE has Security Defaults enabled and per-user MFA on 3 admin accounts. No CA policies. Design and document the complete CA policy set: 8 baseline policies, named locations for NE's 6 offices, device compliance for managed Windows endpoints, risk-based policies, and break-glass accounts. Produce the policy matrix and deployment timeline.

Where CA fits

Conditional Access is the enforcement layer for identity security. It connects to everything: MFA (what CA requires), device management (what CA checks), risk detection (what CA responds to), and application access (what CA controls). This skill focuses on the CA policy layer specifically. For the broader identity security architecture, see Entra ID Security.

What this skill is not

This is not an Intune or device management course. Device compliance policies appear as CA conditions, but creating compliance policies in Intune is outside scope. This is not an Entra ID Protection deep-dive — risk signals are used as CA inputs, but configuring risk detection is covered in the full Entra ID Security course.