SCADA on Thin Clients: Architecture, Risks, and Best Practices

Overview

Thin client computing centralizes applications on a server while delivering keyboard, video, and mouse (KVM) over Ethernet to inexpensive endpoint devices. In an office environment, this architecture reduces patch management burden, hardens endpoints, and lowers total cost of ownership. In a plant environment, where the same machine often hosts an HMI/SCADA workstation tied to PLCs over Ethernet or serial, the architecture creates new failure modes that do not exist on a fat client. A computer terminal that depends on the host for processing is functionally a thin client, regardless of whether the link is serial RS-232 or modern RDP/ICA over TCP.

The principal question an automation engineer must answer is not "can the SCADA vendor's HMI render over Remote Desktop Services or Citrix?" but "does the application survive when the server, the network, the licensing server, the print spooler, the Windows update cycle, and the terminal session all become shared resources?" This article documents the engineering constraints, the network segmentation pattern that mitigates risk, the specific Wonderware InTouch compatibility boundaries, and the bench-test procedure that must precede any production deployment.

Thin Client vs Fat Client Architecture

A thin client depends on a host computer for processing power, storage, and application logic. Modern thin clients typically run HP ThinPro, Dell Wyse ThinOS, IGEL OS, or Windows 10 IoT Enterprise and connect to a Windows Server running Remote Desktop Services (RDS), Citrix Virtual Apps and Desktops, or VMware Horizon. The endpoint renders only pixels and forwards input events.

For a desk operator monitoring non-critical trends, the latency budget of a well-tuned session is acceptable. For a maintenance engineer launching PLC programming software, downloading firmware, or recovering from a fault, the latency and the loss of physical I/O become unacceptable.

Network Segmentation: The Purdue Model

The defense-in-depth pattern that consistently survives IT/OT collisions is the Purdue Enterprise Reference Architecture (PERA), formalized in ISA-99 / IEC 62443. The plant is divided into five levels (0-4), and the IT/OT boundary is anchored at the Industrial Demilitarized Zone (IDMZ) between Level 3 (Operations) and Level 4 (Enterprise).

Implementation rules for an SCADA workstation that may end up on a thin client:

1. Level 0-2 (process, basic control, supervisory control) is a plant-owned, broadcast-limited, IT-independent network. Switches, VLANs, and firewalls are owned by engineering or maintenance, not IT.
2. Level 3 hosts SCADA servers, historians, and engineering workstations. This is the only network that may run a terminal server farm if thin clients are used.
3. The IDMZ between Level 3 and Level 4 contains a data diode or dual-firewall pair. Only whitelisted ports (typically OPC UA TCP 4840, Modbus TCP 502, or DNP3 20000) traverse it.
4. Thin client endpoints, if deployed, sit on Level 3 alongside the SCADA servers. They do not sit on the office LAN.
5. IT owns the server OS, anti-virus, and RDS broker. Engineering owns the SCADA application, I/O drivers, and tag database. A written change-control board manages who can patch what and when.

Wonderware InTouch on Terminal Services: Compatibility Boundaries

Wonderware InTouch (now AVEVA InTouch HMI) has shipped since 1989. Compatibility with Windows Server and Terminal Services has evolved with the product line.

The critical distinction is View Node vs. Development Node. The View Node (WindowViewer) is a run-time-only application that displays the HMI graphics. It is licensed by tag count and is the part that can be hosted on a terminal server. The development environment (WindowMaker) is a per-engineer licensed product that requires a local, full-admin Windows session. Running development on a thin client works in principle but is slow and uncomfortable for any application beyond a few hundred tags.

Serial Port and Hardware I/O Constraints

Most legacy SCADA architectures include at least one workstation with a real RS-232 or RS-485 port connected to a PLC, a panel meter, a barcode reader, or a scale. RDP and Citrix virtual channels can pass COM port traffic to the session, but the redirect is implemented in the endpoint's RDP/ICA client and frequently fails for industrial protocols that use long inter-character timeouts, 9-bit data, or hardware handshaking.

• Allen-Bradley DF1 full-duplex on COM1: works over RDP serial redirect on Windows 10 endpoints with the Microsoft RDP client, fails on most Linux thin clients (HP ThinPro, IGEL) unless a vendor-specific redirector is installed.
• Modbus RTU over RS-485: timing-sensitive; degrades to timeouts at 100 ms+ RDP latency.
• Siemens MPI/PROFIBUS on USB-to-serial adapters: never reliable over RDP redirect; the adapter must be mapped on the session host, not the endpoint.

