Technical security overview

The following diagram shows the components in a Citrix Managed Desktops deployment.

Citrix Managed Desktops components

With Citrix Managed Desktops, the customer’s Virtual Delivery Agents (VDAs) that deliver desktops and apps, plus the Citrix Cloud Connectors are deployed into an Azure subscription and tenant that Citrix manages.

Citrix responsibility

Citrix Cloud Connectors for non-domain-joined catalogs

Citrix Managed Desktops deploys at least two Cloud Connectors in each resource location. Some catalogs may share a resource location if they are in the same region as other catalogs for the same customer.

Citrix is responsible for the following security operations on non-domain-joined catalog Cloud Connectors:

  • Applying operating system updates and security patches
  • Installing and maintaining antivirus software
  • Applying Cloud Connector software updates

Customers do not have access to the Cloud Connectors. Therefore, Citrix is wholly responsible for the performance of the non-domain-joined catalog Cloud Connectors.

Azure subscription and Azure Active Directory

Citrix is responsible for the security of the Azure subscription and Azure Active Directory (AAD) that are created for the customer. Citrix ensures tenant isolation, so each customer has their own Azure subscription and AAD, and cross-talk between different tenants is prevented. Citrix also restricts access to the AAD to the Citrix Managed Desktops service and Citrix operations personnel only. Access by Citrix to each customer’s Azure subscription is audited.

Customers employing non-domain-joined catalogs can use the Citrix-managed AAD as a means of authentication for Citrix Workspace. For these customers, Citrix creates limited privilege user accounts in the Citrix-managed AAD. However, neither customers’ users nor administrators can execute any actions on the Citrix-managed AAD. If these customers elect to use their own AAD instead, they are wholly responsible for its security.

Virtual networks and infrastructure

Within the customer’s Citrix-managed Azure subscription, Citrix creates virtual networks for isolating resource locations. Within those networks, Citrix creates virtual machines for the VDAs, Cloud Connectors, and image builder machines, in addition to storage accounts, Key Vaults, and other Azure resources. Citrix, in partnership with Microsoft, is responsible for the security of the virtual networks, including virtual network firewalls.

Citrix ensures the default firewall policy is configured to prevent all incoming traffic to VDAs and Cloud Connectors, except for ports 80, 443, 1494, and 2598 for bidirectional traffic between VDAs and Cloud Connectors. The default firewall policy also allows all outgoing traffic. Customers who want to alter the default policy – such as configuring additional firewall rules or installing a virtual private network on a Citrix-created VDA machine – are responsible for any security risks that might result.

Access to infrastructure

Citrix may access the customer’s Citrix-managed infrastructure (Cloud Connectors) to perform certain administrative tasks such as collecting logs (including Windows Event Viewer) and restarting services without notifying the customer. Citrix is responsible for executing these tasks safely and securely, and with minimal impact to the customer. Citrix is also responsible for ensuring any log files are retrieved, transported, and handled safely and securely. Customer VDAs cannot be accessed this way.

Backups for non-domain-joined catalogs

Citrix is not responsible for performing backups of non-domain-joined catalogs.

Backups for master images

Citrix is responsible for backing up any master images uploaded to Citrix Managed Desktops, including images created with the image builder. Citrix uses locally redundant storage for these images.

Bastions for non-domain-joined catalogs

Citrix operations personnel have the ability to create a bastion, if necessary, to access the customer’s Citrix-managed Azure subscription for diagnosing and repairing customer issues, potentially before the customer is aware of a problem. Citrix does not require the customer’s consent to create a bastion. When Citrix creates the bastion, Citrix creates a strong randomly generated password for the bastion and restricts RDP access to Citrix NAT IP addresses. When the bastion is no longer needed, Citrix disposes of it and the password is no longer valid. The bastion (and its accompanying RDP access rules) are disposed of when the operation completes. Citrix can access only the customer’s non-domain-joined Cloud Connectors with the bastion. Citrix does not have the password to log in to non-domain-joined VDAs or domain-joined Cloud Connectors and VDAs.

Customer responsibility

VDAs and master images

The customer is responsible for all aspects of the software installed on VDA machines, including:

  • Operating system updates and security patches
  • Antivirus and antimalware
  • VDA software updates and security patches
  • Additional software firewall rules (especially outbound traffic)

