Citrix SecurSpaces™

Layered controls with the Citrix platform

SecurSpaces enforces its own controls on the development environment. It also runs inside the wider Citrix platform, so the access layer in front of a workspace can carry controls of its own.

This page separates the two, so you can see which control comes from where when you are assessing coverage or closing a specific gap.

What SecurSpaces enforces

These are properties of the platform itself and apply however a developer reaches a workspace.

Control What it enforces
Source code isolation Code stays in the workspace and is never cloned to the endpoint
Credential brokering Repository and service credentials are held by the platform and injected at runtime, rather than stored on the developer’s machine
Clipboard control Copying out of the IDE or the secure browser can be blocked
Workspace app confinement An application published from a workspace can be required to open only in a secure browser
Network egress policy Outbound traffic is restricted to approved repositories and domains, enforced at the proxy
Audit Every action is recorded and can be exported to a SIEM

See the control catalogue for the full set with identifiers.

What the access layer adds

SecurSpaces integrates with the Citrix components you may already run, rather than introducing a second access stack. Each governs the path to the workspace, not the workspace itself.

Component What it governs
Citrix DaaS Delivery of desktops and published applications, including reaching a workspace from a VDA
Secure Private Access Zero-trust access to private applications, including device posture and conditional access before a session starts
Chrome Enterprise Premium Browser-level controls on the session itself, such as restrictions on printing, screenshots, and file transfer
Citrix Workspace A single entry point to all of the above

For what each of these enforces and how to configure it, see that product’s own documentation. This page describes only how they relate to SecurSpaces.

Where the layers matter most

Two cases where an access-layer control closes something SecurSpaces cannot close on its own.

Remote development over SSH. When a developer connects a local IDE over SSH, the workspace controls still apply to the environment, but the session terminates on a machine SecurSpaces does not govern. Clipboard and file-transfer restrictions that depend on the browser do not apply. Where that matters, either restrict SSH access by role, or govern the endpoint through the access layer. This limitation is stated in the control catalogue as SDS-DLP-01.

Unmanaged and contractor devices. SecurSpaces keeps source code off the device, which is the larger part of the risk. Controls on what the user can do with the rendered session — screenshot, print, copy to a local application — belong to the browser or the access layer rather than to the workspace.

Licensing

SecurSpaces is included in the Citrix Platform License, with no new SKU and no user limit. Entitlement for the other components above depends on your agreement — confirm what your organization holds with your Citrix account team before you plan a design around them.

Layered controls with the Citrix platform