Skip to main content

Blog

What is a conditional access system? A guide for cloud desktop administrators

Conditional Access is the Zero Trust policy engine for Microsoft cloud services. Here's how it secures Windows 365 and Azure Virtual Desktop.

Microsoft Entra Conditional Access is the Zero Trust policy engine for Microsoft cloud services. At every sign-in, it evaluates user identity, device compliance, location, application, and real-time risk, then decides whether to grant access, block it, or limit what the session can do. Writing the policy is the easy part. Keeping it enforced correctly across Windows 365 and Azure Virtual Desktop is where things get complicated, and the failure modes are mostly silent.

Every Conditional Access policy is an if-then statement: if a user wants to access a resource, they must satisfy the conditions you set, or they're blocked. The difference from a static MFA toggle is real-time context. Session and device signals are evaluated on every access attempt. Entra ID P1 is the minimum license that includes Conditional Access; risk-based policies require P2 or Identity Protection. One important boundary: Conditional Access enforces after first-factor authentication completes. It is not a defense against pre-authentication attacks.

This guide is for IT admins running Windows 365 or Azure Virtual Desktop, and MSP operators securing dozens of client tenants. It covers what Conditional Access is, how it applies to Windows Cloud environments (Microsoft's portfolio of Windows 365 and Azure Virtual Desktop), the policies to deploy first, and the operational failures that catch experienced admins off-guard.

How does Conditional Access evaluate access requests?

Every authentication attempt passes through a three-stage evaluation.

What signals does Conditional Access collect?

Conditional Access aggregates signals from five core categories before making any access decision: user or group identity, application, device, location, and real-time risk.

Signal category

Examples

User/group identity

Group membership, assigned roles

Application

Which cloud or on-premises app is being accessed

Device

Compliance state, join type (Entra joined, hybrid joined, registered)

Location

Named locations, IP ranges, country/region

Real-time risk

Sign-in risk, user risk from Entra ID Protection

The five categories together give Conditional Access context-aware control without depending on network location alone.

How does policy evaluation work?

Policy evaluation runs in two phases. Phase 1 collects session details: network location, device identity, and the rest of the data needed for evaluation. Phase 2 enforces. If a block control is configured, the user is denied. If grant controls require MFA or a compliant device, access is allowed once the user satisfies them. Microsoft validates MFA before checking device state.

What access decisions can Conditional Access make?

Three possible outcomes:

  • Grant: access allowed when criteria are met (require MFA, require compliant device, or combinations).
  • Block: access denied when risk thresholds are crossed or conditions can't be met. Block overrides any grant control.
  • Session controls: access granted but behavior is limited within the session, including session control options for sign-in frequency, persistent browser configuration, and app-enforced restrictions.

The three-stage sequence is what makes Conditional Access a real-time control, not a one-time gate.

Why does Conditional Access matter now?

Identity-based attacks surged 32% in the first half of 2025, per the Microsoft Digital Defense Report 2025:

  • 97%+ of identity attacks are password spray or brute force attacks (Microsoft Digital Defense Report 2025).
  • 22% of all breaches start with credential abuse as the initial attack vector, ahead of vulnerability exploitation at 20% (Verizon 2025 DBIR).
  • 35% of cloud-related incidents in H1 2024 involved valid account abuse (CrowdStrike Threat Report, 2025).
  • 46% of compromised systems with corporate logins were non-managed devices hosting both personal and business credentials (Verizon DBIR Executive Summary, 2025).

Phishing-resistant MFA blocks more than 99% of identity-based attacks, per the Microsoft Defense Report (2025). A 2025 Forrester Total Economic Impact study commissioned by Microsoft quantified a 30% reduction in identity-related risk exposure through Conditional Access and identity protection.

The risk lives in the gap between having Conditional Access policies and having policies that actually enforce across your Windows Cloud environment.

How does Conditional Access apply to cloud desktops?

Generic Conditional Access guidance falls short for cloud desktops. Azure Virtual Desktop authentication targets its own Microsoft Entra application. Windows 365 has separate policy guidance. Each platform has its own enforcement surface, and the differences matter when you target policies.

Which apps does Azure Virtual Desktop use for Conditional Access?

Azure Virtual Desktop authentication touches three separate Microsoft Entra applications. Two are MFA targets. One is explicitly excluded.

Application

App ID

When it applies

Azure Virtual Desktop

9cdead84-a844-4324-93f2-b2e6bb768d07

Feed subscription, AVD Gateway authentication, diagnostics

Windows Cloud Login

270efc09-cd0d-444b-a71f-39af4910ec45

Session host authentication when SSO is enabled

Azure Virtual Desktop Resource Manager Provider

50e95039-b200-4007-bc97-8d5790743a63

Feed retrieval only. Never target with MFA.

A policy that targets only the Azure Virtual Desktop app misses the session host sign-in phase when SSO is active. Match policies between the Azure Virtual Desktop app and the Windows Cloud Login app. Configure sign-in frequency separately for each.

With single sign-on enabled, reauthentication runs through Conditional Access session controls, primarily MFA and sign-in frequency on the Windows Cloud Login app. Session lock matters too. When a user reconnects after a lock, Conditional Access reevaluates the policies. MFA and sign-in frequency can fire again on reconnect. Token expiry isn't required to trigger reauthentication.

How does Windows 365 handle Conditional Access?

Windows 365 Cloud PCs are provisioned as Microsoft Entra-joined or hybrid-joined devices and managed with Microsoft Intune. The Cloud PC itself appears in Intune as a managed device with its own compliance status.

For Conditional Access targeting, Windows 365 splits across three Microsoft Entra applications:

Application

App ID

When it applies

Windows 365

0af06dc6-e4b5-4f28-818e-e78e62d137a5

Portal access (retrieving Cloud PCs, Restart actions)

Microsoft Remote Desktop

a4a365df-50f1-4397-bc59-1a1564b8bb9c

SSO authentication to the Cloud PC (current)

Windows Cloud Login

270efc09-cd0d-444b-a71f-39af4910ec45

SSO authentication to the Cloud PC (taking over)

Match Conditional Access policies across all three. Microsoft warns that an upcoming change will move Cloud PC authentication from Microsoft Remote Desktop to Windows Cloud Login. Policies that target only one risk a breaking change when the migration completes.

Why do compliance checks work differently on AVD and Windows 365?

The two platforms evaluate device compliance against different things. Azure Virtual Desktop checks the device the user is connecting from. Windows 365 checks the Cloud PC itself.

In Azure Virtual Desktop, Conditional Access checks whether the connecting client device is compliant. That's the physical machine the user is working from.

In Windows 365, the compliance check evaluates the Cloud PC VM itself. The physical endpoint the user connects from is a separate concern.

That difference matters for BYOD scenarios and compliance reporting. In Azure Virtual Desktop, you assert trust in the endpoint. In Windows 365, the cloud desktop carries the trust assertion. Many enterprises run both, which means managing compliance considerations across both surfaces.

One Windows 365 gotcha: Cloud PCs don't support BitLocker. If you apply a physical-device compliance template to a Cloud PC policy without removing the BitLocker requirement, those Cloud PCs will be marked non-compliant. Conditional Access can then block them.

 

Which Conditional Access policies should you deploy first?

Deploy these in order. Each policy builds on the last. Always run new policies in report-only mode before enforcement.

  1. Require MFA for all Windows 365 and Azure Virtual Desktop users. Target the correct app IDs. Exclude break-glass accounts. Disable legacy per-user MFA for Entra-joined session host VMs.
  2. Require compliant device, hybrid joined, or MFA. Use OR logic for mixed environments where not all devices are Intune-enrolled. This avoids hard blocks while enforcing strong authentication.
  3. Set sign-in frequency. Use periodic reauthentication for managed devices. Configure sign-in frequency separately for the Azure Virtual Desktop app and the Windows Cloud Login app.
  4. Disable persistent browser sessions for unmanaged devices. Pair with shorter sign-in frequency as a combined session control set.
  5. Location-based restrictions with named locations. Block or require step-up authentication from outside trusted corporate IP ranges. Review the Conditional Access Insights workbook and audit for IPv6 impact before enforcing.
  6. Sign-in risk policy (requires Entra ID P2). This is where P2 licensing pays for itself. Require MFA or block at medium-and-above risk levels. Reserve "every time" reauthentication for high-risk scenarios only.
  7. App-enforced restrictions for unmanaged devices. Supported by Microsoft for Exchange Online and SharePoint Online to provide limited or read-only access.
  8. Conditional Access App Control via Microsoft Defender for Cloud Apps. For apps outside the Exchange and SharePoint scope, use Defender for Cloud Apps session policies to block download, cut, copy, and print of sensitive documents.

Start with MFA and break-glass coverage. Layer compliance and risk-based controls on top.

What Conditional Access failures don't show up in documentation?

At scale, Conditional Access breaks in predictable ways. These failure patterns are consistent with Microsoft's troubleshooting guidance.

Silent MFA bypass

A new host pool group gets created but never added to the Conditional Access policy scope. Users access Azure Virtual Desktop without an MFA prompt. No error surfaces. No alert fires. Access appears normal. The security control appears active. You find out only when you go looking.

Intune-enrolled VMs that evaluate as unmanaged

Devices can appear enrolled in Intune and receive configuration while still failing Conditional Access device-based evaluation. Compliance state or device records may not be evaluated the way you expect. The visible enrollment state in Intune can imply everything is fine, even when access decisions say otherwise.

Sign-in logs show success, the connection fails

Conditional Access troubleshooting can show policies evaluating as expected while the actual connection issue occurs downstream of enforcement. That creates a diagnostic dead-end if you stop at the sign-in result.

Windows patches misread as Conditional Access failures

Authentication and connection problems in Azure Virtual Desktop don't always originate in policy. Other changes produce symptoms that look similar to Conditional Access blocks. Policy review alone can send troubleshooting in the wrong direction.

Exclusion scope creep

Broad exclusions solve access problems quickly. They also expand the portion of your environment that no longer receives the intended controls. Over time, the exclusion surface grows and the security model erodes.

App ID confusion at scale

Running both Windows 365 and Azure Virtual Desktop multiplies the targeting work. Each platform has its own apps, exclusions, and sign-in frequency settings. For MSPs managing many tenants, that surface explodes across dozens or hundreds of admin centers. Manual effort doesn't scale.

 

How does Conditional Access fit into a Zero Trust architecture?

Sixty-three percent of organizations have fully or partially implemented a Zero Trust strategy, per a 2024 Gartner Zero Trust survey of 303 security leaders. Conditional Access is the component that operationalizes it for Microsoft environments. The architecture aligns with NIST SP 800-207, the federal Zero Trust standard.

Zero Trust role

Microsoft implementation

Policy engine / policy administrator

Microsoft Entra Conditional Access

Signal sources

Microsoft Intune, Microsoft Defender for Endpoint, Entra ID Protection

Access control

Windows 365 and Azure Virtual Desktop session broker and authentication endpoints

Intune assesses device compliance and passes the status to Entra ID. Defender for Endpoint detects threat activity and classifies device risk. Intune can automatically mark risky devices as noncompliant based on those signals. Entra ID Protection feeds user risk and sign-in risk scores. Conditional Access reads all of these at authentication and renders a decision. Continuous Access Evaluation extends enforcement past initial authentication, revoking access mid-session when critical events occur instead of waiting for token expiry.

A policy requiring device compliance is worthless if Intune compliance policies are misconfigured. It's worthless if users authenticate through legacy protocols that Conditional Access doesn't evaluate. And it's worthless if the sync between Intune enrollment and Entra ID device records fails.

How do you keep Conditional Access working at scale?

Keeping the surrounding infrastructure accurate is what makes Conditional Access enforce correctly. Endpoints have to stay enrolled in Microsoft Intune. Compliance state has to hold when devices drift. Security baselines across Windows 365, Microsoft Intune, and Azure Virtual Desktop have to stay consistent. Silent enforcement failures have to surface before they become incidents. In Azure Virtual Desktop, that management surface spans Azure Portal, PowerShell, and Microsoft Intune.

Nerdio Manager for Enterprise automates the Microsoft Intune policy deployment and compliance management that Conditional Access policies evaluate against. It brings Windows 365, Microsoft Intune, and Azure Virtual Desktop into one management layer instead of forcing admins to piece together policy, compliance, and endpoint workflows across separate consoles.

What does Nerdio Manager add for Windows 365 Cloud PCs?

Nerdio Manager extends Microsoft Intune management for Cloud PCs. It backs up and restores Intune policies, which native Intune can't do. It speeds up app delivery. It gives admins a unified view of device and Cloud PC operations alongside Conditional Access dependencies. When an Azure Virtual Desktop or Windows 365 endpoint falls out of compliance, Nerdio Manager runs remediation scripts automatically. Conditional Access then evaluates against accurate compliance data, not stale or broken device records.

What does Nerdio Manager add for Azure Virtual Desktop?

Nerdio Manager adds patented auto-scaling, golden image lifecycle management, and host pool orchestration. As the environment scales up and down, the same Conditional Access policies stay aligned. New host pools and session host VMs inherit the established policy scope automatically. That closes one of the most common silent-bypass paths described earlier.

How does this change for MSPs?

MSPs face the same problem multiplied across every client tenant. Nerdio Manager solves it with a hub-and-spoke architecture. A master template containing security, identity, and compliance policies, including Conditional Access, can be pushed to client tenants from a single MSP console. Break-glass exclusion management, Secure Score tracking, and cross-tenant policy comparison run from one interface instead of logging into each tenant's admin center.

Microsoft validates this approach. The official Microsoft Intune Blog names Nerdio as a validated partner in the #IntuneForMSPs program. MSPs get the efficiency, visibility, and automation to operate Conditional Access at scale across every tenant.

What's the validated business impact?

Organizations using Nerdio Manager reduced the likelihood of a breach from 11% to 7%, an alleviated risk valued at $659K annually. That finding comes from an Enterprise Strategy Group economic validation study (a TechTarget division). Contributing factors included improved visibility, better patching strategy, and stronger policy management.

As one ESG study participant put it: "We explored AVD for half a year and were overwhelmed by the amount of data flowing at us. Within days of adopting Nerdio, we had a clear understanding of our entire AVD operation and had an actionable list of ways to make it run better and more cost-effectively."

Where should you start with Conditional Access?

If you're managing Windows 365, Azure Virtual Desktop, or both:

  1. Audit your current Conditional Access policies for correct app ID targeting. Confirm the Azure Virtual Desktop Resource Manager Provider app is excluded from MFA policies.
  2. Verify that your policy scope covers the relevant Azure Virtual Desktop resources and assignments. The silent bypass from a missing group assignment is the highest-risk, lowest-visibility failure mode.
  3. Run any new policy in report-only mode before enforcement. Review the Conditional Access Insights workbook for unexpected evaluation results.
  4. Check that your Intune compliance policies exclude BitLocker for Windows 365 Cloud PCs.
  5. If you're running both platforms, plan your policy architecture carefully and validate app targeting and exceptions across both environments.

Conditional Access is the right framework. What determines whether it holds in production is the accuracy of the Intune compliance infrastructure behind it, catching silent failures, and scaling policy management as your environment grows.

Want to see how Nerdio Manager automates the compliance infrastructure your Conditional Access policies depend on? Get a demo or start a free trial.

Frequently asked questions about conditional access systems

Ready to get started?