Citrix provides a prepared image that is intended as a starting point. Customers can use this image for proof-of-concept or demonstration purposes or as a base for building their own master image. Citrix does not guarantee the security of this prepared image. Citrix will make an attempt to keep the operating system and VDA software on the prepared image up to date, and will enable Windows Defender on these images.

VNet peering

For VDAs in Citrix Managed Desktops to contact on-premises domain controllers, file shares, or other intranet resources, Citrix Managed Desktops provides a VNet peering workflow. The customer’s Citrix-managed virtual network is peered with a customer-managed Azure virtual network. The customer-managed virtual network has connectivity with the customer’s on-premises resources using the cloud-to-on-premises connectivity solution of the customer’s choice, such as Azure ExpressRoute or iPsec tunnels.

The customer is responsible for the security of their own virtual network and its connectivity to their on-premises resources. The customer is also responsible for security of the incoming traffic from the Citrix-managed peered virtual network. Citrix does not take any action to block traffic from the Citrix-managed virtual network to the customer’s on-premises resources.

Customers have the following options for restricting incoming traffic:

  • Give the Citrix-managed virtual network an IP block which is not in use elsewhere in the customer’s on-premises network or the customer-managed connected virtual network. This is required for VNet peering.
  • Add Azure network security groups and firewalls in the customer’s virtual network and on-premises network to block or restrict traffic from the Citrix-managed IP block.
  • Deploy measures such as intrusion prevention systems, software firewalls, and behavioral analytics engines in the customer’s virtual network and on-premises network, targeting the Citrix-managed IP block.


The customer may choose whether to use a proxy for outbound traffic from the VDA. If a proxy is used, the customer is responsible for:

  • Configuring the proxy settings on the VDA master image or, if the VDA is joined to a domain, using Active Directory Group Policy.
  • Maintenance and security of the proxy.

Proxies are not allowed for use with Citrix Cloud Connectors or other Citrix-managed infrastructure.

Catalog resiliency

Citrix provides three types of catalogs with differing levels of resiliency:

  • Static: Each user is assigned to a single VDA. This catalog type provides no high availability. If a user’s VDA goes down, they will have to be placed on a new one to recover. Azure provides a 99.5% SLA for single-instance VMs. The customer can still back up the user profile, but any customizations made to the VDA (such as installing programs or configuring Windows) will be lost.
  • Random: Each user is assigned randomly to a server VDA at launch time. This catalog type provides high availability via redundancy. If a VDA goes down, no information is lost because the user’s profile resides elsewhere.
  • Windows 10 multisession: This catalog type operates in the same manner as the random type but uses Windows 10 workstation VDAs instead of server VDAs.

Backups for domain-joined catalogs

If the customer uses domain-joined catalogs with a VNet peering, the customer is responsible for backing up their user profiles. Citrix recommends that customers configure on-premises file shares and set policies on their Active Directory or VDAs to pull user profiles from these file shares. The customer is responsible for the backup and availability of these file shares.

Disaster recovery

In the event of Azure data loss, Citrix will recover as many resources in the Citrix-managed Azure subscription as possible. Citrix will attempt to recover the Cloud Connectors and VDAs. If Citrix is unsuccessful recovering these items, customers are responsible for creating a new catalog. Citrix assumes that master images are backed up and that customers have backed up their user profiles, allowing the catalog to be rebuilt.

In the event of the loss of an entire Azure region, the customer is responsible for rebuilding their customer-managed virtual network in a new region and creating a new VNet peering within Citrix Managed Desktops.

Citrix and customer shared responsibilities

Citrix Cloud Connector for domain-joined catalogs

Citrix Managed Desktops deploys at least two Cloud Connectors in each resource location. Some catalogs may share a resource location if they are in the same region, VNet peering, and domain as other catalogs for the same customer. Citrix configures the customer’s domain-joined Cloud Connectors for the following default security settings on the image:

  • Operating system updates and security patches
  • Antivirus software
  • Cloud Connector software updates

Customers do not normally have access to the Cloud Connectors. However, they may acquire access by using catalog troubleshooting steps and logging in with domain credentials. The customer is responsible for any changes they make when logging in through the bastion.

