Conditional Access: Plan & Build Policies

What is Conditional Access?

The IF/THEN model

Every CA policy has two halves:

IF  [user/group] accesses [cloud app/action]
    AND [conditions are met]
THEN [enforce controls]

IF: Assignments

Users and groups — who does this policy apply to?

• All users, specific groups, directory roles, guest users
• Exclude: break-glass accounts (emergency access), specific groups
• ⚠️ Always exclude at least one break-glass account from all blocking policies

Cloud apps or actions — what are they accessing?

• All cloud apps, specific apps (e.g., Azure portal, Exchange Online), or user actions (register security info, register devices)
• “All cloud apps” is the broadest scope — be careful with this + block

Conditions — what are the circumstances?

Condition	What It Checks	Example
User risk	ID Protection risk level (low/medium/high)	Require password change for high-risk users
Sign-in risk	Risk of this specific sign-in (low/medium/high)	Require MFA for medium+ risk sign-ins
Device platforms	iOS, Android, Windows, macOS, Linux	Require compliant device on Windows/macOS
Locations	Named locations (IP ranges, countries)	Block access from countries you don’t operate in
Client apps	Browser, mobile apps, desktop clients, legacy auth	Block legacy authentication protocols
Device state	Compliant, Entra Joined, Hybrid Joined	Require managed device for sensitive apps
Filter for devices	Device properties (model, OS, ownership)	Target policies to specific device types

THEN: Controls

Grant controls — requirements to allow access:

• Require MFA
• Require authentication strength (phishing-resistant, passwordless, etc.)
• Require compliant device (Intune)
• Require Entra Hybrid Joined device
• Require approved client app
• Require app protection policy
• Require password change
• Require terms of use acceptance

When multiple grant controls are selected: choose “Require one of the selected controls” (OR) or “Require all the selected controls” (AND).

Block — deny access outright. Use sparingly and always with exclusions.

💡 Exam tip: how multiple policies interact

CA policies are additive. If a user matches multiple policies, they must satisfy ALL of them.

• Policy A: requires MFA for Exchange Online
• Policy B: requires compliant device for all apps

A user accessing Exchange Online must satisfy both MFA AND compliant device.

Block always wins. If any matching policy blocks access, the user is blocked — even if other policies would grant access. This is why you must be careful with “All users” + “Block” policies.

Named locations

Named locations define trusted or untrusted network locations used in CA conditions.

Types:

• IP ranges — specify CIDR blocks (e.g., your office public IPs). Can mark as “trusted.”
• Countries/regions — select countries by name. Entra resolves location from IP geolocation.
• Compliant network locations — when using Global Secure Access, mark the GSA network as trusted

Common patterns:

• “Block access from all countries except [your operating countries]”
• “Require MFA when NOT on a trusted network”
• “Skip MFA from the corporate office IP range”

Report-only mode

Report-only mode lets you deploy a CA policy without enforcing it. The policy evaluates every sign-in and logs what WOULD have happened, but doesn’t actually block or require MFA.

Why this matters:

• Test new policies before enforcement — see how many users would be affected
• Check the sign-in logs → “Report-only: Success” or “Report-only: Failure”
• Validate that break-glass accounts are properly excluded
• Identify unexpected impacts (e.g., service accounts being blocked)

Workflow: Report-only → review logs for 1-2 weeks → fix issues → switch to On

ℹ️ Scenario: Anika builds a CA policy set for a client

Anika is setting up Conditional Access for a new client (200 users, Entra P2 licences). She follows a structured approach:

Policy 1 — Block legacy auth:

• IF: All users, All cloud apps, Client apps = Exchange ActiveSync, Other clients
• THEN: Block
• Exclude: break-glass accounts
• Deploy: Report-only → verify no legitimate legacy apps → switch to On

Policy 2 — Require MFA for all users:

• IF: All users, All cloud apps
• THEN: Require MFA
• Exclude: break-glass accounts, helpdesk service accounts
• Deploy: Report-only first

Policy 3 — Require phishing-resistant MFA for admins:

• IF: Directory roles (Global Admin, Security Admin, etc.), All cloud apps
• THEN: Require authentication strength = phishing-resistant MFA
• Exclude: break-glass accounts

Policy 4 — Block access from untrusted countries:

• IF: All users, All cloud apps, Locations = Any location EXCEPT [trusted countries]
• THEN: Block
• Exclude: break-glass accounts

Policy 5 — Require compliant device for sensitive apps:

• IF: All users, Target apps (SharePoint, Exchange), Device platforms = Windows, macOS
• THEN: Require compliant device
• Exclude: break-glass accounts, guest users

She deploys all policies in report-only mode first, reviews sign-in logs for two weeks, identifies a legacy scanning app blocked by Policy 1 (excluded it), then switches all policies to On.

CA policy templates

Entra provides pre-built CA policy templates for common scenarios:

