25. July 2026

Securing AVD: Building Protection in from Day One

Start with the security requirements, not the products

Before selecting controls, establish the risks associated with each AVD workload and user persona.

A pooled desktop for standard office users, a personal desktop for developers and a privileged admin environment should not automatically receive the same policies. Their applications, access requirements, data sensitivity and likely attack paths are different.

The design should answer questions such as:

• Who will connect and are they employees, third parties, administrators or external users?
• Will connections be permitted from personal or unmanaged devices?
• Which applications and data can each persona access?
• Does any user require elevated rights inside the desktop?
• Which device-redirection features are genuinely required?
• Can session hosts reach the internet and which destinations are necessary?
• Where are FSLogix profiles and application data stored?
• Which events need to be collected, retained and investigated?
• Who owns vulnerability remediation and incident response after go-live?

These decisions should be recorded in a security control matrix and traced back to business, compliance and operational requirements.

Security exceptions should be explicit, approved, time-limited and reviewed, not allowed to emerge accidentally during deployment.

1. Protect the identity before the desktop

Identity is the first control point in an AVD connection. If an attacker can sign in as a legitimate user or administrator, the remaining controls are already under pressure.

Require multifactor authentication

MFA is important, but it should not be viewed as the whole identity design. It proves that an additional authentication factor was supplied; it doesn’t establish that the device is trusted, the location is expected or the sign-in risk is acceptable.

Use Conditional Access to make contextual decisions

Conditional Access can evaluate the user, device, location, application and sign-in risk before granting access.

Policies might:

• Require MFA for all AVD access.
• Block high-risk sign-ins or require secure remediation.
• Require a compliant or hybrid-joined device for sensitive host pools.
• Permit unmanaged devices to access only a restricted desktop or RemoteApp service.
• Apply stronger controls to privileged users and administrators.
• Restrict access by country or named location where there is a valid requirement.
• Define suitable sign-in frequency and session controls.

Policies should initially be introduced in report-only mode and tested using representative pilot accounts. Emergency-access procedures must also be maintained.

A poorly designed CA policy can lock out administrators or interrupt production access just as effectively as a technical outage.

Separate and control privileged access

Admins should use separate privileged identities rather than their normal productivity accounts.

Microsoft Entra Privileged Identity Management can provide time-bound and approval-based activation for privileged roles, with MFA, justification and notifications applied where appropriate.

Permanent access to broad roles should be avoided. Global Administrator, Owner and User Access Administrator are rarely appropriate for routine AVD administration.

Responsibilities can instead be divided between teams managing:

• AVD workspaces, host pools and application groups.
• Session host virtual machines.
• Images and application packaging.
• Networking and firewalls.
• Profile storage.
• Monitoring and security operations.

Apply RBAC at the correct scope

Use RBAC roles assigned to groups rather than directly to individual accounts wherever possible.

Scope each assignment to the management group, subscription, resource group or resource the team genuinely needs to manage. Microsoft provides built-in RBAC roles for AVD, which should be considered before custom roles are created.

RBAC reviews should cover users, groups, service principals and managed identities. Old automation identities and temporary project access are common sources of privilege that survive long after their original purpose has ended.

2. Treat every session host as a security boundary

AVD uses reverse connect, so inbound ports do not need to be opened to session hosts for normal user connections.

That removes one traditional exposure, but it doesn’t protect an unpatched or poorly configured operating system.

Build a repeatable hardening baseline

Create a documented session-host baseline using the relevant security baselines and organisational standards.

Apply it consistently using:

• Microsoft Intune.
• Group Policy.
• Azure Policy.
• Image-building pipelines.

The baseline should cover operating system security, Defender settings, Firewall, credential protection, audit policies, screen-lock behaviour, application control, browser security and prohibited services.

Trusted Launch should be used for supported session-host deployments unless a documented compatibility issue prevents it.

The baseline must also be tested against the applications and user personas. A technically strong policy that breaks a business-critical application will usually be bypassed under pressure, weakening the overall design.

Patch the image

Use a validation host pool to test operating system, application and security updates before broad deployment.

The patching process should define:

• Maintenance windows.
• Drain-mode procedures.
• Application regression testing.
• Image versioning.
• Rollback procedures.
• Emergency patching.
• The maximum period a critical vulnerability may remain unresolved.

Microsoft recommends patching base images monthly, although critical vulnerabilities may require an accelerated response.  This will be dependant on company policy and regulatory requirements.

Deploy endpoint protection and detection

Microsoft Defender Antivirus or an approved alternative should protect every session host.

Microsoft Defender for Endpoint adds:

• Endpoint detection and response.
• Threat and vulnerability management.
• Automated investigation.
• Advanced hunting.
• Device isolation and response capabilities.

AVD-specific performance and profile considerations must be tested. Antivirus exclusions should be narrowly based on documented product guidance because broad folder or process exclusions can create significant blind spots.

The security team should confirm that new or reimaged session hosts are successfully onboarded and reporting before they accept users.

Restrict local admin accounts and usage

Users should not be local administrators on pooled multi-session hosts.

Local admins in a shared environment can cross session and NTFS security boundaries, disrupt other users and cause data loss.

If a user or group genuinely requires local administration, for example, certain developers, use a separately secured personal host pool or another enhanced admin solution such as Endpoint Privilege Management (see my previous article on EPM for more details)

