ExamFinch.com My Study

Study guide

10.3 Planning & Implementing Conditional Access Policies

Practice this exam

Microsoft 365 Administrator Expert MS-102

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 MS-102 Exam Facts & Blueprint 1.2 Registration, Retake & Renewal 1.3 Study Strategy & Using This Guide

2 Tenant Setup, Domains & Org Settings

2.1 Creating a Microsoft 365 Tenant 2.2 Implementing and Managing Domains 2.3 Configuring Org Settings: Security, Privacy & Profile

3 Service Health, Network & Software Updates

3.1 Monitoring Service Health & Notifications 3.2 Network Connectivity Insights 3.3 Configuring & Monitoring Software Updates

4 Adoption, Usage & Microsoft 365 Backup

4.1 Monitoring Adoption & Usage 4.2 Configuring & Managing Microsoft 365 Backup

5 Users, Contacts, Groups & Shared Mailboxes

5.1 Creating & Managing Users Including External Users 5.2 Creating & Managing Contacts 5.3 Managing Microsoft 365 Groups & Shared Mailboxes

6 Licensing & Bulk User Management

6.1 Managing & Monitoring Microsoft 365 Licenses 6.2 Bulk User Management with Graph & Entra PowerShell

7 Roles, Admin Units & Privileged Identity Management

7.1 Implementing & Managing Roles in M365 & Entra ID 7.2 Managing Permissions for Defender XDR, Purview & Workloads 7.3 Managing Delegation with Administrative Units 7.4 Managing Entra ID Roles in PIM

8 Identity Synchronization with Entra Connect

8.1 Preparing for Identity Synchronization & IdFix 8.2 Directory Sync with Entra Connect Sync & Cloud Sync 8.3 Monitoring Sync with Entra Connect Health 8.4 Troubleshooting Synchronization

9 Authentication, SSPR & Password Protection

9.1 Implementing & Managing Authentication Methods 9.2 Self-Service Password Reset (SSPR) 9.3 Microsoft Entra Password Protection 9.4 Investigating & Resolving Authentication Issues

10 Identity Protection, Conditional Access & MFA

10.1 Planning for Identity Protection 10.2 Implementing Entra Identity Protection 10.3 Planning & Implementing Conditional Access Policies 10.4 Managing MFA with Conditional Access

11 Defender XDR Posture, Incidents & Threat Intelligence

11.1 Security Exposure Management & Secure Score 11.2 Incidents, Alerts & Advanced Hunting 11.3 Reviewing Defender XDR Reports 11.4 Defender Threat Intelligence

12 Defender for Office 365: Policies, Alerts & Investigation

12.1 Threat Policies & Rules in Defender for Office 365 12.2 Configuring Alert Policies 12.3 Investigating & Responding to Email Threats

13 Attack Simulation & Restricted Entities

13.1 Managing Attack Simulations & Training 13.2 Managing Restricted Entities & Blocked Users

14 Defender for Endpoint

14.1 Onboarding Devices to Defender for Endpoint 14.2 Configuring Endpoint Settings 14.3 Defender Vulnerability Management Dashboard

15 Defender for Cloud Apps

15.1 Configuring the App Connector for Microsoft 365 15.2 Defender for Cloud Apps Policies & Alerts 15.3 Interpreting the Activity Log 15.4 Cloud App Discovery

16 Purview Information Protection & Data Lifecycle

16.1 Sensitive Information Types 16.2 Retention Labels & Policies 16.3 Sensitivity Labels & Policies 16.4 Monitoring Label Usage: Content & Activity Explorer

17 Purview Data Loss Prevention

17.1 DLP Policies for Microsoft 365 Workloads 17.2 Configuring Endpoint DLP 17.3 Reviewing & Responding to DLP Alerts, Events & Reports

18 Final Review & Exam Strategy

18.1 Exam-Day Strategy & Question Handling 18.2 Final Review Checklist & Next Steps

10.3 Planning & Implementing Conditional Access Policies

Key Takeaways Explain This Topic AI

A Conditional Access policy is an if-then rule: if the assignments (users, cloud apps, conditions) match, then the access controls (grant with MFA/compliant device/etc., block, or session controls) apply

Assignments have three buckets — Users (include/exclude), Cloud apps or actions (include/exclude), and Conditions (user risk, sign-in risk, platforms, locations, client apps, authentication context)

Grant controls include Block, Grant with one or more of MFA/require compliant device/require hybrid joined/require approved app/require password change, with a toggle for requiring all vs any one selected control

Report-only mode lets you assess a policy's impact on real sign-ins before enforcing it; Microsoft also publishes reusable Conditional Access templates

Always exclude at least two break-glass / emergency access accounts from every Conditional Access policy to avoid tenant-wide admin lockout

Last updated: August 2026

Quick Answer: A Conditional Access (CA) policy is an if-then rule: if a sign-in matches the assignments (specific users, cloud apps, and conditions), then the access controls you defined apply — grant with MFA, require a compliant device, block, or apply session controls. CA replaces ad-hoc per-user MFA and Security Defaults with scoped, policy-driven access. Every CA policy should exclude break-glass accounts, and new policies should start in Report-only mode.

