Blog
Conditional access for Windows 365 and Azure Virtual Desktop (how to configure Zero Trust policies)
Configure conditional access for Windows 365 and Azure Virtual Desktop with the right app IDs and policy design.
Table of Contents
- Why conditional access is your Zero Trust policy engine for cloud desktops
- Entra conditional access architecture
- The app ID reference table every cloud desktop admin needs
- Configuring conditional access for Azure Virtual Desktop
- Configuring conditional access for Windows 365
- Five policy design decisions that prevent coverage gaps
- How Nerdio Manager supports conditional access governance at scale
- Putting your conditional access policies into production
- Frequently asked questions about conditional access
A conditional access (CA) policy targeting only one application ID leaves entire authentication flows unprotected, and the gap won't show up until an auditor or an attacker finds it first.
This guide is for GRC leads, platform owners, and security architects responsible for enforcing Zero Trust controls across Windows Cloud, which encompasses both Windows 365 and Azure Virtual Desktop. Microsoft Intune and related identity infrastructure sit alongside as separate management and identity layers.
You'll get the authoritative app ID reference, platform-specific configuration steps, and the policy design decisions that close coverage gaps before they become audit findings.
Why conditional access is your Zero Trust policy engine for cloud desktops
For teams managing Windows Cloud environments, Conditional Access is the Zero Trust engine for access to all apps, whether legacy or modern, private or public. Enforcement kicks in after authentication. It then pulls signals from identity risk, device health, location, and application context.
Deploying conditional access across your cloud desktop estate is supported by published breach and compromise data. Verizon's DBIR 2025 says stolen credentials were involved in 31% of breaches. Microsoft's own MDDR 2024 shows that tenants using security defaults experience 80% fewer compromises than tenants without them. Microsoft-managed conditional access policies reduced compromise rates by 39% in the higher-baseline tenant population where they were deployed.
The most impactful controls you can deploy with minimal configuration are to enforce MFA, block legacy authentication, and require compliant devices, as described in Microsoft's baseline security measures.
Entra conditional access architecture
Formerly known as Azure Active Directory, Microsoft Entra ID is the current product name. Conditional access policies and configurations are functionally identical. Policy management now lives in the Entra admin center under Conditional Access. If you're still looking under the previous branding, you'll find a functionally identical experience.
Every conditional access policy consists of two parts: assignments and access controls. When multiple policies apply to a single sign-in, all applicable policies must be satisfied. The engine evaluates in two phases. Phase 1 collects session details for both enabled and report-only policies. These details include network location, device identity, and risk signals. Phase 2 enforces controls only for enabled policies.
Assignments you can evaluate
Assignments set the scope. You target users and groups. That includes directory roles and external identities. You also target cloud apps or actions and conditions tied to risk signals. User risk and sign-in risk require Entra ID P2. Other conditions include device context, named locations, client app type, and device filters.
Device platform data comes from unverified user agent strings that can be altered. Microsoft recommends pairing platform conditions with Intune compliance policies or block statements.
Grant and session controls
Grant controls determine what happens when all assignment conditions are met. You can block access entirely or grant it subject to requirements like MFA, device compliance, hybrid join, or app protection policies.
Session controls limit the experience within an authenticated session. Sign-in frequency determines how often users reauthenticate. Token protection binds tokens cryptographically to the issuing device. This prevents replay attacks.
For cloud desktops, a device compliance grant control applied to Windows 365 or Azure Virtual Desktop sessions evaluates the access device. The access device is the physical endpoint initiating the connection.
Licensing requirements
Every user targeted by conditional access policies must hold an Entra ID P1 or higher license. Risk-based policies require Entra ID P2. Microsoft 365 E3 includes P1; Microsoft 365 E5 includes P2. Office 365 plans (E1/E3/E5) include only Entra ID Free and carry no conditional access capability at all. Windows 365 Enterprise explicitly requires Entra ID P1. That makes conditional access a practical consideration for those deployments.
For device compliance as a grant control, an Intune license assigned to the user is required. Device-only Intune licenses do not include conditional access rights. Conditional access requires Entra ID P1 or P2 licensing. Nerdio Manager for Enterprise includes Windows 365 license tracking and user assignment features.
These assignments, controls, and license tiers form the evaluation framework. Which application IDs you include determines whether your policies cover every authentication flow in your cloud desktop environment.
The app ID reference table every cloud desktop admin needs
This is the configuration detail behind many Windows 365 and Azure Virtual Desktop conditional access misconfigurations. Conditional access for Windows 365 and Azure Virtual Desktop is configured in Entra ID by targeting specific enterprise applications with an Application (client) ID. Targeting the wrong ID, or omitting one, creates either over-blocking or a silent security gap.
| App name | App ID | When enforced |
| Azure Virtual Desktop | 9cdead84-a844-4324-93f2-b2e6bb768d07 | User subscribes to Azure Virtual Desktop, authenticates to Azure Virtual Desktop Gateway |
| Microsoft Remote Desktop | a4a365df-50f1-4397-bc59-1a1564b8bb9c | Client application authentication |
| Windows Cloud Login | 270efc09-cd0d-444b-a71f-39af4910ec45 | SSO authentication to session host (only when SSO is enabled) |
| Windows 365 | 0af06dc6-e4b5-4f28-818e-e78e62d137a5 | Cloud PC list retrieval, restart, lifecycle actions |
MFA should never be applied to this app: AVD Azure Resource Manager Provider (50e95039-b200-4007-bc97-8d5790743a63). This app retrieves the user feed only. Conditional Access for Azure Virtual Desktop MFA is applied by targeting the "Microsoft Azure Virtual Desktop" enterprise app.
The Azure Virtual Desktop web client (a85cf173-4192-42f8-81fa-777a763e6e2c) appears in sign-in logs. Microsoft's guidance for Azure Virtual Desktop focuses on targeting the Azure Virtual Desktop cloud app in Conditional Access policies rather than the web client app ID.
If Azure Virtual Desktop, Microsoft Remote Desktop, or Windows Cloud Login don't appear in the CA app picker, a common cause is that these enterprise applications are not yet provisioned in your tenant. Deploying a host pool or running the Azure Virtual Desktop quickstart can trigger provisioning of the related enterprise apps. Nerdio Manager includes Conditional Access policy management features such as policy state selection and configuration drift views.
Configuring conditional access for Azure Virtual Desktop
Azure Virtual Desktop authentication has two touchpoints that conditional access can enforce:
- Service authentication - when the user subscribes to the feed and connects to the Azure Virtual Desktop Gateway
- Session host authentication - when the user signs in to the VM itself
A policy targeting only the control plane does not protect session host access. The three policies below cover both touchpoints and add a baseline block for legacy authentication.
Policy 1: control plane MFA
Target the Azure Virtual Desktop app. Assign the Azure Virtual Desktop user security group. Under client apps, select Browser and Mobile apps and desktop clients. The grant control is typically set to require MFA, optionally combined with device compliance.
Policy 2: session and SSO MFA
Target Microsoft Remote Desktop (a4a365df) and Windows Cloud Login (270efc09). Apply the same user group and MFA grant control.
One approach is to match the sign-in frequency interval to Policy 1, but note Microsoft's recommendation to configure sign-in frequency for Windows Cloud Login separately from the Azure Virtual Desktop app, since the “Every time” option is only supported for Windows Cloud Login when SSO is enabled.
Policy 3: block legacy authentication
Target all Azure Virtual Desktop app GUIDs. Under client apps, select Exchange ActiveSync clients and Other clients. The grant control is then set to Block access. >99% of password spray attacks use legacy authentication protocols, per Microsoft telemetry.
In practice, teams benefit from avoiding immediate enforcement for new policies. New policies are typically set to Report-only mode first. You can review sign-in logs for unintended blocks and use the What If tool to simulate policy evaluation against specific users, devices, and locations. Switching to On is usually done only after validation.
For Entra-joined session hosts, disable legacy per-user MFA for affected users, add the RDP property targetisaadjoined:i:1 via the host pool's Advanced RDP Properties tab, and exclude the Azure Windows VM Sign-In app from MFA policies.
Azure Virtual Desktop is managed through the Azure portal, PowerShell, and Microsoft Intune. In this context, Intune is part of the management surface, while the conditional access configuration itself remains in Entra ID.
Configuring conditional access for Windows 365
Windows 365 Conditional Access guidance includes the Azure Virtual Desktop and Windows Cloud Login app IDs in addition to its own primary app. Microsoft recommends three apps in every Windows 365 CA policy for consistent enforcement across the Cloud PC portal, gateway connection, and Cloud PC sign-in.
The admin portal side effect
When admins sign in to the Azure portal, Microsoft Intune admin center, or Microsoft 365 admin center, the sign-in flow uses Microsoft 365 and Entra ID authentication services. This also happens in tenants where Cloud PCs are not provisioned. A CA policy targeting the Windows 365 app can therefore affect those admin portal sign-ins. Report-only testing and validation of emergency access exclusions before enforcement help reduce that risk.
Device compliance: access device versus Cloud PC
Conditional access evaluates the physical endpoint the user connects from. The Cloud PC's compliance state is evaluated through Intune compliance policies assigned to the Cloud PC. For Cloud PCs, BitLocker is typically excluded from compliance policies.
Windows 365 Link: the two-policy requirement
If you are deploying Windows 365 Link devices, a second CA policy must protect the user action to register or join devices alongside the Cloud PC access policy. Windows 365 Link uses Entra ID authentication and must be joined to Entra ID and enrolled in Intune during setup.
Sign-in frequency differences for mixed-platform tenants
For Windows 365, Microsoft provides guidance on using Conditional Access sign-in frequency for relevant cloud apps, but specific recommendations should be based on the apps in your environment. For Azure Virtual Desktop, Microsoft recommends configuring sign-in frequency through Conditional Access session controls for the Azure Virtual Desktop cloud app. In tenants running both platforms, review sign-in frequency settings carefully because reauthentication behavior differs by app and sign-in flow.
These platform-specific differences in sign-in frequency, admin portal token behavior, and device evaluation mean that a policy set copied from Azure Virtual Desktop to Windows 365 requires adjustment. Without that adjustment, the policy set can over-block or leave gaps.
Five policy design decisions that prevent coverage gaps
1. Address the implicit-allow problem
The conditional access engine grants access for any scenario not explicitly handled by a policy. Every application should have at least one CA policy applied. To assert a defensible access control posture, you need to demonstrate that every authentication path is governed by an explicit policy.
2. Maintain emergency access accounts
Maintain at least two break-glass accounts excluded from all conditional access policies. Activity from these accounts is typically monitored and alerted on. A common CA-caused tenant lockout happens when an admin without an enrolled device enables "Require compliant device" and locks themselves out of the very Intune portal they need to fix the problem.
3. Integrate Privileged Identity Management with conditional access
Integrate Privileged Identity Management with Conditional Access so that role activation is evaluated against your access controls. This helps prevent privileged sessions from bypassing controls that govern standard user access.
4. Separate risk-based policies from baseline policies
For user risk, a common configuration is to set the condition to High and require password change for remediation. For sign-in risk, a common configuration is Medium to require MFA and High to block access. Do not combine user risk and sign-in risk conditions in a single policy. Risk-based policies require Entra ID P2.
5. Respect the per-tenant policy limit
Your tenant supports a maximum of 240 conditional access policies per tenant, including policies in report-only, on, or off states. Apps with the same resource requirements are often grouped into single policies. Naming conventions established early make policy sets easier to manage at scale.
These five decisions collectively move your conditional access posture from a set of individual policies to a governance framework. The gap between "we have CA policies" and "we can prove our CA policies cover every authentication path" is where audit findings live.
How Nerdio Manager supports conditional access governance at scale
Conditional access policies define the rules. Keeping those rules aligned across hundreds of policies, thousands of endpoints, and ongoing configuration changes is the operational challenge. Nerdio Manager for Enterprise adds Conditional Access policy management, tracks policy drift, and shows policy state in one console.
For Azure Virtual Desktop environments
Nerdio Manager manages the Intune device compliance policies that conditional access evaluates as grant controls. The policy approval workflow allows a second RBAC-assigned admin to review, approve, or deny Intune policy changes before deployment. That adds a second-review step before Intune policy changes are deployed.
Automatic policy backup captures policy state whenever a policy is edited. This applies whether the change is made through the Nerdio console or the native Intune console. CIS Hardened Images, available directly within Nerdio Manager for securing Azure Virtual Desktop during session host deployment, provide a pre-hardened baseline OS configuration and are managed separately from CIS Intune policies.
For Windows 365 environments
Nerdio Manager adds Intune policy backup and restore to Cloud PC lifecycle management. Managing Windows 365 means managing Intune, including the compliance policies, configuration policies, baselines, and application deployments that sit behind Cloud PC access. Admins can create, back up, and restore Intune policies through Nerdio Manager rather than rebuilding them manually after a deletion or bad change.
Nerdio Advisor adds Windows 365-specific planning and optimization signals, including right-sizing recommendations for Cloud PCs, license reclamation alerts for underutilized licenses, and Flex (formerly Frontline) license conversion opportunities. Nerdio Manager also provides Windows 365 insights such as active users, maximum concurrent usage, license health, device health, and connection quality monitoring for troubleshooting.
Policy drift detection across both platforms
Nerdio Manager tracks conditional access policy state and surfaces configuration drift. That gives admins a direct way to compare current configurations with the approved state, whether changes originate from the Nerdio console or the native Entra admin center.
Many enterprises run both Windows 365 and Azure Virtual Desktop. Nerdio Manager presents policy state, Intune policy backups, Cloud PC recommendations, and Microsoft Intune data across both platforms in one console, without additional monitoring agents.
Putting your conditional access policies into production
If you target only one app ID, you leave part of the authentication path outside policy scope. The app IDs, sign-in frequency behaviors, and policy design decisions documented here are what close that gap.
If you are running both Windows 365 and Azure Virtual Desktop, the policy consistency challenge across platforms is real. A management layer that tracks policy state, surfaces drift, adds approval workflows, and centralizes Intune policy backups across both platforms reduces the operational work that conditional access alone does not cover.
Get a demo to see how Nerdio Manager works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your own Azure tenant.
Frequently asked questions about conditional access
Resources
Learn more about Nerdio Manager
