A thin client is a small, low-cost terminal that does almost no computing of its own; instead it displays the screen of an HMI or SCADA session that is actually running on a central server, and sends back the operator's keyboard and mouse input. Because the terminal holds no application, no data, and little configuration, it is cheap to buy, trivial to replace, and easy to secure, which is why control rooms increasingly put thin clients on the floor rather than full workstations. This guide defines the thin client, contrasts it with thick or fat clients and with zero clients, and explains the reasons operators favour the model, from centralized patching to keeping sensitive data off the plant floor.
Thin Client in one line: A thin client is a stateless endpoint device that runs little or no application software locally and instead connects to a central server that does the real work, presenting the server's session on the terminal's screen. In a SCADA context, the HMI or SCADA software runs on a server, and the thin client simply renders that remote session and relays the operator's inputs. Because the terminal stores no data and holds no application state, it can be swapped out in minutes, patched centrally by updating the server, and kept free of the sensitive information that a full workstation would hold locally.
The defining feature of a thin client is that the work happens somewhere else. The HMI or SCADA application, its configuration, and its data all live on a central server, and the thin client's job is only to display what that server draws and to send back what the operator types and clicks. The heavy lifting, running the graphics, polling tags, driving alarms, is done on the server, and the terminal handles the comparatively light task of drawing the screen and forwarding input over the network. This is why the device can be modest hardware: it does not need the processing power, memory, or storage to run the control application itself, because it never does.
Statelessness is the crucial property that follows. Because the thin client holds no application state and no meaningful data, one terminal is interchangeable with another; if a unit dies, you unplug it and plug in a replacement, and the operator logs back into the same server session with nothing lost, because nothing of value was on the failed terminal in the first place. The session, its history, and its data were always on the server. This turns the endpoint into a commodity, a pane of glass onto a server-side session, and it is precisely that commodity nature that delivers the operational and security advantages control rooms are after. The terminal on the desk becomes almost disposable, while everything that matters is consolidated and protected on the server.
The thin client is best understood against its opposite, the thick client, sometimes called a fat client. A thick client is a full workstation that runs the HMI or SCADA application locally, holding the software, configuration, and often cached data on its own disk, and doing its own processing. It is powerful and works even if the server is unreachable, but each thick client must be patched, updated, licensed, and secured individually, and each holds data locally that could be lost or stolen if the machine is compromised or removed. Managing a room full of thick clients means managing many independent, stateful machines, each a small administrative and security burden in its own right.
At the other extreme from the thick client sits the zero client, an even more stripped-down terminal than a thin client. A thin client usually runs a minimal local operating system just capable enough to establish and manage the remote session, whereas a zero client has essentially no configurable operating system at all, often just firmware that connects to a specific remote protocol and does nothing else. The zero client trades the small flexibility of a thin client for even lower cost, an even smaller attack surface, and near-zero local management, since there is almost nothing on the device to patch or misconfigure. The three sit on a spectrum: thick clients do everything locally and carry the most weight to manage, thin clients push the work to a server while keeping a slim local operating system, and zero clients push nearly everything away and keep almost nothing. Control rooms choose along that spectrum based on how much they value local independence versus centralized simplicity and security.
The reasons operators adopt thin clients cluster around management, security, and cost, and each flows from the same fact that the terminal holds nothing. Patching and updates happen centrally: you update the HMI software once on the server rather than touching every workstation on the floor, which is a large saving in effort and a large gain in consistency, since every operator is guaranteed to be looking at the same, current software. Replacing failed hardware is fast and low-skill, because a new thin client needs only to be pointed at the server, with no application to reinstall and no data to restore. And because the terminals are inexpensive, standardising on them across a large control room or many field offices is affordable.
Security is often the deciding factor in OT. Keeping no data at rest on the floor means a terminal that is stolen, tampered with, or physically accessed by an unauthorised person yields nothing, because the sensitive process data and credentials live on the protected server, not on the endpoint. The endpoint's tiny software footprint also gives it a small attack surface, and centralised patching means it stays current without depending on someone remembering to update a floor machine. This model pairs naturally with cloud SCADA and virtualized servers: when the HMI or SCADA runs on a hardened central or hosted server, thin clients across the control room and at remote field offices all reach the same authoritative session, and a platform such as Merobix, delivered through the browser, extends the same idea further, since any device becomes a light window onto the hosted system with nothing stored locally. Whether the session runs on an on-site server or in the cloud, the thin-client philosophy is consistent: keep the intelligence and the data central and protected, and make the thing on the operator's desk as simple, cheap, and replaceable as possible.
A thick client, or fat client, is a full workstation that runs the HMI or SCADA application locally and stores software and data on its own disk, so it works even if the server is down but must be patched and secured individually. A thin client runs almost nothing locally and instead displays a session running on a central server, holding no application or data. The thin client is cheaper, easier to replace, and simpler to patch centrally, at the cost of depending on the server and network.
A thin client runs a minimal local operating system, just enough to manage the connection to the remote server session. A zero client goes further and has essentially no configurable operating system, usually just firmware that connects to a specific remote protocol and nothing else. The zero client gives up the thin client's small flexibility in exchange for even lower cost, a smaller attack surface, and almost no local management, since there is nearly nothing on the device to patch or misconfigure.
Thin clients let operators patch and update the HMI software once on the central server rather than on every workstation, replace failed terminals quickly with no reinstall, and standardise on cheap hardware. Critically for OT security, they keep no data at rest on the plant floor, so a stolen or tampered terminal yields nothing because the sensitive data and credentials stay on the protected server. Their small software footprint also gives a reduced attack surface, making the whole control room easier to keep secure and current.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.