Conditional Access Design

Focused skills. One thing, learned properly.

Learn to design Conditional Access policy sets that form a coherent zero-trust enforcement layer. Baseline policies, risk-based policies, break-glass accounts, testing methodology, deployment without lockouts, and troubleshooting failures.

Start Skill View Pricing

Content last updated: April 2026

Why take this course

For Entra ID administrators and security engineers responsible for identity access control. You finish able to design layered conditional access policies that block modern identity attacks including AiTM and device registration bypass — the policy design capability that determines whether CA actually protects the tenant.

What this skill teaches

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 organisations 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 teaches 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.

What this course does NOT cover

Deliberate scope boundaries. If any of these is your primary need, the sibling course is the better fit.

Broader Entra ID security architecture — see Microsoft Entra ID Security
Incident response when CA is bypassed — see Practical Incident Response: Windows & M365

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 organisation 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.