Conditional Access
Microsoft’s rule-based access control system — “if …, then …”. Conditional Access evaluates signals (user, device, location, risk) and decides whether a sign-in is allowed, what conditions apply, or whether it is blocked. The heart of Zero Trust.
What is Conditional Access?
Conditional Access (CA) is a Policy-Framework in Microsoft Entra ID that decides at every sign-in whether and how access is granted. The logic always follows a simple pattern:
If user X, on device Y, from location Z, wants to reach application A —
Then do B (allow / block / require MFA / require a compliant device / …).
Conditional Access is therefore the heart of a modern Zero Trust architecture. Instead of treating users as simply in or out, every single access is judged in context.
The signals CA responds to
| Signal category | Examples |
|---|---|
| User / group | Individual users, security groups, all guest users, roles |
| Cloud App | Exchange, SharePoint, Teams, M365, AVD, Windows 365, individual SaaS apps |
| Location | Named locations (IP ranges), countries, known versus unknown networks |
| Device Platform | Windows, macOS, iOS, Android, Linux |
| Device State | Entra joined, compliant (Intune), hybrid joined, unmanaged |
| Client app | Browser, Mobile App, Desktop Client, Legacy Protocols (IMAP/POP) |
| Sign-In Risk (P2) | A real-time risk score (low, medium, high) based on machine learning |
| User Risk (P2) | An account compromise indicator from threat intelligence |
What CA can do in response
Access controls (grant controls)
- Block Access — hard block
- Require MFA — enforce a second factor
- Require Compliant Device — only from Intune-compliant devices
- Require Hybrid Joined Device — only from domain-joined devices
- Require Approved Client App — only from Microsoft apps (Outlook Mobile, Teams)
- Require App Protection Policy — app MAM protection
- Require Authentication Strength — e.g. phishing-resistant MFA (FIDO2)
- Require Password Change — when user risk is elevated
Session controls
- Sign-In Frequency — user must sign in again every X hours
- Persistent Browser Session — allow/block “Stay signed in”
- App Protection via MCAS — Defender for Cloud Apps Session Restrictions
- Require Continuous Access Evaluation
Typical CA policies in practice
Classic baseline policies
| Policy name | IF | THEN |
|---|---|---|
| MFA for everyone | All users, all apps, all locations | MFA required |
| Block Legacy Auth | Client app = IMAP/POP3/SMTP | Block |
| Admin-MFA-Always | User holds an admin role | MFA without a trusted-locations exception |
| Block countries | Sign-in from high-risk countries | Block |
| A compliant device for Microsoft 365 | Access to Exchange, SharePoint and OneDrive | An Intune-compliant device |
| Guest restriction | User type = guest | Only specific apps accessible |
| High Risk Block | Sign-In Risk = High (P2) | Block + Password Change |
Break-glass accounts: In every CA strategy, keep at least 2 admin accounts outside of every CA policy (an exclude list). Otherwise a faulty policy can lock the whole tenant out.
Conditional Access for AVD and Windows 365
Conditional Access matters particularly in DaaS scenarios — and has a few special cases there.
The two relevant applications in CA for AVD
- Azure Virtual Desktop (cloud app): controlling access to the AVD broker
- Azure Windows VM Sign-in (for Entra-joined session hosts): controlling the Windows sign-in within the session
These are independent — you can, for example, keep access to the AVD broker relaxed while making the Windows sign-in strict (MFA plus a compliant device).
Windows 365
For Windows 365, three cloud applications matter: Windows 365 for the end-user portal and the gateway, Azure Virtual Desktop, and — as soon as single sign-on is enabled in the provisioning policy — Windows Cloud Login for the sign-in to the Cloud PC itself. Microsoft recommends matching the policies across these applications; if you exclude one, you must exclude all of them. Depending on how they are provisioned, Cloud PCs are Entra joined or hybrid joined — the join type alone does not carry access control.
Worth noting: a policy targeting the Windows 365 application also affects administrator sign-ins to the Azure portal, Intune and the Microsoft 365 admin centre, because that sign-in flow requests a Windows 365 token in the background.
A best-practice pattern for DaaS
- Users with access to AVD or Windows 365 always protected with MFA
- External access allowed only from known countries
- Unmanaged devices: browser access only to Windows 365 and AVD — no desktop client download onto private devices
- Admin pools: additionally phishing-resistant MFA (a FIDO2 key)
CA-Patterns in DaaS Maps
DaaS Maps shows Conditional Access patterns for AVD, Windows 365 and the other DaaS platforms. For a conversation about CA design and Zero Trust strategy, you will find me on LinkedIn.