OASOpen
Architecture
Systems
Back to insights
Citrix & Virtualisation

deviceTRUST Rollout: A Checklist for Citrix Administrators

deviceTRUST ships inside Citrix Workspace app and the VDA, so installation is no longer the hard part. This checklist covers entitlement, prerequisites, a notify-first pilot and staged enforcement.

OAS Editorial Team

· 5 min read

Since Citrix Virtual Apps and Desktops 2503, deviceTRUST has been part of the product rather than an add-on: the Agent is in the VDA installer, the Console is on the product ISO and the Client Extension is inside Citrix Workspace app. That removes the installation project. What remains is the policy work, and that is where rollouts go wrong, either by enforcing too early and locking users out, or by never moving past a pilot. This checklist is about getting contextual access into production without a helpdesk spike.

Step 1: confirm your entitlement and versions

Citrix's customer FAQ, published with the December 2024 acquisition, states that the Platform License, the Universal Hybrid Multi-Cloud licence and the legacy DaaS subscriptions are all entitled to deviceTRUST, with the software and licence file available from the Citrix account portal. Organisations without one of those can request a trial through their Citrix representative.

Then check versions. The Citrix documentation ties each component to a release:

  • Agent: included in Citrix Virtual Apps and Desktops 2503 or later. Install it from the VDA media on every session host that will enforce policy.
  • Console: on the product ISO from 2503, in the x64\deviceTRUST folder. It runs on a Windows management workstation, not on the VDA.
  • Client Extension: included in Citrix Workspace app 2503 or later for Windows, with separate packages for macOS, Ubuntu, eLux, IGEL OS and other thin-client platforms.

A separate deviceTRUST licence is needed only in a non-CVAD environment, such as Azure Virtual Desktop or a plain Remote Desktop Session Host farm. Either way, event ID 11 in the deviceTRUST Admin log on the session host confirms that the Agent is licensed.

deviceTRUST 2507 is the Long Term Service Release. Plan Workspace app upgrades alongside the server side, because several newer properties need the 2607 client.

Step 2: clear the prerequisites

The getting-started guide lists conditions that are easy to overlook. Work through them before the first policy is written.

  • Decide how policy will reach the session hosts: a Group Policy Object for the VDA organisational unit, a file copied to C:\ProgramData\deviceTRUST\Policy on each host, or the local policy editor for a lab. Group Policy is the production choice.
  • Keep Citrix policy and deviceTRUST policy separate. Citrix policies are still created in Web Studio. If deviceTRUST will control clipboard redirection, unconfigure the equivalent Citrix setting so the two do not conflict.
  • If AppLocker or FSLogix App Masking is on the image, confirm they work correctly before adding deviceTRUST, so a later problem can be attributed.
  • Create a non-administrative test account. deviceTRUST applies to all users except local administrators, so testing as an admin proves nothing.
  • Inventory the endpoints. Older Workspace app versions, Macs, thin clients and browser-only users all need a plan; a client without the extension cannot report context.

Step 3: pilot with notification, not enforcement

Start with the Compliance Check template. Its Notification action is enabled by default and its Enforcement action is disabled. That default is the pilot design: for the first weeks, a device that falls out of compliance produces a message to the user and an event in the log, but keeps its session.

Run the pilot on one delivery group with a handful of contexts, for example firewall and antivirus state, Workspace app version and domain membership. Read the logs weekly and ask three questions. How many users would have been locked out? Were they exceptions, such as a branch on an undocumented network range, or real risks? What message would have let them fix the problem themselves?

deviceTRUST 2607 adds a rich pop-up and deny-access appearance with a corporate logo, colour scheme and formatted text with links. A message that names the fix (re-enable the firewall, update Workspace app, remove the USB drive) is the difference between a self-service recovery and a ticket.

Note also that 2607 removed some template building blocks, including the Device Type Contractor and Corporate blocks, so review any policy built on an earlier release in the new Console.

Step 4: enforce in stages

Switch on enforcement one context at a time, in order of least user impact.

  1. Security software state. The user can fix it in seconds. Lock the session rather than disconnecting it, so work is not lost.
  2. Workspace app version. Deny access with a message that links to the update, once the endpoint team has pushed the new version.
  3. Unauthorised USB storage. The 2607 release adds USB device properties (name, path, device class, vendor ID and product ID) on Windows, macOS and Linux clients, which allows an allow-list of approved media rather than a blanket block. Disable drive redirection; keep the session alive.
  4. Network and location. Define trusted ranges first and test from every office, branch and VPN pool. Geofencing is the context most likely to catch a legitimate traveller, so agree the exception process before enforcing it.
  5. BYOD profiles. Apply the restricted profile, with clipboard, printing and local drives off, to devices that are not domain-joined or lack the corporate certificate.

Between stages, read the enforcement log and confirm that the helpdesk saw a trickle, not a flood.

Step 5: add the pre-logon layer and keep the evidence

deviceTRUST evaluates context inside the session. The Citrix Device Posture service does the complementary job before it: its scans run only during pre-authentication, and a device is classed as compliant, non-compliant with restricted access to chosen delivery groups, or denied login. Together they cover before logon, at logon and throughout the session.

Finally, treat the logs as a compliance asset. Every evaluation, decision and action is recorded, which is evidence that an access control was applied, not just configured. That record supports the security safeguards POPIA expects; our POPIA compliance guide covers what regulators ask for. Contextual access is one piece of a wider architecture: the zero trust guide maps the other pillars, and Citrix Secure Private Access covers applications outside a Citrix session.

Sources

Plan a notify-first pilot with deviceTRUST designed, deployed and managed by OAS.

Keep exploring

All insights