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.