Built-in Security Mechanisms in Azure Virtual Desktop (AVD)
Azure Virtual Desktop (AVD) is a cloud-managed VDI service designed with numerous built-in security features. Network security is integrated into the architecture: AVD uses a Reverse Connect transport, meaning session host VMs do not need any inbound ports open to receive remote desktop sessions. Instead, both the client and the host initiate outbound TLS 1.2 connections to Azure’s AVD gateways, and the service brokers a session, greatly reducing exposure since no direct RDP port is listening on the internet. All traffic between the user’s client and the AVD service (and onward to the session host) is encrypted using TLS 1.2 with strong ciphers. The RDP session itself runs inside this secure tunnel, validated by certificates, ensuring that display, keystrokes, and data are protected in transit. This encryption in transit is enforced end-to-end by Azure and cannot be disabled, safeguarding against eavesdropping or man-in-the-middle attacks.
Authentication and access control are handled through Entra ID integration. Users must authenticate to Entra ID before accessing virtual desktops, allowing organizations to leverage modern authentication protections. Entra ID supports multi-factor authentication (MFA) and Conditional Access policies for AVD, so administrators can require additional verification or enforce sign-in conditions (like trusted devices or locations) for desktop access. AVD supports hybrid identity models as well – session hosts can be domain-joined to Active Directory (with accounts synced to Entra ID), or in a cloud-only configuration using Entra ID join for the VMs. In all cases, Entra ID is in the loop to broker connections, meaning features like Entra ID Conditional Access (device compliance, user risk, etc.) can gate AVD login. This ensures only authorized users under the right conditions can initiate sessions.
Isolation strategies in AVD span multiple layers. At the service level, AVD employs logical isolation—the broker, gateway, and other control plane components are multi-tenant Azure services that isolate each customer’s data and sessions. Microsoft manages these components in its cloud (under the Azure control plane), while the customer manages the session host VMs and their configuration. This shared responsibility model means Microsoft secures the AVD control plane (including keeping the gateway and broker infrastructure updated and hardened), and the customer focuses on securing their users, VMs, and Azure resources. On the session hosts, user sessions are isolated from each other by the Windows OS itself – each user gets a separate session environment with process and memory isolation. No user (without privileges) can access another user’s data in a multi-session host. Administrators should ensure standard users are not granted administrative rights on session hosts to maintain this isolation (more on this in best practices). Additionally, one can choose personal desktops (single-session) in AVD if stricter isolation per user is required, though at the cost of higher resource usage.
AVD’s built-in security includes encrypted connections by default, identity-centric access control, elimination of inbound attack surfaces, and separation of control plane and workload. Together, these mechanisms provide a secure foundation for virtual desktop deployments, even before any custom hardening is applied.
Generation 2 VMs with Trusted Launch Security Features
The AVD session host VMs in this scenario are Generation 2 Azure VMs with Trusted Launch enabled, bringing advanced platform security protections at the VM level. Generation 2 VMs use UEFI firmware instead of legacy BIOS and support features like Secure Boot and virtual TPM. With Trusted Launch, Azure automatically enables a UEFI Secure Boot policy on the VM. Secure Boot acts as a hardware root-of-trust that permits the VM to boot only bootloaders and OS kernel components that are digitally signed by trusted authorities. This prevents malicious bootkits or rootkits from installing themselves into the boot process. If any unsigned or tampered bootloader or driver tries to load at startup, Secure Boot will block it and the VM will refuse to boot, ensuring that only a trusted, untampered operating system instance runs. In practical terms, this thwarts attackers from persisting malware at the firmware or boot level – a foundational integrity protection.
Trusted Launch also provides a virtual Trusted Platform Module (vTPM) 2.0 to each VM. The vTPM is a virtualized cryptographic module that functions like a physical TPM chip, isolated from the VM’s own CPU and memory. It serves as a secure vault for cryptographic keys and measurements of the boot sequence. During boot, the vTPM records measurements (hashes) of the UEFI firmware, OS bootloader, and drivers. These measurements can be used for remote attestation – Azure can cryptographically verify via the vTPM that the VM booted with expected, untampered components. In other words, Trusted Launch VMs support boot integrity monitoring: Azure’s attestation service or Microsoft Defender for Cloud can query the vTPM to ensure the VM’s boot chain is healthy and has not been compromised. If Secure Boot is disabled or a boot integrity attestation fails, Defender for Cloud will flag it so administrators are alerted to potential malware at startup.
The presence of a vTPM also unlocks further security features: it allows enabling disk encryption (BitLocker) inside the VM to encrypt the OS and data disks with keys protected by the TPM. It also permits the use of Windows security features like Credential Guard and Virtualization-Based Security, which require a TPM and virtualization extensions. Generation 2 VMs with Trusted Launch have the necessary virtualization support to run these features, adding additional layers (like isolating LSASS process memory to protect credentials).
It’s worth noting that as of late 2024, Trusted Launch is the default security type for new Azure VMs that support it, underscoring its importance in Azure’s security strategy. This configuration (Gen2 + Trusted Launch) significantly hardens the AVD session hosts at the hypervisor and firmware level. It ensures that our Windows 11 hosts boot up in a known-good state (protecting against firmware-level malware) and that secrets and encryption keys are stored in a secure enclave (vTPM) not accessible to an attacker even if they gain user-level access on the VM. Overall, Gen2 VMs with Trusted Launch mitigate entire classes of attacks (bootkits, unauthorized kernel drivers, etc.) that could otherwise undermine the operating system security from below.
CIS-Hardened Windows 11 Images for Session Hosts
On top of the secure VM platform, the session hosts can be deployed using CIS-hardened Windows 11 images. These are Azure Marketplace images pre-configured according to the Center for Internet Security (CIS) Benchmarks for Windows 11. A CIS-hardened image applies a comprehensive set of security best practices and baseline configurations to the operating system. According to Microsoft and CIS, these images are “hardened to either a Level 1 or Level 2 CIS benchmark profile” and are designed to protect against unauthorized access, denial of service, and other cyber threats by eliminating common system vulnerabilities.
Key benefits of using a CIS-hardened Windows 11 image include:
- Secure default settings: Many of Windows’ default configurations are tightened. For example, password policies, account lockout thresholds, and audit settings are set to recommended secure values. Insecure protocols like LANMAN or NTLMv1 may be disabled, and modern TLS settings enforced. The Windows firewall is enabled with restrictive rules out of the box, and unnecessary services or features are turned off or removed, reducing the attack surface of the OS.
- Validated against benchmarks: CIS Benchmarks are consensus-driven guidelines developed by security experts across industries. By using an image that complies with these benchmarks, the environment aligns with known good practices and meets many compliance requirements. (Level 1 benchmark settings are those that should cause little to no user impact, whereas Level 2 are stricter settings for high-security environments, potentially at the cost of some functionality.) An image hardened to CIS guidelines ensures the OS is locked down in a standardized way from first boot, rather than relying on manual hardening after deployment.
- Reduced misconfiguration risk: Common misconfigurations that attackers exploit (like unrestricted RDP access, default admin accounts, or lax audit logging) are already addressed. For instance, the CIS image likely enforces Network Level Authentication (NLA) for RDP, ensures strong authentication for remote access, and configures audit policies to record security-relevant events. This means the AVD session hosts start in a state that is resilient against many attacks that prey on default settings.
Using CIS-hardened images in AVD gives the organization a head start on OS-level security compliance. It complements Azure’s platform security by hardening the software layer (the Windows 11 OS) running on the secure Gen2 VM. Administrators should still maintain these VMs (applying regular Windows updates and keeping configurations consistent), but the baseline enforcement from CIS greatly decreases the chances of overlooked security settings. In summary, the combination of Trusted Launch and CIS-hardened OS images means both the underlying VM and the guest OS are following best-in-class security practices from the ground up.
Securing FSLogix Profile Containers on Azure Files
User profiles in this AVD setup are managed with FSLogix profile containers, stored as VHDX files on Azure Files shares. This design centralizes user data and settings on a network share (Azure Files), rather than on the session host’s local disk, which has security advantages but also calls for secure storage configuration. Azure Files offers several features to ensure these profile containers are protected in transit and at rest, as well as accessible only to authorized entities.
Encryption at rest: All data in Azure Files is automatically encrypted using Azure Storage Service Encryption. This means that the FSLogix VHD(X) files containing user profiles are encrypted on disk using AES-256 encryption by default. The encryption is transparent – data is encrypted and decrypted by the service without user intervention, similar to how BitLocker protects a disk. Even if an attacker were somehow able to access the raw storage media in Azure (which Azure’s internal security prevents), they would only see encrypted data. Organizations can opt to use Microsoft-managed keys (default) or customer-managed keys for this storage encryption, but either way, profile data is protected at rest.
Encryption in transit: By default Azure Files requires secure transport. Only SMB 3.x connections with encryption are allowed when encryption-in-transit is enabled on the storage account (this setting is on by default for all file shares). SMB 3.1.1 supports AES-128 and AES-256 GCM encryption for file transfers, and Windows 11 (and Windows Server 2022+) will negotiate the strongest available cipher (AES-256-GCM) for SMB. In practice, when an FSLogix profile container is attached over the network, the SMB channel is encrypted end-to-end, preventing attackers from snooping on profile data as it travels between the session host VM and the Azure Files storage. If a client or OS did not support SMB encryption, Azure Files would reject the connection by policy, ensuring weaker connections aren’t even established. This guarantees that profile reads/writes (registry keys, user documents, etc.) are always transmitted securely over the network.
Access control and identity integration: Azure Files can integrate with Entra Domain Services or on-premises Active Directory for authentication, enabling NTFS access control lists (ACLs) on files and folders. In an AVD deployment, the Azure Files share holding FSLogix profiles is typically domain joined (either to an Entra DS instance or a traditional AD via Entra ID Connect). This allows you to apply Windows ACLs such that each user’s VHDX file is only accessible by that user (and administrators). For example, each profile container file might reside in a directory named after the user or have an ACL granting access only to the user’s AD security principal. The FSLogix agent on the session host uses the user’s credentials to access their profile VHD, so Windows will enforce the ACL and prevent other users from opening someone else’s VHD. Azure Files fully supports this model: it can join an AD domain and honor directory ACLs just like a Windows file server. This means the confidentiality of each profile is preserved – one user cannot read or tamper with another’s profile data. Additionally, the storage account can be configured with Azure RBAC as an extra layer (for example, requiring the session host’s managed identity or computer account to have a role to access the file share, in the case of Entra ID Kerberos authentication). Only the AVD session hosts and authorized users should have any access to the file share.
Network isolation: To further secure the profile storage, Azure Files supports Private Endpoints which map the storage service to a private IP in your Azure Virtual Network. In this AVD setup, the Azure Files share should be accessed via a Private Endpoint, ensuring that profile data traffic stays on Azure’s private network and is not exposed to the public internet. The storage account’s firewall can be configured to deny all public access, such that the only way to reach it is from the AVD host pool’s VNet (or via an express route/on-prem network if applicable). This network isolation means an attacker cannot even attempt to connect to the file share from an unknown IP – only the session hosts (or other allowed network locations) can reach the storage.
In addition, Azure Files provides features like Azure Backup integration and soft delete for file shares. Soft delete can preserve deleted VHDX files for a retention period, adding resilience against accidental or malicious deletion of profile containers. From a security perspective, it’s also important to monitor and manage the share: for instance, regularly auditing permissions and using Azure Monitor logs to track access to the file share. But overall, by using Azure Files with encryption in transit and at rest, AD-based authentication, and network controls, the FSLogix profile containers are well-protected. The design centralizes user data in a hardened storage service, rather than leaving it scattered on many VM disks, which allows for easier implementation of consistent security measures.
Native Azure Security Features Enhancing AVD Security
Beyond the AVD service and VM/storage configuration, Azure provides a rich ecosystem of security features that either enhance security by default or can be enabled to bolster the AVD deployment. The following Azure capabilities are critical in securing the environment and are recommended as part of a defense-in-depth strategy:
Identity and Access Management: Entra ID and Conditional Access
Entra ID is the identity backbone for Azure Virtual Desktop. Using Entra ID, administrators can enforce strong identity controls for all AVD users and admins. Multi-factor authentication (MFA) is one of the most effective defenses to prevent stolen credentials from being used. It is highly recommended (and often required) to enforce MFA for AVD logins. This can be achieved by requiring MFA in a Conditional Access policy for the Entra ID tenant. Every user connecting to AVD would need to complete a second factor (be it a text code, authenticator app prompt, or FIDO2 token) during sign-in, significantly reducing the risk of unauthorized access with just a password.
Conditional Access (CA) provides granular control over when and how users can access Azure Virtual Desktop. With CA policies, you can restrict AVD access to compliant or hybrid-joined devices, specific geographic locations, or through approved client apps. For example, a policy might allow only company-managed devices that meet certain compliance policies (like having antivirus and disk encryption) to initiate an AVD session. Another policy might block AVD access from foreign countries where your organization doesn’t operate. Conditional Access evaluates conditions like user risk (leveraging Entra ID Identity Protection), sign-in risk, device state, etc., before granting access. This ensures that even valid credentials cannot be used to log into a virtual desktop unless all requirements are satisfied. In essence, Entra ID and Conditional Access bring a Zero Trust approach to AVD logons: never trust, always verify each session launch.
Additionally, Entra ID enables modern authentication methods such as passwordless login (using Windows Hello or security keys) and can enforce policies like periodic password rotation and banned passwords. For administrators, Entra ID Privileged Identity Management (PIM) can be used to make role assignments (like AVD Tenant Admin or Subscription Owner) just-in-time and auditable, reducing standing administrative access. All authentication events and changes in Entra ID are logged (Entra ID sign-in logs and audit logs) and can be monitored for anomalies, providing insight into potential unauthorized attempts. Using Entra ID as the authentication gate for AVD thus leverages Microsoft’s cloud-scale security monitoring and control to protect the desktop environment.
Cloud Security Posture Management: Microsoft Defender for Cloud
Microsoft Defender for Cloud (formerly Azure Security Center) is a native Azure service that helps secure your resources by providing both security posture management and threat protection. Enabling Defender for Cloud for your subscription (and specifically for the Virtual Machines that serve as AVD session hosts) is a recommended step. Defender for Cloud will continuously assess the configuration of your AVD environment against known best practices and benchmarks. For example, it will check that your VMs have Secure Boot and vTPM enabled (since Trusted Launch is used) and flag if any are disabled. It will also recommend enabling the Azure Monitor agent and the Guest Attestation extension on Trusted Launch VMs to perform continuous boot integrity monitoring. All these recommendations roll up into a Secure Score, which gives a quantitative measure of your environment’s security posture and prioritizes the most critical fixes.
In addition to configuration checks, Defender for Cloud offers threat protection for Azure workloads. When the Defender for Cloud plan is enabled for servers, it deploys the Microsoft Defender for Endpoint agent (on Windows machines) which provides Endpoint Detection and Response (EDR) capabilities. This means the AVD session hosts will be monitored for suspicious activities or malware in real time. If a user accidentally runs malicious code or if an attacker somehow gains a foothold on a session host, Defender for Endpoint can detect behaviors like credential theft attempts, unusual script execution, or known malware signatures, and generate alerts. These alerts surface in Defender for Cloud with context and severity, so the security team can quickly investigate. The integration of vTPM also means Defender for Cloud can leverage attestation-based signals – for instance, if the VM’s boot attestation fails or if Secure Boot was turned off, you would get a security alert since that could indicate low-level compromise.
Defender for Cloud also includes vulnerability assessment and inventory features. It can scan the VMs (using Qualys or Defender’s built-in scanner) to find missing patches or misconfigurations at the OS level, complementing the CIS baseline with ongoing checks. Furthermore, it can assess the Azure resources around AVD (like storage accounts, networks) for issues – e.g., if the storage account with FSLogix profiles is misconfigured or lacking a private endpoint, it would flag that. By using Defender for Cloud, you benefit from continuous security oversight of the entire AVD stack and Azure resources, with actionable recommendations to harden the setup and active alerts for threat detection. It’s essentially a second set of eyes (powered by Microsoft’s security research) constantly watching over your environment.
Network Security: NSGs, Private Link, and Azure Firewall
A well-architected AVD deployment uses Azure network controls to restrict access and contain potential breaches. Network Security Groups (NSGs) are essential for filtering traffic at the network interface or subnet level. For each AVD session host subnet, NSG rules should be in place to allow only expected traffic and deny everything else. By default, because of AVD’s reverse connect, you typically do not need to allow any inbound internet traffic to the session hosts. NSGs can enforce that by blocking all inbound (except perhaps management traffic from a specific IP or Azure Bastion, if needed). Outbound NSG rules can also be used to restrict egress. For instance, session hosts generally only need to reach AVD service endpoints (which can be allowed via service tags) and perhaps Windows Update or management services. You might choose to block outbound internet access for arbitrary destinations to reduce the risk of malware communicating out from a host. This forces the VMs to only talk to known services or on-prem networks. NSGs provide a stateful firewall at no additional cost and are the first line of internal network defense.
To secure service access, Azure Private Link is leveraged for services like Azure Files (and any other PaaS services in use). As discussed, the Azure Files share for FSLogix is accessed via a private endpoint in the VNet. Similarly, if your AVD environment uses other Azure services (databases, web APIs, etc.), private endpoints can be used to ensure the session hosts reach those services over the Azure backbone rather than via public IPs. Private Link essentially extends the internal network to Azure services, eliminating exposure of service endpoints to the internet. This not only reduces the attack surface but also mitigates data leakage risk, since even if malware ran on a host, it couldn’t easily exfiltrate data to an external endpoint if internet egress is locked down – it would be constrained to internal/private endpoints.
For more advanced network control, an Azure Firewall or similar network virtual appliance (I personally prefer a virtual Sophos Firewall NVA) can be placed in the network path (for example, in a hub network in a hub-spoke topology). Azure Firewall is a managed firewall service that can inspect and filter traffic with high granularity. In an AVD scenario, Azure Firewall can be used to implement application-level outbound rules – for instance, only allow web traffic from session hosts to go to Microsoft update sites or specific SaaS applications, and deny all else. It also provides logging of all allowed/denied flows for audit purposes. Azure Firewall can work alongside NSGs: NSGs restrict traffic by IP/port, and traffic that is allowed can then be subject to Azure Firewall rules for deeper inspection. The AVD best practices recommend considering such egress restrictions: by default session hosts can reach any internet resource, so implementing network egress controls (via Firewall, proxy, or NVA) helps limit potential abuse. If using Azure Firewall, one should be careful to allow required endpoints (such as Azure Virtual Desktop service URLs, identity endpoints, etc.) – Microsoft publishes documentation on required network URLs/ports for AVD.
Network segmentation is also important within Azure: the AVD subnet should be isolated from other sensitive subnets except where necessary. For example, if the session hosts need to communicate with an internal licensing server or domain controller, NSG rules should limit that traffic only to the specific ports/IPs needed. Using Private Endpoints and service tags, you can often avoid needing the session hosts to have any broad network access. Also consider integrating AVD networks with on-premises networks via VPN/ExpressRoute carefully, applying firewall rules on-prem as well to limit what AVD machines can reach in the corporate network. In summary, a combination of NSGs for basic ingress/egress filtering, Private Link for service access, and Azure Firewall for comprehensive traffic governance will significantly enhance the network security of the AVD deployment.
Governance: Azure Policy and Bicep
Azure provides governance tools like Azure Policy and Bicep to enforce and automate security configurations across resources. Azure Policy can be used to ensure the AVD environment and its components remain compliant with your organization’s security standards. For example, you can apply built-in policies or custom policies to:
- Enforce resource configuration: Ensure that all session host VMs have Trusted Launch enabled (audit or deny creation of any VM that isn’t a Gen2/Trusted Launch). Ensure that only approved VM SKU sizes are used (maybe disallowing any unsupported ones). You can also require that Azure Disk Encryption is enabled on the VM disks if you choose to layer guest-level encryption on top of platform encryption.
- Storage and network rules: Require that the storage accounts (for FSLogix) have Secure Transfer (HTTPS) enabled and disallow public network access (so someone doesn’t accidentally disable the private endpoint requirement). Audit that a private endpoint exists for the storage. Enforce that any Azure Storage uses customer-managed keys if that’s a policy. Similarly, ensure NSGs are present on subnets, and maybe use policies to restrict open ports. Azure Policy has many built-in definitions like “NSGs should be applied to subnets” or “Public network access should be disabled for Storage Accounts,” which can directly apply here.
- Compliance standards: Map to standards like CIS or Azure Security Benchmark. Microsoft publishes an Azure security baseline for Azure Virtual Desktop which is a set of recommendations; these are often implemented as Azure Policy initiatives that you can assign to your subscription. By assigning relevant policies, you get a compliance view and can even enforce settings. For instance, an Azure Policy can detect if a VM is not on a specific allowed image (ensuring only your CIS-hardened image is used).
To ensure consistent deployment and reduce configuration drift, use Bicep, Azure’s declarative Infrastructure-as-Code (IaC) language. With Bicep, you can define reusable templates that deploy AVD components (like host pools, application groups, session hosts, networks, and storage) alongside Azure Policy assignments. This ensures that every deployment adheres to your organization’s security and configuration standards from the start.
For example, a Bicep template could:
- Deploy networking resources such as VNets, subnets, and NSGs with the required configuration.
- Create storage accounts for FSLogix with policies enforced to block public access and require HTTPS.
- Assign Azure Policies to enforce tagging, encryption standards, and security baselines.
- Configure RBAC roles (e.g., assigning an “AVD Operators” Entra ID group the Desktop Virtualization Contributor role on the AVD resource group).
Using Bicep in combination with Azure Policy supports a policy-as-code approach. This ensures new resources are deployed securely and consistently while enabling automated compliance at scale. It also simplifies auditing, allows version control, and makes it easier to iterate and improve governance over time.
Role-Based Access Control (RBAC)
Azure’s Role-Based Access Control is fundamental to restricting administrative access in the AVD environment. With RBAC, you grant permissions to Azure resources based on roles, ensuring each administrator or service has the minimum privileges necessary (principle of least privilege). There are built-in RBAC roles specific to Azure Virtual Desktop – for instance, Desktop Virtualization Reader, Contributor, Admin roles – that can be assigned to allow management of AVD host pools, application groups, and session host VMs without over-provisioning someone as a full Subscription Owner. For example, the team that publishes applications to AVD can be given a role on the AVD application group resource that lets them add or remove app assignments, but they wouldn’t automatically have rights to modify the virtual network or storage account. This separation prevents someone from inadvertently or maliciously altering critical settings unrelated to their job function.
For the session host VMs themselves (which are Azure VMs), use RBAC to control who can initiate start/stop, who can RDP login (Entra ID login can control VM login if Entra ID Join is used), and who can manage the VMs. You might have an “AVD VM Administrators” group that has Virtual Machine Contributor rights on those VMs for troubleshooting, distinct from the team that manages user access. Just-in-time elevation can be implemented using Entra ID PIM for these roles, so that no one has standing admin access to the VMs unless needed (this ties into best practices below).
On the storage side (Azure Files), RBAC can also be applied to the storage account: Azure has roles like Storage File Data SMB Share Contributor which, when Entra ID authentication is in use for Azure Files, control who can read/write in the file share. If using Active Directory authentication for Azure Files, access is mostly controlled by NTFS ACLs as mentioned, but you still want to restrict who can alter the storage account configuration or retrieve storage account keys. Use Azure RBAC to restrict the management of the storage account to storage admins only – for instance, there’s no need for an AVD app admin to have access to the storage keys or file share settings. By compartmentalizing roles (AVD service management, VM management, storage management, network management), you reduce the risk that a compromise of one admin account can impact the entire environment.
Azure RBAC also provides an audit log of role assignments and changes, which is useful for compliance. It’s a good practice to routinely audit who has what roles assigned, and remove any unnecessary privileges. Integrating Entra ID PIM as mentioned ensures that high-impact roles (like subscription contributor or user access administrator) are only active when absolutely needed, and each activation is logged and can require MFA. In short, RBAC is used to limit both the scope and duration of administrative access, thereby lowering the chances of human error or insider threats affecting AVD security.
Best Practices for Further Securing the AVD Environment
Finally, beyond the built-in features and configurations already discussed, here are additional best practices and recommendations to further secure the Azure Virtual Desktop deployment. These practices help achieve a layered defense and address operational security aspects:
- Enable Just-In-Time (JIT) VM Access for Administration: Even though AVD negates the need for inbound RDP to users, administrators may occasionally need to log directly into session hosts (for maintenance, offline troubleshooting of FSLogix, etc.). Using Azure’s JIT VM access (part of Defender for Cloud) is recommended for these cases. JIT access keeps management ports (e.g. RDP on 3389) closed by default and only opens them for a specified short duration and only to specific IPs when an admin requests access. This minimizes the window of exposure for RDP and ensures that even if RDP is needed, it’s not continuously available to attackers. Each JIT request is logged and can require approval, adding oversight to admin access. In practice, many AVD deployments might avoid direct RDP entirely – but if it’s needed, JIT provides a controlled way to do so rather than leaving ports open.
- Hardening Session Hosts Beyond CIS Baseline: Review the security of the Windows 11 session hosts and apply additional hardening as appropriate for your environment. The CIS baseline is a great starting point, but there may be further measures to implement: Endpoint protection and EDR: Ensure Microsoft Defender Antivirus is active (or a third-party equivalent) on all session hosts with up-to-date definitions. Also deploy an Endpoint Detection & Response agent (like Defender for Endpoint, which can be auto-enabled via Defender for Cloud) to get behavioral detections. These tools will help catch any malware or suspicious activity that slips through preventive controls. Application allowlisting: Consider using Windows Defender Application Control (WDAC) or AppLocker to restrict which applications and scripts can run on the session hosts. By only allowing known good applications, you can mitigate ransomware or unauthorized software from executing. This is especially useful in a tightly managed AVD environment where the set of applications is controlled. WDAC can be configured to trust applications signed by Microsoft or your organization, etc., preventing unknown executables from running. Attack Surface Reduction (ASR) rules: If using Microsoft Defender for Endpoint P2, enable ASR rules which prevent common attack techniques (like blocking Office from creating child processes, blocking credential stealing from the memory, etc.). These harden the OS against exploitation. Disable unnecessary device redirections: Through AVD client policies or group policy on session hosts, disable or limit features like drive redirection, clipboard sharing, USB device redirection, and printing redirection if they are not needed. Each redirected device channel could be a potential avenue for data leakage or attack. For example, if users have no business need to copy files from the remote session to their local machine, consider disabling disk drive redirection. AVD even provides features like watermarking and screen capture protection for sessions – if your data is highly sensitive, enabling these can prevent users from easily exfiltrating information via screenshots or photography of the screen. Idle session management: Configure strict screen lock and session timeout policies. As recommended by Microsoft, enforce that user sessions are locked after a period of inactivity and signed out after a reasonable timeout. This helps if a user walks away from their device or forgets to sign out – an attacker can’t just sit at the open session. Likewise, an idle session still consumes resources and could be hijacked, so logging off idle users improves both security and resource usage. Least privilege on the OS: Ensure that no regular end-users have local admin rights on the session hosts. They should operate as standard users only. Administrators of the environment should use separate admin accounts if they need to log onto session hosts for maintenance, and those accounts should not be used for daily non-admin tasks. This way, even if a user’s context is compromised, the damage is limited by their non-admin rights.
- Monitoring and Logging: A secure environment is one that is well-monitored. Enable and aggregate logs from all relevant sources – Entra ID sign-in logs (to watch for unusual login patterns or failures), AVD feed and diagnostic logs (user connection events, latency, errors), Windows Event Logs on session hosts (especially security events, PowerShell logs, etc.), and Azure activity logs (for any changes to the infrastructure). Use Azure Monitor or Microsoft Sentinel to set up alerts for critical events, such as multiple failed logins (potential brute force), a user added to an admin role, or a new network rule created. Azure Monitor Workbooks or dashboards can help visualize session host performance and usage, which might also surface odd behavior (like a host under heavy CPU load unexpectedly could indicate crypto mining malware). In short, treat the AVD environment like you would an on-prem datacenter – have a SIEM or logging solution in place to continuously watch for indicators of compromise.
- Regular Updates and Patching: Keep the AVD session hosts and images updated. Apply Windows security patches in a timely manner (at least monthly) to address newly discovered vulnerabilities. Since the image is CIS-hardened, it’s important to maintain that secure state by not falling behind on patches or letting third-party software go unpatched. Consider using Azure Update Management or another patch management tool to schedule updates during maintenance windows. For AVD, you might use a scaling plan to drain VMs and patch them in rotation. Also, periodically update your master image (the gold image) with the latest patches and re-harden if needed, so that any new host VMs launched are fully up to date from the start. Don’t forget to update applications (e.g., Office) and tools like FSLogix if new security improvements come out.
- Backups and Recovery: Although not always considered a “security” measure, having backups is vital for recovery from security incidents (like ransomware or an admin error). Ensure that Azure Files share with FSLogix profiles is backed up (Azure Backup can do file-share backups). This allows point-in-time restore of user profiles in case data gets encrypted or wiped maliciously. Similarly, maintain backups or snapshots of any important configurations (like custom scripts or configurations on the session hosts). In a pooled AVD scenario, you can always redeploy VMs from the image, but user profile data needs protection via backups.
- Testing and Incident Response: Conduct periodic simulated attacks or red-team exercises on the AVD environment. For example, simulate what would happen if a user’s credentials are phished – can an attacker get in? If they do, can they move laterally to other systems from the AVD host? By testing these, you can identify gaps (maybe you need tighter NSG rules or additional hardening). Make sure you have an incident response plan specifically for cloud/Azure/AVD incidents. Know how to isolate a compromised session host (e.g., by removing it from the host pool or disabling it in NSG), how to reset user sessions, and how to restore data. Leverage Azure’s capabilities like performing a forensic disk snapshot of a VM for analysis if needed.
By following these best practices in conjunction with the robust built-in and Azure-native security features discussed earlier, the Azure Virtual Desktop environment will be highly secure and resilient. In this configuration – using Gen2 VMs with Trusted Launch, CIS-hardened Windows 11 images, FSLogix with Azure Files, and Azure’s identity/network security – each layer from hardware to software to user access is fortified. Defense-in-depth is achieved by multiple overlapping controls: from firmware protection (Secure Boot, vTPM) to OS hardening (CIS baseline, AV/EDR), network fencing (NSGs, Firewall, Private Link), identity safeguards (MFA, Conditional Access), and continuous monitoring (Defender for Cloud, logging). The result is an AVD deployment that can confidently defend against a wide range of threats while safely delivering virtual desktops to users.