What Conditional Access Is

Conditional Access is Microsoft's recommended access-control mechanism for Entra ID. It evaluates signals at sign-in time and enforces controls before access is granted. The model is declarative: you describe the conditions that matter and the controls you want, and Entra ID applies them consistently across every sign-in.

The Two Halves of a Policy

Every CA policy has two halves — Assignments (the "if") and Access controls (the "then").

Assignments

Assignment What you configure

Users Include and/or exclude users, groups, directory roles. Exclude is critical for break-glass accounts.

Cloud apps or actions Include All cloud apps, specific apps, or user actions (like registering security info); exclude specific apps.

Conditions Optional but powerful: user risk, sign-in risk, device platforms, locations/named locations, client apps (browser, mobile, Exchange ActiveSync, legacy protocols), authentication context.

The Conditions blade is where Identity Protection integrates: user risk and sign-in risk appear here as selectable conditions, each with a Low/Medium/High threshold.

Access Controls

Control Options

Grant Block, or Grant with zero or more of: Require MFA, Require device to be marked compliant, Require hybrid Entra-joined device, Require approved client app, Require password change. A toggle lets you require all selected controls or any one of them.

Session Limited sign-in frequency, app-enforced restrictions, persistent browser session, sign-in frequency (re-auth interval), Continuous Access Evaluation.

The Grant control is the most common. "Grant with Require MFA" is the standard MFA policy. "Block" is absolute — use it for legacy authentication or high-risk scenarios. When you select multiple grant controls, the Require all the selected controls toggle enforces AND logic; Require one of the selected controls enforces OR logic.

Policy Mode: Report-Only vs On

Every CA policy has a Enable policy toggle with three states:

Report-only — the policy evaluates every sign-in and logs what it would have done, but does not enforce. Use this to assess impact before enforcement.

On — the policy is enforced.

Off — the policy is disabled.

Microsoft's documented best practice is to run every new policy in Report-only for a period, review the Conditional Access Insights and reporting workbook, and then flip to On . The workbook shows aggregate impact and per-user results, including which policies matched each sign-in.

Conditional Access Templates

Microsoft publishes a catalog of Conditional Access templates in the Entra admin center — pre-built policy definitions for common scenarios such as:

  • Require MFA for admins
  • Require MFA for all users
  • Block legacy authentication
  • Require compliant or Entra-joined device for admins
  • Securing security info registration (require MFA to register, only from trusted locations)
  • Require MFA for Azure management
  • Identity Protection starter policies (sign-in risk, user risk)

Templates are a starting point, not a finished policy — you still scope users, choose report-only, and exclude break-glass accounts before enabling.

Common Policy Patterns

Four patterns cover most real-world deployments:

Require MFA for all users — Include All users, exclude break-glass; All cloud apps; Grant with MFA. This is the baseline.

Require MFA for admins — Include directory roles like Global Administrator, Privileged Role Administrator, Security Administrator; All cloud apps; Grant with MFA. Layered on top of the all-users policy.

Block legacy authentication — Include All users; Conditions → Client apps → Other clients (Exchange ActiveSync legacy, IMAP, POP, SMTP); Grant → Block. Legacy auth cannot do MFA, so blocking it removes a major bypass.

Require compliant device for access — Include All users (or a group); All cloud apps or a sensitive app; Grant with Require device marked compliant (often combined with Require hybrid Entra-joined for domain-joined devices).

Conditions-to-Controls Reference

  • Condition Typical control
  • User risk = High Block, or require secure password reset (via Identity Protection user risk policy)
  • Sign-in risk = Medium/High Require MFA, or block at High
  • Location = untrusted Require MFA
  • Location = trusted (named location) Skip MFA (used as exclude)
  • Client apps = legacy protocols Block
  • Device platform = macOS/iOS/Android Require approved client app, require compliant device
  • Authentication context (step-up) Require MFA for sensitive actions within a session
  • Best Practices

Always exclude break-glass accounts. Keep at least two emergency-access accounts (cloud-only, no MFA, strong passwords) excluded from every CA policy. If a misconfigured policy locks out all admins, the break-glass accounts still sign in.

Start in Report-only. Assess impact before enforcement; review the workbook.

Scope least privilege. Prefer targeted include groups over All users where possible, and use exclude for exception users.

Use named locations. Define trusted office IP ranges as named locations so you can exclude them from MFA requirements.

Block legacy authentication. Always include a block-legacy-auth policy; legacy protocols cannot satisfy MFA and are the most common bypass.

Don't stack too many policies. A user can match multiple policies; Entra ID applies the most restrictive intersection. Too many overlapping policies make troubleshooting hard — use the Conditional Access What If tool and the sign-in logs to see which policies matched.

Naming convention. Name policies so the intent is obvious (for example, CA-001-Require-MFA-All-Users-ReportOnly ) — the sign-in logs show the policy name, and a clear name speeds triage.