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:
Wenn user X, on device Y, from location Z, wants to reach application A —
Dann mach B (erlauben / blockieren / MFA verlangen / Compliant Device fordern / …).
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-Kategorie | Examples |
|---|---|
| User / Gruppe | Individual users, security groups, all guest users, roles |
| Cloud App | Exchange, SharePoint, Teams, M365, AVD, Windows 365, individuelle SaaS-Apps |
| Standort | 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
Zugriffs-Kontrollen (Grant Controls)
- Block Access — harter Block
- Require MFA — zweiter Faktor erzwingen
- 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-Schutz
- Require Authentication Strength — z.B. phishing-resistentes MFA (FIDO2)
- Require Password Change — when user risk is elevated
Session-Kontrollen
- Sign-In Frequency — user must sign in again every X hours
- Persistent Browser Session — “Angemeldet bleiben” erlauben/verbieten
- App Protection via MCAS — Defender for Cloud Apps Session Restrictions
- Require Continuous Access Evaluation
Typical CA policies in practice
Klassische Baseline-Policies
| Policy-Name | WENN | DANN |
|---|---|---|
| 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-Typ = Guest | Nur spezifische Apps zugreifbar |
| High Risk Block | Sign-In Risk = High (P2) | Block + Password Change |
Break-the-Glass-Accounts: Bei jeder CA-Strategie mindestens 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.