Azure Virtual Desktop shows up in a lot of my Microsoft 365 and Azure projects as the standard answer for secure remote access. Proper Azure Virtual Desktop security, though, is almost never there from day one. I regularly find tenants that rely on basic MFA and treat that as "good enough." It isn't. Attackers get around basic controls without much effort, and the same goes for data exfiltration. Hardening AVD means stacking several layers: strong Conditional Access, network isolation, session restrictions and ongoing endpoint protection, each one covering what the others miss. This is how I handle it in practice.

Conditional Access for the Azure Virtual Desktop app should go beyond MFA

I always start with Conditional Access. Every AVD deployment gets its own policy aimed at the "Azure Virtual Desktop" enterprise app, not just at generic Azure sign-ins. MFA on every sign-in is a given, and I can't think of a good reason to skip it. I also almost always configure a strict sign-in frequency (usually 8 hours or less), which reduces the risk from session tokens and long-lived access. Host pools with particularly sensitive workloads get an authentication context with tighter access conditions on top. I've written about contexts in more detail in Conditional Access Authentication Contexts.

Pro tip: Check the policy assignment carefully. Target only the AVD app and not all Azure resources, otherwise you'll lock out users you didn't mean to and the helpdesk tickets will follow.

The configuration lives in the Entra portal under "Conditional Access." Azure AD Premium P1 covers MFA and sign-in frequency. For authentication contexts and the more granular controls you need P2.

RDP restrictions stop data leaks and session abuse

In AVD, a lot of the risk sits inside the RDP session rather than at the initial login. With clipboard, drive or printer redirection enabled, sensitive data can leave the environment with very little effort, whether a user does it on purpose or malware does it for them. On every host pool I go through the RDP properties and switch off the options that carry the most risk:

  • clipboard:redirection:i:0 (blocks clipboard)
  • drive:redirection:i:0 (blocks drive mapping)
  • printer:redirection:i:0 (blocks printers)
  • camera:redirection:i:0 (blocks webcam)

You configure these in the host pool's "RDP Properties" blade, either through the UI or as a single string:

clipboard:redirection:i:0;drive:redirection:i:0;printer:redirection:i:0;camera:redirection:i:0

If the use case is especially sensitive, think about allowing only whitelisted file types or cutting redirection back even further. Microsoft's documentation on this is solid: AVD Security Guide.

Screen capture protection and watermarking guard confidential sessions

For confidential data I now treat screen capture protection and watermarking as standard. The Screen capture protection feature blocks most screenshot tools, Snipping Tool included, on Windows 10/11 and Windows Server 2022 once you enable it through GPO, Intune policy or host pool settings. Watermarking adds a deterrent and an audit trail by overlaying user and session details on the screen. The documentation is good: AVD Watermarking. In my experience users accept it without much pushback as long as you explain up front that it's a compliance requirement.

The diagram below shows the main controls along the access path:

flowchart TD
    user["User"] --> ca["Conditional Access (MFA, Sign-in frequency)"]
    ca --> avdapp["Azure Virtual Desktop App"]
    avdapp --> gateway["AVD Gateway (Private Endpoint)"]
    gateway --> sessionhost["Session Host (Trusted Launch)"]
    sessionhost --> rdp["RDP settings (Clipboard, Printer, Drive)"]
    sessionhost --> screenprotect["Screen Capture Protection / Watermarking"]
    sessionhost --> defender["Defender for Endpoint + Intune Mgmt"]
    sessionhost --> fslogix["FSLogix profile with Azure Files (Kerberos)"]

Figure: The hardening controls at each AVD layer

Session hosts get no public IPs, only Private Endpoints

I still come across AVD session hosts with public IPs, either for "convenience" or because "it's always been done this way." That's a serious gap. Make sure no public IP gets assigned when you deploy hosts. Access to the AVD service and to every profile and file share should go through Private Endpoints only, and that includes the AVD gateway as well as the FSLogix shares. For profile containers, use Azure Files with Entra Kerberos authentication and connect to them exclusively over Private Endpoints. If you want more on Entra joined session hosts, see [/blog/azure-virtual-desktop-entra-joined-single-sign-on]. The session hosts themselves should now be Trusted Launch VMs, unless legacy hardware or a specific business reason gets in the way. I wrote about that in [/blog/azure-trusted-launch-vm-security-upgrade].

Defender for Endpoint and Intune belong on multi-session and non-persistent hosts too

The network is only part of securing session hosts. You also need telemetry and active threat detection. Every session host should be onboarded to Defender for Endpoint, and non-persistent and multi-session VMs are no exception. My preferred route these days is the Intune integration, because it also gives you policy management (updates, hardening, inventory) for multi-session VMs. This requires Intune Administrator rights and Defender for Endpoint P2.

One thing to watch: non-persistent VMs need the dedicated onboarding methods (GPO or script), so each new instance registers cleanly when it boots. Microsoft documents the details in the Defender portal.

FSLogix profiles belong on Azure Files with Kerberos and network controls

Profile storage gets overlooked surprisingly often. FSLogix gives users a good experience, but unprotected profile storage is exactly what attackers like to go after. My rule is simple. Profiles always go on Azure Files with Entra Kerberos authentication, behind Private Endpoints, so they can only be reached from the networks that should reach them. I go through the setup step by step in [/blog/azure-files-entra-kerberos-hybrid-identities].

Real-world AVD security goes beyond the checklist

Plenty of best practices look simple on paper. Putting them into place in a real environment takes coordination and discipline. AVD security doesn't come from a single setting. It's a chain of identity, network, session controls and monitoring, and each link depends on the others. Put the effort in early: strong Conditional Access, restricted RDP options, Private Endpoints everywhere and Defender for Endpoint on every host. That is far cheaper than incident response later. If I had to pick one lesson, it's this: treat AVD security as a system and not as a collection of separate controls. With that approach, Azure Virtual Desktop becomes a platform you can actually trust with sensitive workloads.