VDI and DaaS Security Requirements for Buyers

Virtual desktops are often bought as a security control, but a weak gateway, a shared multi-session host or an over-permissive redirection policy turns them into a direct route from any internet-connected device into the estate. The security a virtual desktop platform can deliver is largely fixed at selection time: where the control plane runs, how users and administrators authenticate, which data paths can be closed, and who patches the internet-facing gateway. This vendor-neutral guide sets out the security requirements to put into an RFP for on-premises virtual desktop infrastructure (VDI) and cloud desktop as a service (DaaS), with evaluation criteria, questions for vendors, red flags and a pilot plan. It is for end user computing, identity, security and procurement teams choosing or replacing a platform. Hardening an estate you already run is covered in the Virtual Desktop (VDI) and DaaS Security Guide.

Key takeaways

Know the responsibility split before you score. In DaaS the provider runs the control plane and hosts, but identity, user devices, the session host operating system, configuration and network controls typically stay with you.
The gateway decides your exposure. Prefer architectures that avoid customer-managed inbound gateways, or require a credible patch and session revocation story for the one you must run.
Data control lives in policy granularity. Clipboard direction, drive, printer and USB redirection, screen capture protection and watermarking must be controllable per user group and device posture.
Identity must be enforced at two doors. The broker and the desktop both need modern authentication, Conditional Access style policy, phishing-resistant MFA and separate administrative roles.
Pilot the failure modes, not the login. Test redirection bypasses, session hijack resistance, image patching and admin role separation before you sign.

Define requirements

Use cases: list who will use virtual desktops and why: contractors and third parties, bring your own device (BYOD) staff, privileged administrators, call centres, developers, regulated data handlers, disaster recovery. Each drives different data controls. The NCSC BYOD guidance, for example, expects clipboard and drive redirection disabled, printing blocked and screen capture prevented where possible when VDI is used from personal devices.
Delivery model: persistent desktops, pooled non-persistent desktops, multi-session hosts or published applications. Multi-session hosts share one operating system between users, so they are a shared trust boundary.
Control plane location: customer-hosted brokers and gateways, a vendor-hosted control plane with customer hosts, or fully managed cloud PCs.
Identity: which identity provider brokers sign-in, whether the desktop needs domain join, hybrid join or cloud-only join, and how single sign-on reaches the session.
Endpoints: managed corporate devices, thin clients, unmanaged personal devices, browsers and mobile clients. Your posture requirements will differ per class.
Data residency and regulation: where session hosts, profile storage and logs may sit, and which supplier requirements apply (NIST CSF 2.0 GV.SC-05 and GV.SC-06 describe the expectation of security requirements in contracts and due diligence before contracting).
Non-human identities: broker service accounts, connector or agent enrolment credentials, image build pipelines and automation accounts. List them as requirements, not afterthoughts.

Responsibility split by delivery model

Layer	Self-hosted VDI	DaaS with customer session hosts	Fully managed cloud PC
Physical hosts, hypervisor, datacentre	Customer	Provider	Provider
Broker, gateway, control plane	Customer	Provider (some products still need customer connectors)	Provider
Session host OS and image	Customer	Customer	Shared: provider base image, customer configuration and apps
Identity and access policy	Customer	Customer	Customer
User devices and clients	Customer	Customer	Customer
Network controls and egress	Customer	Customer	Shared

Microsoft's own security recommendations for its DaaS service describe exactly this split: the provider is responsible for the virtualisation control plane, physical hosts, network and datacentre, while customers are responsible for identity, user devices, application security, the session host operating system, deployment configuration and network controls. Ask every shortlisted vendor to produce the equivalent table for their product in writing.

Capability areas

