The customer designs, manufactures and services onsite power systems that keep data centers and other large-scale industrial facilities running. Its own factory floor runs on a mix of Windows-based PLC controllers and VNC-connected equipment — machinery that is serviced not only by internal engineers but by third-party vendors, including original equipment manufacturers who support it from overseas. Getting those people to the one machine they need, and nowhere else, is the job Kasm Workspaces now does.
A flat network and a vendor-access problem
Vendor access was the core problem. The customer's OT network was flat, with no meaningful segmentation between manufacturing sites or between vendor tenants. When an external vendor needed hands-on access to troubleshoot or commission a piece of equipment, the existing approach gave them something closer to a full employee footprint than to the single device they actually needed to touch. Every vendor session was a potential path for lateral movement across the network.
The incumbent remote-access tool, built for general-purpose VPN access, was never designed for granular, device-specific OT use. As the environment scaled across multiple sites, the security and IT teams needed to:
Give external vendors and internal staff access to specific PLC and VNC endpoints, without exposing anything else on the network- Enforce least-privilege, need-to-know access so one vendor’s session could never reach another vendor’s equipment
- Support RDP, VNC and secure web applications through a single, consistent access layer
- Scale the architecture across distributed sites without rebuilding it site by site
- Do all of this on a network that had never been formally segmented or documented
Why Kasm: isolation enforced by the access layer, not the network
The customer's IT and security teams evaluated Kasm Workspaces as a replacement for legacy VPN-based access, working with a Kasm implementation partner to run a structured proof of concept on three priority manufacturing use cases: vendor access to Windows/VNC hosts running PLC software, controlled access to internal Kasm tool instances, and VNC access to other floor equipment.
The model Kasm offered was an inversion of the incumbent's. Instead of placing a vendor on the network and then trying to constrain where they could go, Kasm places them in a single, policy-scoped workspace and translates protocol to exactly one endpoint. Because isolation is enforced through group policy and security zones, the customer did not have to segment and document its flat network before improving its security posture.
WHERE THE INCUMBENT FELL SHORT
- General-purpose VPN access with no device-level scoping for OT endpoints
- No tenant isolation — one vendor’s session could reach another vendor’s equipment on a flat network
- No single access layer for RDP, VNC and web applications
- Scaling to new sites meant rebuilding access site by site
What they built: a single-zone PoC that became the production foundation
Phased, single-zone proof of concept
Rather than attempting a full multi-site build on day one, the team started with a single-zone deployment: the Kasm web application and database hosted in AWS, proxying directly to the customer’s existing Windows and VNC endpoints. This validated the core access pattern — authentication through a secure web gateway, protocol translation to the target device, and session-level isolation — before any architectural complexity was added.
Protocol translation and connection proxies
Kasm’s connection proxy component handles protocol translation between the web-native session a vendor initiates and the RDP or VNC protocol the target machine requires. Vendors never need direct VPN-level network access; they authenticate once at the Kasm gateway and are proxied only to the specific workspace they are authorized to reach.
Tenant isolation through security zones and group policy
To prevent lateral movement between vendors, the solution uses Kasm’s group-policy model to define security zones per workspace. Each group of users — internal engineer or external vendor — is scoped to specific workspaces with defined network access, available tools and data-loss-prevention controls. One vendor’s tenant has no visibility into another’s, satisfying the customer’s core security requirement without a network redesign up front.
Vendors and internal staff now reach specific OT endpoints through a single, auditable access layer — with no direct network exposure.
A path to multi-site scale
As the customer moves from PoC to production, the architecture extends from a single zone to a multi-zone model: a centralized web application and control plane, with dedicated connection proxies deployed at each manufacturing site. Sessions route to the lowest-latency proxy for the requested resource, so the deployment scales by adding proxies and agents rather than by re-architecting the core.
Critically, the PoC infrastructure carried forward. The customer’s cloud engineering team confirmed that the AWS-hosted deployment could become the production control plane rather than being rebuilt — a decision that directly reduced the professional-services scope needed for the production rollout.
A modernization path for legacy Windows applications
In parallel with the primary remote-access use cases, the team scoped a modernization track: packaging legacy Windows manufacturing applications into containerized, on-demand workspaces using Kasm’s agent architecture. This gives the customer a longer-term option to reduce its dependence on full Windows VM sessions in favor of positive-security, purpose-built application delivery on the same platform.
Results
| Metric | Before | With | Impact |
|---|---|---|---|
 Vendor access scope | Near-employee network footprint via general-purpose VPN | Single authorized workspace, proxied to one endpoint | Lateral-movement path closed |
 Tenant isolation | None — flat network, no segmentation between vendors | Security zones and group policy per workspace | Enforced without network redesign |
 Priority OT use cases | Unsupported by incumbent tool | PLC/VNC hosts, internal tool instances, floor equipment | 3 of 3 validated |
 Legacy VPN access for OT | Primary remote-access method | Retired site by site as use cases onboard | Full retirement targeted in 1–2 months |
 Multi-site scale | Rebuild per site | Central control plane; add proxies and agents per site | Scales without re-architecting |
Production hardening is underway: SSO/MFA integration and a formal architecture review are closing a documentation gap that predated the engagement. Looking ahead, the customer plans to expand Kasm coverage to its remaining sites, formalize a managed-services arrangement with a Kasm partner for day-to-day administration, and continue the containerization track to modernize legacy Windows applications used on the factory floor.
