Securing remote access to corporate resources has become a critical priority for organizations adopting Azure Virtual Desktop (AVD). While AVD provides a managed virtual desktop infrastructure, it also creates a potential entry point for attackers armed with stolen credentials. Conditional Access policies in Microsoft Entra ID provide the security controls needed to ensure that only authorized users, from trusted devices and locations, can access your virtual desktop environment.

In this article, we will explore how to implement Conditional Access for Azure Virtual Desktop, covering the unique authentication architecture of AVD, the specific application IDs you need to target, recommended policy configurations, and common pitfalls that can undermine your security posture. This guide serves as a companion to my video walkthrough where I demonstrate the portal configuration step by step.

Why Azure Virtual Desktop Requires a Different Approach

Before implementing Conditional Access for AVD, it’s essential to understand why standard “all cloud apps” policies don’t work as expected. Azure Virtual Desktop uses a dual authentication architecture that differs from typical SaaS applications.

The Two-Plane Authentication Model

When a user connects to Azure Virtual Desktop, two distinct authentication flows occur:

Control Plane Authentication: The user first authenticates to the AVD service itself. This is the gateway that manages session brokering, connection handling, and resource allocation. The control plane determines which host pools and application groups the user can access.

Data Plane Authentication: After the initial connection is established, the user authenticates to the actual session host. This is where the virtual desktop session runs, and where the user accesses applications and data.

This separation means that a Conditional Access policy targeting only the control plane won’t necessarily protect the session host access, and vice versa. For comprehensive protection, your policies must address both authentication flows.

Required Application IDs

To properly secure AVD with Conditional Access, you must target multiple application registrations:

Missing even one of these application IDs can result in users bypassing your security controls. I’ve encountered production environments where MFA was supposedly enforced, but users connected without it because the policy only targeted one application ID.

Planning Your Conditional Access Strategy

Before creating policies, establish clear security requirements for your AVD environment.

Key Questions to Answer

1. Who needs access? Define specific user groups rather than targeting all users
2. From where should access be allowed? Consider geographic restrictions
3. What device requirements apply? Managed devices, compliant devices, or any device
4. What authentication strength is required? MFA, passwordless, or certificate-based
5. How often should users re-authenticate? Session lifetime considerations

Recommended Policy Structure

For most organizations, I recommend implementing a layered approach with multiple policies:

Policy 1: AVD - Baseline MFA Requirement
├── Target: AVD Users group
├── Apps: All three AVD app IDs
├── Grant: Require MFA
└── Exclusions: Emergency access accounts

Policy 2: AVD - Compliant Device Requirement
├── Target: AVD Sensitive Data Users
├── Apps: All three AVD app IDs
├── Grant: Require compliant device + MFA
└── Conditions: All locations

Policy 3: AVD - Guest User Restrictions
├── Target: All guest and external users
├── Apps: All three AVD app IDs
├── Grant: Block access OR stricter controls
└── Conditions: Geographic restrictions

Implementing the Baseline Policy

Let’s walk through the essential configuration for a baseline AVD Conditional Access policy. For a visual demonstration of these steps in the Azure portal, watch my accompanying video.

Policy Configuration Overview

Name: Use a descriptive naming convention such as AVD - Require MFA and Compliant Device

Assignments – Users:

• Include: Specific security group (e.g., “AVD Users”)
• Exclude: Emergency access accounts (critical for break-glass scenarios)

Assignments – Target Resources:

• Select apps: Azure Virtual Desktop, Microsoft Remote Desktop, Windows Virtual Desktop

Conditions:

• Locations: Configure based on your geographic requirements
• Device platforms: Usually left unconfigured for broad coverage
• Client apps: Default settings (browser and mobile apps)

Grant Controls:

• Require multifactor authentication
• Require device to be marked as compliant (optional)
• Choose “Require all” or “Require one” based on security requirements

Session Controls:

• Sign-in frequency: 8-12 hours recommended for AVD

PowerShell Deployment