Area	What good looks like
User authentication	Modern federation (SAML or OIDC) to your identity provider, policy-based access by user, device and location, phishing-resistant MFA, sign-in risk evaluation, ability to prevent multiple concurrent sessions
Session security	Idle lock and disconnect timeouts, maximum session lifetime, reauthentication on reconnect, short-lived session tokens bound to the client where the protocol supports it, central session revocation
Gateway exposure	Reverse-connect or outbound-only transport so no inbound ports are opened on customer networks, or a hardened gateway with a published patch timeline and the ability to invalidate all sessions after patching
Data path controls	Per-group control of clipboard direction and content types, drive, printer, USB and camera redirection; file transfer controls; screen capture protection; watermarking that identifies the session
Host and image integrity	Secure Boot and virtual TPM on session hosts, image versioning, automated image builds and rollback, support for your EDR and application control on hosts
Isolation	Clear tenant isolation statement for DaaS; for multi-session hosts, user separation, no local admin, profile container isolation
Administrative security	Granular admin roles (help desk, image, policy, global), MFA for admins, just in time elevation, separate admin portal access policy, provider support access only with customer approval
Logging	Connection, authentication, policy change, admin action and session shadowing events exported to your SIEM in near real time, with client IP and device identifiers
Profile and data storage	Encrypted profile storage, private network access to profile shares, permissions so users reach only their own container, backup and recovery
Supplier assurance	Signed client and agent updates, public vulnerability disclosure policy, timely CVE records, SBOM on request, security patch cadence for gateways and agents

Where identity fits

A virtual desktop platform has two front doors: the broker or service sign-in, and the sign-in to the desktop itself. Windows 365 documentation, for example, notes these two authentication challenges and names Conditional Access as the primary control for the service. Require that both doors honour the same policy and that the product supports single sign-on into the session without falling back to passwords. Administrative access to the platform is privileged access to every desktop and should be treated as tier zero. See the Conditional Access Guide, the Phishing-Resistant MFA Guide and the Remote Access Identity Guide. Service accounts used by brokers, connectors and image pipelines need owners, least privilege and rotation; see the Service Account Security Guide.

Evaluation criteria

Criterion	Suggested weight	Evidence to request
Identity integration and MFA	20%	Supported protocols, policy engine, MFA methods, two-door SSO demonstration
Gateway and network exposure	15%	Network diagram, required inbound and outbound ports, patch history for gateway components
Data path controls	15%	Policy reference showing granularity of redirection, screen capture and watermark settings per group and device
Session security and revocation	10%	Timeout settings, token lifetime, revocation procedure and how long it takes to take effect
Host, image and isolation	10%	Image build and patch process, Secure Boot and vTPM support, tenant isolation statement
Administrative security	10%	Role model, admin MFA, provider support access controls
Logging and SIEM export	10%	Event catalogue, export latency, retention at no extra cost
Supplier assurance	10%	VDP, CVE history, time to fix critical issues, update signing

Weights are an NHI Mgmt Group starting point: raise data path controls for contractor and BYOD use cases, and gateway exposure for estates that must self-host.

Small vs large organisations: smaller organisations usually gain most from fully managed cloud PCs or DaaS with a provider-run gateway, because patching an internet-facing gateway quickly is hard without a dedicated team. Large or regulated organisations may need self-hosted or hybrid deployments for residency or latency, and should then weight gateway patching, session revocation and admin tiering more heavily.

Questions to ask vendors

Provide your shared responsibility matrix for this product. Which components do we patch, and which do you?
Does the product require any inbound connection to our network or to an appliance we manage? If so, what was the time from disclosure to fix for your last three critical gateway vulnerabilities?
After a gateway vulnerability, how do we invalidate every existing session and token, and how long does it take?
Which identity providers and MFA methods are supported at the broker and at the desktop? Can we require phishing-resistant MFA for both?
Can redirection policy (clipboard direction and content type, drive, printer, USB, camera) be set per user group and per device posture, and is it enforced server-side?
Do you offer screen capture protection and session watermarking, and on which client platforms? What happens when a client cannot enforce them: is the connection blocked or allowed?
How are multi-session hosts isolated between users? Can users ever obtain local administrator rights on pooled hosts?
What tenant isolation do you provide in the DaaS control plane, and can your staff access our session hosts or data without our approval?
Which administrative roles exist, can they be scoped to host pools or user groups, and are all admin actions logged with the operator identity?
Which events can be exported to our SIEM, with what latency, and is that included at no extra cost?
How are your clients, agents and connectors updated and signed? Do you publish a vulnerability disclosure policy and complete CVE records?

Red flags

A gateway or broker component you must expose to the internet with no documented emergency patch process.
Redirection controls that are all-or-nothing, or enforced only by the client.
Screen capture protection that silently degrades on unsupported clients instead of blocking the connection.
Password-only sign-in to the desktop after an MFA-protected broker sign-in, with no SSO path.
Default configurations that grant users local administrator rights on pooled or multi-session hosts.
Provider support access to tenant environments without customer approval or audit.
Admin and connection logs only viewable in a portal, with short retention or an extra charge to export.