Administrative access to session hosts should use:

• Separate privileged credentials.
• Controlled support procedures.
• Time-bound access.
• Auditing and session recording where required.
• Approved management devices.

Avoid leaving direct RDP exposed. Where direct administration is required for troubleshooting, use a restricted method such as just-in-time access.

Control applications and device redirection

RemoteApp limits what is presented to the user, but it isn’t an application-security boundary. Use App Control for Business or AppLocker where the requirement is to prevent unapproved software from running.

Review every redirection capability, including:

• Clipboard.
• Local and remote drives.
• Printers.
• USB devices.
• Cameras and microphones.
• COM ports and smart cards.

The decision should be based on the persona and data risk.

For example, a user may need to copy text into a session without being allowed to copy files out. Directional clipboard controls can provide a more usable solution than unrestricted bidirectional transfer.

OneDrive and Universal Print can also provide controlled alternatives to drive and printer redirection.

3. Design the network to contain and control

An AVD session host can become a route to applications, file shares, databases, management services and the internet. Network design should limit that reach to what the workload needs.

Segment by trust and workload

Place session hosts in dedicated subnets and use Network Security Groups to restrict traffic.

Separate host pools when their users, applications, data sensitivity or administrative requirements create different trust boundaries. For example, privileged administrators should not share the same network boundary and policies as general productivity users.

In larger environments, a hub-and-spoke architecture can centralise:

• DNS.
• Firewall inspection.
• Routing.
• Connectivity to on-premises services.
• Logging and network management.

Segmentation should consider east-west access between internal resources, not only internet traffic.

Control outbound access

Route outbound traffic through Azure Firewall, a network virtual appliance or another approved secure web access service when the risk requires inspection and control.

Allow the required AVD FQDNs and endpoints, together with the endpoints required by Microsoft Entra ID, Microsoft 365, update services, applications and monitoring agents.

Use private endpoints where they reduce meaningful exposure

Private endpoints are particularly valuable for profile storage, application storage and supported PaaS services because they provide access through private IP addresses.

AVD supports Private Link for private feed discovery and session-connectivity scenarios. It should be selected because the threat model or compliance requirement justifies the additional DNS, routing, client-connectivity and operational complexity—not simply because “private” sounds more secure.

Microsoft provides separate Private Link guidance for AVD.

Encrypt data at rest and in transit

Azure provides platform encryption for supported disks and storage services, but the architecture must still document:

• What data is encrypted.
• Whether encryption applies at rest, in transit and in use.
• Which service manages the keys.
• Whether customer-managed keys are required.
• How keys are rotated and recovered.
• Who can access key-management services.

Protect traffic to SMB shares and application services in transit and avoid legacy protocols that weaken authentication or encryption.

Highly sensitive workloads may justify confidential virtual machines, which add hardware-based isolation and memory protection, subject to workload compatibility, regional availability and cost.

Make access auditable

Enable logging for storage access, permission changes and administrative operations where supported.

Decide how long logs must be retained and who is permitted to query them. Audit data is only useful if it is collected before an incident and protected from casual deletion or modification.

4. Monitor the complete connection path

AVD security monitoring should connect identity, control-plane, session-host, network and data events. Looking at any one layer in isolation can miss the story of an attack.

Use Azure Monitor and Log Analytics

Send AVD diagnostic settings to a Log Analytics workspace.

AVD Insights uses Azure Monitor Workbooks and can surface connection activity, errors, host registration and agent health alongside session-host performance data.

Session-host telemetry requires the Azure Monitor Agent and Data Collection Rules to collect the selected Windows event logs and performance counters. Collect deliberately: too little data creates blind spots, while uncontrolled ingestion adds cost and makes important signals harder to find.

Security go-live checklist

Before an AVD workload moves into production, confirm that:

• MFA and Conditional Access have been tested with normal, privileged and emergency-access accounts.
• Administrative roles are least-privileged, group-based and time-bound where appropriate.
• Session hosts meet the approved hardening baseline.
• The image and active hosts have current patches.
• Defender and monitoring agents are healthy on every production host.
• Users do not have unnecessary local administrator rights.
• Clipboard, drive, printer and USB redirection match persona requirements.
• Network paths, firewall rules, DNS and private endpoints have been validated.
• Profile and file-share permissions prevent cross-user access.
• Encryption and key-management requirements are documented and met.
• AVD, Entra, Windows, Defender, network and storage logs reach the intended workspaces.
• High-priority alerts have owners and tested response runbooks.
• Security exceptions are approved, documented and scheduled for review.

…and finally

Securing AVD isn’t a single product decision and it isn’t a task to leave until deployment is complete. It is an architectural discipline spanning identity, endpoints, session hosts, networks, profiles, applications, data and operations.

The strongest AVD designs use layers.

MFA and Conditional Access reduce the chance of account misuse. Least privilege limits what a compromised identity can do. Hardening, patching and Defender reduce the session-host attack surface. Segmentation and outbound controls restrict movement. Data permissions and encryption protect the information users work with. Monitoring and Sentinel provide the visibility needed to detect and respond.

When these controls are designed alongside the user personas, application requirements and operating model, security becomes part of how the AVD service works, not an obstacle added after go-live.