Conditional Access building blocks

What goes into a Conditional Access policy, how policies combine, and the baseline set most tenants should have.

Fits on one A4 page. Checked 8 Oct 2026.

Assignments: who and what

Users: all users, users and groups, directory roles, guests and external users. Always exclude break-glass accounts.
Target resources: cloud apps, user actions (register security info, register or join devices) or an authentication context.
Network: include or exclude named locations, such as trusted IP ranges or countries.

Conditions: when

User risk and sign-in risk (Entra ID P2)
Device platforms: Windows, macOS, iOS, Android, Linux
Client apps: browser, mobile and desktop apps, Exchange ActiveSync and other legacy clients
Filter for devices: rules on device properties
Authentication flows: device code flow and authentication transfer

Grant: what's required

Block access
Require MFA or a specific authentication strength
Require compliant device or hybrid joined device
Require app protection policy
Require password change (with user risk)
Terms of use

Within one policy, choose whether all or one of the selected controls is needed.

Session: how long and how much

Sign-in frequency: how often users re-authenticate. "Every time" for sensitive actions.
Persistent browser session
App enforced restrictions: browser-only access in SharePoint and Exchange
Conditional Access App Control: session control through Defender for Cloud Apps
Continuous access evaluation settings

How policies combine

Every policy that applies to a sign-in is evaluated. There's no order or priority.
Block wins. If any applicable policy blocks, access is blocked.
Otherwise the user must satisfy the grant controls of every applicable policy.
Report-only policies are evaluated and logged but never enforced.
Exclusions beat inclusions: an excluded user isn't in scope, whatever else the policy includes.

A baseline set

Policy	Users	Resources	Control
Block legacy authentication	All	All	Block (client apps: Exchange ActiveSync, other)
MFA for everyone	All	All	Authentication strength: MFA
Phishing-resistant MFA for admins	Admin roles	All	Authentication strength: phishing-resistant
Protect security info registration	All	User action: register security info	MFA, or a trusted location
Block device code flow	All	All	Block (authentication flows: device code)
Compliant device for corporate apps	Staff	All or key apps	Compliant or hybrid joined device
Risk-based (P2)	All	All	High user risk: secure password change. High sign-in risk: MFA

Exclude break-glass accounts from every policy, and test with report-only and What If before switching on. Check your own policies with the Conditional Access visualiser.