Customers also have control over the domain-joined Cloud Connectors through Active Directory Group Policy. The customer is responsible for ensuring that the group policies that apply to the Cloud Connector are safe and sensible. For example, if the customer chooses to disable operating system updates using Group Policy, the customer is responsible for performing operating system updates on the Cloud Connectors. The customer can also choose to use Group Policy to enforce stricter security than the Cloud Connector defaults, such as by installing a different antivirus software. In general, Citrix recommends that customers put Cloud Connectors into their own Active Directory organizational unit with no policies, as this will ensure that the defaults Citrix uses can be applied without issue.


In the event the customer experiences problems with the catalog in Citrix Managed Desktops, there are two options for troubleshooting: using bastions and enabling RDP access. Both options introduce security risk to the customer. The customer must understand and consent to undertaking this risk prior to using these options.

Citrix is responsible for opening and closing the necessary ports to carry out troubleshooting operations, and restricting which machines can be accessed during these operations.

With either bastions or RDP access, the active user performing the operation is responsible for the security of the machines that are being accessed. If the customer accesses the VDA or Cloud Connector through RDP and accidentally contracts a virus, the customer is responsible. If Citrix Support personnel access these machines, it is the responsibility of those personnel to perform operations safely. Responsibility for any vulnerabilities exposed by any person accessing the bastion or other machines in the deployment (for example, customer responsibility to whitelist IP ranges, Citrix responsibility to implement IP ranges correctly) is covered elsewhere in this document.

In both scenarios, Citrix is responsible for correctly creating firewall exceptions to allow RDP traffic. Citrix is also responsible for revoking these exceptions after the customer disposes of the bastion or ends RDP access through Citrix Managed Desktops.


Citrix may create bastions in the customer’s Citrix-managed virtual network within the customer’s Citrix-managed subscription to diagnose and repair issues, either proactively (without customer notification) or in response to a customer-raised issue. The bastion is a machine that the customer can access through RDP and then use to access the VDAs and (for domain-joined catalogs) Cloud Connectors through RDP to gather logs, restart services, or perform other administrative tasks. By default, creating a bastion opens an external firewall rule to allow RDP traffic from a customer-specified range of IP addresses to the bastion machine. It also opens an internal firewall rule to allow access to the Cloud Connectors and VDAs through RDP. Opening these rules poses a large security risk.

The customer is responsible for providing a strong password used for the local Windows account. The customer is also responsible for providing an external IP address range that allows RDP access to the bastion. If the customer elects not to provide an IP range (allowing anyone to attempt RDP access), the customer is responsible for any access attempted by malicious IP addresses.

The customer is also responsible for deleting the bastion after troubleshooting is complete. The bastion host exposes additional attack surface, so Citrix automatically shuts down the machine eight (8) hours after it is powered on. However, Citrix never automatically deletes a bastion. If the customer chooses to use the bastion for an extended period of time, they are responsible for patching and updating it. Citrix recommends that a bastion be used only for several days before deleting it. If the customer wants an up-to-date bastion, they can delete their current one and then create a new bastion, which will provision a fresh machine with the latest security patches.

RDP access

For domain-joined catalogs, if the customer’s VNet peering is functional, the customer can enable RDP access from their peered VNet to their Citrix-managed VNet. If the customer uses this option, the customer is responsible for accessing the VDAs and Cloud Connectors over the VNet peering. Source IP address ranges can be specified so RDP access can be restricted further, even within the customer’s internal network. The customer will need to use domain credentials to log in to these machines. If the customer is working with Citrix Support to resolve an issue, the customer may need to share these credentials with support personnel. After the issue is resolved, the customer is responsible for disabling RDP access. Keeping RDP access open from the customer’s peered or on-premises network poses a security risk.

Domain credentials

If the customer elects to use a domain-joined catalog, the customer is responsible for providing to Citrix Managed Desktops a domain account (username and password) with permissions to join machines to the domain. When supplying domain credentials, the customer is responsible for adhering to the following security principles:

  • Auditable: The account should be created specifically for Citrix Managed Desktops usage so that it is easy to audit what the account is used for.
  • Scoped: The account requires only permissions to join machines to a domain. It should not be a full domain administrator.
  • Secure: A strong password should be placed on the account.

Citrix is responsible for the secure storage of this domain account in an Azure Key Vault in the customer’s Citrix-managed Azure subscription. The account is retrieved only if an operation requires the domain account password.

More information

For related information, see: