2.2 Conditional Access Policies

2.2 Conditional Access Policies

Quick Answer: Conditional Access (CA) policies are if-then statements: if a user/app/condition matches, then block access or grant it only after controls such as MFA, authentication strength, or a compliant device. Use report-only and the What If tool before enforcing, and exclude break-glass accounts so you never lock out the tenant.

Conditional Access sits at the center of SC-500 identity security. PIM answers “who may elevate and when”; Conditional Access answers “under what real-time conditions may this identity reach this resource.”

Policy Building Blocks

Every enforceable policy needs at minimum:

1. A name
2. Assignments — users/groups (or workload identities) and target resources (cloud apps, user actions, authentication contexts)
3. Access controls — Grant (allow with requirements) or Block

Conditions refine when the policy fires. Session controls refine the post-grant experience.

Assignments: who and what

Evaluation timing tip: Policies that target roles or groups apply when a new token is issued. Adding a user to a group does not retroactively rewrite an already-valid token. For elevated roles, combining CA with PIM activation is a best practice so evaluation aligns with elevation.

Conditions: when the policy applies

All configured assignments in a policy are combined with logical AND. If multiple CA policies match a single sign-in, the user must satisfy all of them.

Access controls: grant and block

Block access is absolute for matching conditions—powerful and dangerous if scoped too wide.

Grant access can require one or more of:

• Multifactor authentication
• Authentication strength (built-in MFA, passwordless MFA, phishing-resistant MFA, or custom)
• Device marked as compliant (Intune)
• Microsoft Entra hybrid joined device
• Approved client app / app protection policy
• Password change
• Terms of use
• Custom controls

When multiple grant controls are selected, administrators choose:

• Require all the selected controls (AND — default)
• Require one of the selected controls (OR)

Enforcement order (conceptual): session details are collected (including for report-only policies); then enabled policies enforce. Block stops immediately. Grant requirements are prompted in a defined order (MFA, compliant device, hybrid join, approved client, app protection, password change, terms of use, custom controls). After grants succeed, session controls apply.

Session controls

Session controls limit what happens after sign-in is allowed:

• App enforced restrictions (Exchange Online / SharePoint Online limited experience)
• Conditional Access App Control via Microsoft Defender for Cloud Apps (block download, monitor sessions, force labeling)
• Sign-in frequency (how often reauthentication is required)
• Persistent browser session
• Continuous access evaluation customization / resilience defaults

Report-Only Mode and the What If Tool

Safe rollout pattern for SC-500 design questions:

1. Build the policy in report-only
2. Use What If for break-glass, executives, contractors, and mobile-only users
3. Review sign-in logs for would-block / would-require-MFA outcomes
4. Switch to On during a controlled window
5. Keep exclusions minimal and documented

Break-Glass Accounts

Emergency access (break-glass) accounts prevent total lockout if CA, MFA provider outage, or misconfiguration blocks all admins.

Exam expectations:

• Create at least two cloud-only emergency accounts with Global Administrator
• Use long, complex passwords stored offline in a secure process (or other resilient secret storage)
• Exclude them from Conditional Access policies that could prevent emergency sign-in
• Monitor sign-ins aggressively (alert on any use)
• Do not use them for daily administration (pair with PIM for normal admins)

If every Global Administrator is subject to a broken “require compliant device” policy and no one has a compliant device path, the tenant is locked. Break-glass exclusions are the safety valve.

Common Policies You Should Recognize

Workload Identities and CA

Modern tenants also protect apps and service principals. Policies can target workload identities for risky sign-ins or location anomalies. For SC-500, know that CA is not only for human users—machine identities are part of the attack surface and can be brought into the same policy model when licensed/configured.

Interaction with PIM and Authentication Strength

• PIM limits standing privilege; CA limits sign-in path quality
• On activation, requiring MFA in PIM complements CA requiring MFA or authentication strength at token issuance
• Authentication strength is a CA grant control that specifies allowed method combinations (for example, only FIDO2 / Windows Hello for Business / certificate-based MFA for phishing-resistant)

SC-500 Scenario Walkthrough

Scenario: Contoso wants admins to use phishing-resistant methods for Microsoft Admin Portals, all users to use MFA for Office 365, and no policy to lock out emergency accounts.

Design:

1. Policy A — Users: admin directory roles; Target: Microsoft Admin Portals; Grant: phishing-resistant authentication strength; Exclude: break-glass group
2. Policy B — Users: all users; Exclude: break-glass; Target: Office 365; Grant: MFA
3. Deploy both as report-only, validate with What If for a GA, a standard user, and a break-glass account
4. Enable Policy B, then Policy A after impact review
5. Keep day-to-day GA rights in PIM eligible assignments so elevation and strong CA combine

Common Exam Traps

1. Multiple policies stack — satisfying MFA on one policy does not skip a second policy that also requires a compliant device.
2. Report-only ≠ off — it still evaluates and produces reports; enforcement is what changes when you set On.
3. Exclude break-glass — a frequent correct answer when the risk is admin lockout.
4. Block all locations except trusted without planning remote work / break-glass is a classic misconfiguration story.
5. Assignments vs conditions vs controls — “who” is assignment; “sign-in risk” is condition; “require MFA” is grant control.

Conditional Access is the real-time gate. The next section deepens the authentication methods and strengths those grant controls depend on—MFA, passwordless, and phishing-resistant options.