For organizations managing policies at scale, PowerShell provides a more efficient approach. Here’s an example using Microsoft Graph PowerShell:

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Application.Read.All"

# Define the AVD application IDs
$avdAppIds = @(
    "9cdead84-a844-4324-93f2-b2e6bb768d07",  # Azure Virtual Desktop
    "a4a365df-50f1-4397-bc59-1a1564b8bb9c",  # Microsoft Remote Desktop
    "5a0aa725-4958-4b0c-80a9-34562e23f3b7"   # Windows Virtual Desktop (Legacy)
)

# Get your AVD Users group
$avdUsersGroup = Get-MgGroup -Filter "displayName eq 'AVD Users'"

# Get your emergency access account
$breakGlassAccount = Get-MgUser -Filter "userPrincipalName eq '[email protected]'"

# Create the Conditional Access policy
$params = @{
    displayName = "AVD - Require MFA"
    state = "enabledForReportingButNotEnforced"  # Start in report-only mode
    conditions = @{
        users = @{
            includeGroups = @($avdUsersGroup.Id)
            excludeUsers = @($breakGlassAccount.Id)
        }
        applications = @{
            includeApplications = $avdAppIds
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("mfa")
    }
    sessionControls = @{
        signInFrequency = @{
            value = 8
            type = "hours"
            isEnabled = $true
        }
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Important: Always Start in Report-Only Mode

Never deploy a new Conditional Access policy directly to production in enforced mode. Microsoft provides three policy states:

Start with report-only mode for at least 3-5 days, review the sign-in logs to validate behavior, and only then switch to enforced mode.

Grant Control Decisions

The grant controls determine what users must satisfy to access AVD. Understanding the implications of each option is critical.

MFA vs. Compliant Device vs. Both

Require MFA Only:

• Pros: Works with any device, easy to implement
• Cons: Doesn’t validate device security posture
• Best for: BYOD scenarios, contractor access

Require Compliant Device Only:

• Pros: Ensures managed device with security policies
• Cons: Requires Intune enrollment, limits flexibility
• Best for: Corporate-owned device scenarios

Require Both (AND):

• Pros: Defense in depth, highest security
• Cons: May impact user experience, requires infrastructure
• Best for: Accessing sensitive data, regulated industries

Require Either (OR):

• Pros: Flexibility for users, balanced security
• Cons: Potential for weaker authentication path
• Best for: General productivity workloads

The AND vs. OR decision significantly impacts both security and user experience. For most AVD deployments, I recommend requiring MFA universally and adding compliant device requirements for accessing sensitive resources.

Session Controls and Sign-In Frequency

Session controls determine how long a user can remain authenticated before re-authentication is required.

Sign-In Frequency Considerations

For AVD specifically, sign-in frequency requires careful consideration:

An 8-hour sign-in frequency aligns with typical business hours while ensuring that overnight sessions require re-authentication the next day.

Persistent Browser Session

For AVD web client users, consider whether to allow persistent browser sessions. Disabling this ensures users must re-authenticate when they close and reopen their browser.

Handling Advanced Scenarios

Real-world AVD deployments often require more sophisticated policy configurations.

Scenario 1: Different Requirements for Internal vs. Guest Users

External collaborators accessing AVD should typically face stricter controls. Create separate policies targeting guest users:

# Policy targeting guest users with stricter controls
$guestParams = @{
    displayName = "AVD - Guest User Restrictions"
    state = "enabledForReportingButNotEnforced"
    conditions = @{
        users = @{
            includeGuestsOrExternalUsers = @{
                guestOrExternalUserTypes = "b2bCollaborationGuest,b2bCollaborationMember"
                externalTenants = @{
                    membershipKind = "all"
                }
            }
        }
        applications = @{
            includeApplications = $avdAppIds
        }
        locations = @{
            includeLocations = @("All")
            excludeLocations = @("AllTrusted")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "compliantDevice")
    }
}

Scenario 2: Location-Based Restrictions

If your organization operates in specific regions, block connections from high-risk countries:

1. Navigate to Entra ID > Security > Named locations
2. Create a named location for allowed countries
3. In your CA policy conditions, include “Any location” and exclude your trusted locations

Scenario 3: Different Host Pools with Different Security Requirements

Conditional Access doesn’t allow targeting specific AVD host pools directly. To implement differentiated security:

1. Create separate Entra ID security groups for each host pool’s users
2. Create corresponding CA policies targeting each group
3. Assign appropriate security controls per policy

For example:

• AVD-GeneralUsers → Standard MFA policy
• AVD-FinanceUsers → MFA + Compliant device + Location restrictions
• AVD-DevelopersUsers → MFA + Specific network locations

Common Pitfalls and How to Avoid Them

Pitfall 1: FSLogix Profile Container Access Issues

If you’re using FSLogix profile containers stored on Azure Files, Conditional Access policies can inadvertently block the session host from mounting user profiles. This occurs because the session host authenticates to Azure Files using the host’s identity, which may not satisfy your CA policy requirements.

Solution: Create a named location for your AVD subnet and exclude it from location-based restrictions, or exclude the session host service principal from applicable policies.

Pitfall 2: Forgetting the Legacy App ID

Organizations using the AVD web client may encounter issues if they only target the primary AVD app IDs. The legacy “Windows Virtual Desktop” app ID (5a0aa725-4958-4b0c-80a9-34562e23f3b7) is still used in some scenarios.

Solution: Always include all three app IDs in your target resources.

Pitfall 3: Locking Out Administrators

Aggressive CA policies without proper exclusions can lock out administrators, including the accounts needed to modify policies.

Solution: Always exclude at least one emergency access account from every CA policy. This break-glass account should have:

• Strong, unique password stored securely
• Phishing-resistant MFA (hardware key)
• Excluded from all CA policies
• Regular access verification testing

Pitfall 4: Not Testing in Report-Only Mode

Deploying directly to enforced mode can cause immediate, widespread access issues.

Solution: Use report-only mode for initial deployment, review sign-in logs extensively, then gradually enable enforcement.

Monitoring and Troubleshooting

Using Sign-In Logs

The Entra ID sign-in logs are your primary troubleshooting tool:

1. Navigate to Entra ID > Monitoring > Sign-in logs
2. Filter by Application: “Azure Virtual Desktop”
3. Click on a sign-in entry
4. Review the Conditional Access tab

This shows every policy evaluated, whether it applied, and the result (success, failure, or not applied).

Using the What If Tool

The What If tool simulates sign-ins without requiring actual user attempts:

1. Navigate to Entra ID > Security > Conditional Access
2. Click What If
3. Select a user and target application
4. Configure conditions (location, device platform, etc.)
5. Review which policies would apply

This is invaluable for testing policy changes before deployment.

Key Metrics to Monitor

Regularly review these metrics in your sign-in logs:

Hands-On Practice

Conditional Access configuration requires practice in a safe environment before production deployment. For hands-on experience with Azure identity and security, I recommend these labs on CloudLearn.io:

Creating your First Azure Virtual Desktop Solution

While not specifically Conditional Access, this lab covers secure access patterns for Azure resources that complement your CA policies.

For a complete walkthrough of building an AVD environment that you can then secure with Conditional Access, check out my previous video on Building Azure Virtual Desktop with Intune in a Cloud-Only Scenario.

Conclusion

Implementing Conditional Access for Azure Virtual Desktop is essential for securing remote access to your corporate resources. The dual authentication architecture of AVD requires targeting multiple application IDs, and the policy configuration must balance security requirements with user experience.

Key takeaways from this guide:

• Always target all three AVD application IDs (Azure Virtual Desktop, Microsoft Remote Desktop, Windows Virtual Desktop)
• Start with report-only mode and validate using sign-in logs before enforcing
• Exclude emergency access accounts from every policy
• Consider different policies for internal users vs. guests
• Monitor sign-in logs regularly and adjust policies as your environment evolves

Conditional Access is not a set-and-forget configuration. As your AVD environment grows and security requirements change, your policies must evolve accordingly.