Template	What It Does
Require MFA for admins	MFA for all admin directory roles
Require MFA for all users	MFA for everyone
Block legacy authentication	Blocks legacy auth protocols for all users
Require MFA for Azure management	MFA when accessing Azure portal, CLI, PowerShell
Require MFA for risky sign-ins	MFA when sign-in risk is medium or high
Require password change for high-risk users	Password reset when user risk is high
Require compliant or joined device	Device compliance or join status required

Templates create policies in report-only mode by default — review before enabling.

Break-glass accounts

Break-glass accounts (emergency access accounts) are critical for maintaining access if CA policies lock everyone out.

Best practices:

• At least 2 break-glass accounts
• Cloud-only (not synced from on-prem)
• Not tied to any individual
• Excluded from ALL CA policies
• Use long, complex passwords stored securely (not in password managers tied to Entra)
• Set up alerts when break-glass accounts sign in
• Test them regularly

💡 Exam tip: break-glass account question patterns

The exam frequently tests break-glass accounts. Common patterns:

• “An admin is locked out by a CA policy. How should they regain access?” → Break-glass account
• “What type of account should be excluded from all CA policies?” → Emergency/break-glass
• “A break-glass account should NOT use which authentication?” → Federated auth (it should be cloud-only to avoid on-prem dependencies)

Remember: break-glass accounts should be cloud-only, excluded from all CA policies, and monitored for sign-in activity.

🎬 Video walkthrough

🎬 Video coming soon

Conditional Access: Plan & Build — SC-300 Module 12

Conditional Access: Plan & Build — SC-300 Module 12

~14 min

Flashcards

Question

What is the IF/THEN model in Conditional Access?

Click or press Enter to reveal answer

Answer

IF (assignments): specific users/groups access specific cloud apps AND conditions are met (location, device platform, risk level, client app). THEN (controls): grant access with requirements (MFA, compliant device), block access, or apply session controls. Policies are additive — all matching policies must be satisfied.

Click to flip back

Question

What happens when multiple CA policies apply to the same sign-in?

Click or press Enter to reveal answer

Answer

Policies are additive — the user must satisfy ALL matching policies. If Policy A requires MFA and Policy B requires a compliant device, the user needs both. Block always wins — if any policy blocks, the user is blocked regardless of other policies.

Click to flip back

Question

What is report-only mode in Conditional Access?

Click or press Enter to reveal answer

Answer

Report-only mode evaluates the policy against every sign-in and logs the result (would it have blocked? would it have required MFA?) without actually enforcing it. Used to test new policies safely before switching to On. Check sign-in logs for 'Report-only: Success' or 'Report-only: Failure'.

Click to flip back

Question

What are the requirements for break-glass (emergency access) accounts?

Click or press Enter to reveal answer

Answer

At least 2 accounts, cloud-only (not synced from on-prem), not tied to any individual, excluded from ALL CA policies, long complex passwords stored securely, monitored for sign-in activity, and tested regularly. They're your safety net if CA policies lock everyone out.

Click to flip back

Question

What are named locations and how are they used in CA?

Click or press Enter to reveal answer

Answer

Named locations define trusted/untrusted networks by IP ranges (CIDR blocks) or countries. Used as conditions in CA policies — e.g., 'require MFA when not on a trusted network' or 'block access from countries outside our operating region.' IP-based locations can be marked as trusted.

Click to flip back

Knowledge Check

Knowledge Check

Anika creates a CA policy: IF All users access All cloud apps, THEN Block. She excludes the IT admin group but forgets to exclude break-glass accounts. What happens when she enables the policy?

ABreak-glass accounts can still sign in because they have Global Admin roleBThe policy automatically excludes Global AdminsCEntra ID prevents saving a policy that blocks all usersDBreak-glass accounts are blocked — the Global Admin role does not override CA policies

Check Answer

Knowledge Check

A company has two CA policies. Policy A: requires MFA for Exchange Online. Policy B: requires a compliant device for all cloud apps. A user on a non-compliant device tries to access Exchange Online. What happens?

AThe user must satisfy both MFA AND compliant device requirementsBThe user is prompted for MFA only (Policy A applies, Policy B doesn't apply to Exchange specifically)CThe user is blocked because the device isn't compliantDPolicy A overrides Policy B because it's more specific

Check Answer

Knowledge Check

Anika wants to test a new CA policy that blocks access from outside the UK before enforcing it. She needs to see which users would be affected without actually blocking anyone. What should she do?

AEnable the policy for a small test group firstBCreate the policy but leave it disabled, then check manuallyCUse the What If tool once and then enable the policyDDeploy the policy in report-only mode and review sign-in logs

Check Answer

Knowledge Check

A Conditional Access policy requires MFA for all cloud apps. Another policy blocks access from outside the country. An employee is inside the country and completes MFA. What is the combined result?

AAccess is blocked — the block policy always takes precedenceBAccess is granted — MFA was completed and the location condition is satisfiedCAccess is granted but MFA is required again due to policy conflictDThe policies cancel each other out and default access is granted

Check Answer

---

Next up: Conditional Access: Advanced Controls & Troubleshooting — master the What If tool, session management, continuous access evaluation, and authentication context.