Conditional Access Design
Design it. Measure it. Change it safely.
Conditional Access is easy to configure into something that looks like a control and is not. Every weak estate looks the same from inside: the policies are individually correct, each decision was reasonable when somebody made it, and together they cover less than anybody believes. This course teaches the instruments that make the gap visible, from reading a verdict off the sign-in record to stating coverage as a number you can put in front of an auditor.
What you'll be able to do
Course Syllabus
Every module and every lesson. The first three modules are open; the rest open on a click.
Download the full syllabus (PDF)
Course Orientation
What Conditional Access Design teaches: the evaluation engine that decides every sign-in, how scope and conditions and controls combine into one verdict, the policy set that covers a tenant without gaps or conflicts, and the testing, troubleshooting, and operating practice that keeps it working. The discipline, the evidence, and how the course is built. Start here.
Phase 1: The Engine
How Conditional Access actually decides. Why the firewall mental model produces gaps, the two evaluation phases and what happens in each, the anatomy of a policy as assignments and access controls, what the three policy states change, how to read the verdict the engine writes for every sign-in, and the paths where Conditional Access is not present at all.
Phase 2: The Policy
Who a Conditional Access policy actually reaches. The include and exclude model and why exclude always wins, groups as the scoping instrument and how their membership drifts, directory role targeting and the roles it cannot reach, the six guest and external user types, workload identities, and the exclusion debt that hollows out most estates.
The signals that decide when a policy fires. Named locations and the network condition, device platform and device filters, sign-in and user and insider risk, client apps and legacy authentication, and the authentication flows control that covers device code flow and authentication transfer.
What actually happens to a request that survives scope and conditions. Block and grant, the require-all and require-one decision, authentication strength, device and app controls, session controls, continuous access evaluation, token protection and resilience defaults.
Phase 3: The Policy Set
Turning individual policies into a set somebody can inherit. How many policies and why, naming as a design decision, the baseline layer, persona-based layering, authentication contexts for step-up access, and the review practice that keeps a set readable.
Phase 4: Ship and Operate
Changing a policy set without breaking anybody. What If and what it can answer, report-only as a deployment instrument, the rollout sequence, diagnosing a failure from the record, policy as code, and recovering when a change has gone wrong.
Phase 0: Course Resources
How evaluation resolves, what each condition and control actually does, and the exclusions that quietly become the policy.
Ordered procedures for building a policy set, shipping a change, auditing coverage, and clearing exclusion debt.
Four cases reasoned end to end, including the policy that was enabled, correct, and evaluating nobody.
A free tenant, a policy set you build yourself, and the checks that make the practice real.
Every portal path, Graph command, log query, specification and check from the Conditional Access Design course in one place, organized by task and linked back to the section that explains when not to use it.
Show 1 lessonHide lessons
Where to check whether anything in this course has changed, what the live open questions are, which features are in preview, and the authoritative page for each class of fact. Organized by the question you arrived with rather than by source type.
Course Completion
Conditional Access Design end-of-course exam: a privileged sign-in the policy set was built to block, and a coverage figure that reported full protection while it happened.
Show 1 lessonHide lessons
Course overview
Conditional Access decides who gets into your tenant and under what conditions. The framework is simple to describe and the implementation is where organizations fail, because almost nothing about a policy tells you what it actually covers. The interface describes each condition by what it keeps. Its effect on your estate is what it releases, and that appears on no screen.
By the end you can answer the question this product makes surprisingly hard: what does this actually cover, and how would I know if that changed.
How this course works
Conditional Access is a policy engine with an evaluation order, and most policy sets are written as if it were a list of rules. This course runs the same loop for every policy it builds.
1. Reason from the evaluation, not the intent. Every policy that applies to a sign-in is evaluated, and the strictest control wins. What you meant is not what the engine does.
2. Scope before condition. Who a policy applies to, and who is excluded, decides more about the outcome than any control on it. Exclusions are where policy sets go wrong quietly.
3. Choose a control you can explain the failure of. Every control blocks somebody eventually. Knowing who, and what they do next, is the difference between a policy and an outage.
4. Run it in report-only and read the result. Report-only tells you who would have been blocked, using real sign-ins rather than a whiteboard. It is the cheapest thing in this course and the most skipped.
5. Design the set, not the policy. Policies interact. A set assembled one policy at a time acquires gaps that no single policy review finds.
The output is a policy set with its exclusions documented and a break-glass path that has been tested rather than assumed.
What this course assumes
No minimum experience and no prerequisite course. The evaluation model, the difference between grant and session controls, and every condition type are explained where first used.
What makes it go faster: a Microsoft 365 tenant with Entra ID P1 or above, even a developer one, so you can build the policies alongside. Not required, and every policy is shown as JSON you can read without a tenant.
What this course does not cover: identity governance, privileged access management, and incident response to an identity compromise. Conditional Access is the enforcement point, and those are the disciplines either side of it.
Who this course is for
Anyone responsible for who gets into a tenant and under what conditions. There is no minimum experience and no gatekeeping: every concept is explained at first use, so you can start here whether you have never opened the Conditional Access blade or have been maintaining policies for years.
What you'll learn
Six modules, working from how a decision is reached to what to do when a change has already locked people out.
Key course takeaways
Course Resources - what comes with the modules
Every course carries a resources phase built for that course and no other. It is the part subscribers keep going back to long after they have read the modules once.
Things you need to know
What are the prerequisites for this course?
None beyond working familiarity with a Microsoft 365 or Entra ID tenant. You do not need prior Conditional Access experience: the course builds the evaluation model from first principles before it asks you to design anything.
Do I need a tenant to follow along?
No, though it helps. Every module includes portal paths and checks you can run against a real tenant, and the reasoning stands on its own if you are reading without one.
What licensing does this assume?
Conditional Access requires Microsoft Entra ID P1. Some capabilities covered here need P2, Intune, or Microsoft 365 E5, and the course says so at the point each one appears rather than assuming you have everything.
Is this course current?
Every technical claim was verified against Microsoft's documentation at the time of writing. Conditional Access moves, and several capabilities covered here were in preview, so the references module tells you how to check whether anything has changed rather than leaving you to find out.
Usage rights and disclaimer
Course materials are licensed for your individual use. You may apply everything you build here in your own environment and in client work. You may not redistribute the course content itself or resell it as training.
Policy examples, scenarios and figures are illustrative. Verify against your own tenant and against current Microsoft documentation before relying on any specific behavior, and treat the sign-in record as authoritative over any document, including this one.
Ridgeline Cyber is not affiliated with Microsoft. Product names are used descriptively.
End of Course Exam
Complete the course, then prove your skills under time pressure. Pass mark: 70. Earn your certificate with CPE credits.
One random scenario per attempt. Certificate issued on pass.