Mitigation: deploy a terminal server with a multiport serial card (e.g., Digi Neo PCIe, Moxa CP-118U-i) and map the on-board COM ports to the RDS session. The thin client endpoints have no serial hardware at all.

Administrator Rights and Application Licensing

IT-led thin client deployments default to standard-user accounts with no local admin. The following functions break under that model:

1. Installing or upgrading the InTouch run-time, I/O drivers (DAServer, ABCIP, KEPware), or Wonderware Application Server.
2. Modifying the Galaxy or ArchestrA database.
3. Registering OPC COM/DCOM components; DCOM defaults are tightened by Group Policy and break remote OPC calls.
4. Editing the Windows hosts file or LMHosts for legacy NetBIOS resolution to PLCs such as an Allen-Bradley SLC 5/05 or PLC-5.
5. Running PLC programming software (RSLogix 500, Studio 5000, TIA Portal) which demands local admin to install EDS files and to access the network driver stack.

The accepted compromise is a two-tier account model: a standard user account for day-to-day View Node operation, and an engineering account that is a member of the local Administrators group on the session host, invoked by IT only on a service-desk request. This preserves IT's audit trail and gives engineering the access it needs.

Bench-Test Procedure Before Production Cutover

Any SCADA-on-thin-client cutover must pass a bench test in a controlled environment before touching a live line.

Prerequisites

• Identical or near-identical hardware: the same endpoint model, the same session host model, the same RDS/Citrix version, the same InTouch build number, the same anti-virus product.
• A representative I/O load: at least one PLC over Ethernet (e.g., Allen-Bradley SLC 5/05 with EtherNet/IP or ControlLogix with CIP), and at least one serial device on a redirected COM port.
• A scripted fault injection list: kill the session host, kill the RDS gateway, force a Windows Update reboot, drop the network for 30 seconds, exhaust the session host's RAM.

Step-by-Step

1. Stand up the session host on a test VLAN. Join it to a test AD domain. Install RDS, Citrix VDA, or VMware Horizon Agent.
2. Install InTouch, license the WindowViewer, and deploy a sample application with the same tag count as production. Verify the View Node launches and the I/O driver (DAServer, KEPware, or RSLinx) initializes inside the session.
3. Connect one thin client endpoint. Log in. Launch the View Node. Record the screen-render latency with a 1080p30 frame-rate counter and a stopwatch on a tag-spoof event.
4. Connect a second, third, and up to the maximum supported concurrent sessions. Verify the InTouch license server grants all sessions. Monitor session host CPU, RAM, and disk I/O at peak.
5. Force a session disconnect (close the RDP/ICA window). Verify the View Node re-establishes I/O within 10 seconds. Verify no orphaned COM port handles.
6. Apply a Windows Update batch and reboot the session host. Verify users fail over to a second session host (or accept the planned outage window).
7. Inject a network outage of 30 seconds between the endpoint and the session host. Verify the View Node does not lock up; if it does, tune the I/O driver's timeout and retry parameters.
8. Document the result. Sign-off by engineering, IT, and production.

Verification Checklist

Troubleshooting Matrix

Field-Proven Caveats

• A Windows 10 or Windows 11 engineering laptop with a local install of InTouch and the engineering license is not redundant to a thin client; it is the recovery path. If the session host fails, the laptop is the only way to bring the line back in under an hour. Maintain at least one per shift.
• Anti-virus on the session host must exclude the InTouch, KEPware, and DAServer executable paths. Real-time scanning of a 50,000-tag database write causes tag flicker and CPU spikes that look like network faults.
• Do not let IT enforce screen-lock Group Policy at the standard 15-minute idle timer. Operators monitoring a process for 8 hours straight will be locked out, the session will suspend, and the View Node will stop updating.
• Citrix-published InTouch on a Windows Server 2019 or 2022 session host with Citrix Workspace App 2309 or later is the most stable combination observed in 2023-2024 field deployments. Older Citrix Receivers (pre-Workspace) have broken serial redirect on Linux endpoints.
• For Allen-Bradley SLC 5/05 and PLC-5 Ethernet communication, RSLinx or KEPware must run on the session host, not on the thin client endpoint. CIP routing across the IDMZ is not supported.