Common failure patterns

Remote desktop access without MFA: the Change Healthcare breach began with a remote access login that was not protected by MFA. Selection must make MFA at every entry point non-negotiable.
Patching the gateway but leaving sessions alive: in CitrixBleed, CISA warned that the flaw exposed session authentication tokens that could let attackers hijack sessions, and stolen tokens bypassed MFA. A similar flaw, CitrixBleed 2, followed in 2025. Both are on the CISA Known Exploited Vulnerabilities catalogue with known ransomware use.
Assuming data stays in the data centre: leaving clipboard and drive redirection on by default lets data flow straight to unmanaged devices (ATT&CK T1115 Clipboard Data describes the collection technique).
Unpatched golden images: images built once by hand and cloned for months. The Canadian Centre for Cyber Security advises scanning master images before cloning. See the Server Build and Golden Image Hardening Guide.
Misconfiguration at deployment: the same Canadian guidance names software misconfiguration as one of the most common VDI risks, so ask for vendor hardening guidance as a deliverable.

Proof of concept

Build a pilot host pool with a representative image, your EDR and application control, and two user groups with different data policies (for example staff on managed devices and contractors on personal devices).
Apply identity policy: phishing-resistant MFA, device posture conditions and session lifetime. Confirm both the broker and desktop sign-ins honour it, including reconnects.
Test data paths: try clipboard copy in both directions, drive mapping, printing, USB storage and screen capture from each client type, including browser and mobile. Record which controls block, which warn and which fail open.
Test session revocation: disable a pilot user and revoke sessions; measure how long until the active session ends.
Test isolation: on a multi-session host, confirm a standard user cannot see other users' processes, profiles or clipboard contents.
Test admin separation: give a help desk role only session management rights; confirm it cannot change images, policies or shadow sessions without consent if your policy requires consent.
Test logging: forward events to your SIEM and confirm sign-ins, policy changes, admin actions and connection metadata arrive with usable fields.
Test image patching and rollback: push a monthly patch through the image pipeline and roll back to the previous image version.

Detection and measurement after selection

Monitor for sign-ins from unexpected countries or client types, sessions that outlive the configured maximum, policy changes to redirection settings, new admin role assignments, and session shadowing. Useful measures:

Percentage of virtual desktop sign-ins using phishing-resistant MFA.
Days from vendor security advisory to patch on gateways, agents and images.
Age of the oldest image version in production.
Number of user groups with clipboard or drive redirection to unmanaged devices enabled, with documented exceptions.
Time to revoke all sessions for a user, tested quarterly (an NHI Mgmt Group recommendation).

Framework mapping

Requirement	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK technique addressed
Strong authentication at broker and desktop	AC-17 Remote Access, IA-2 Identification and Authentication (Organizational Users)	PR.AA-03	T1133 External Remote Services, T1078 Valid Accounts
Session timeouts and revocation	AC-11 Device Lock, AC-12 Session Termination	PR.AA-03	T1539 Steal Web Session Cookie, T1563.002 RDP Hijacking
Redirection and data path control	AC-4 Information Flow Enforcement	PR.IR-01	T1115 Clipboard Data, T1113 Screen Capture
Multi-session isolation	SC-4 Information in Shared System Resources	PR.IR-01	T1563.002
Image baseline and patching	CM-2 Baseline Configuration, SI-2 Flaw Remediation	PR.PS-02	T1133
Supplier requirements and DaaS services	SA-4 Acquisition Process, SA-9 External System Services	GV.SC-05, GV.SC-06	T1199 Trusted Relationship

NIST SP 800-46 Rev. 2 covers remote access and BYOD security more broadly and expects every component, including client devices, to be secured against the threats in your threat model. CIS Controls v8.1 Control 6 (Access Control Management) and Control 15 (Service Provider Management) are the closest control-level fits.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for remote access and identity programmes. Browse vendors in our products directory or contact us about independent evaluation support.

Security Requirements for Selecting VDI and Desktop-as-a-Service: Criteria, Vendor Questions and Pilot Tests