What is a thin client and what does it change for security?

A thin client is a lightweight device or program that displays and controls a desktop or application running on a server, doing little processing itself. For security it shrinks the endpoint, since little data is stored locally, and concentrates risk on the remote session protocol, the identity check and the servers behind it.

How does a thin client work?

The client sends keyboard and mouse input to a server. The server runs the software and sends back what the screen should show. A small, old and well documented example is the Remote Framebuffer protocol, RFB, specified in RFC 6143. It is described as a simple protocol for remote access to graphical user interfaces that lets a client view and control a window system on another computer. It works at the framebuffer level, so it applies to any windowing system. RFB is the protocol used in VNC.

Modern products use richer protocols with audio, printing, clipboard and device redirection, but the basic idea is the same. Pixels go one way, input goes the other, and the applications and files stay in the data center or cloud.

What do you gain?

Less data on the device. A stolen thin client holds little that matters, because documents and credentials sit on the server. Patching is also simpler. You update a central image and every user gets it at their next session, instead of chasing hundreds of laptops.

You also get a narrower attack surface on the endpoint. A fixed-function device with a locked-down operating system has fewer things to exploit than a general laptop with local admin rights and a pile of browser extensions.

What do you take on?

The risk moves, it does not vanish.

First, the session protocol becomes critical. RFC 6143 is blunt about this. It says the protocol as defined provides no security beyond an optional and cryptographically weak password check, and no protection against observation of or tampering with the data stream. It suggests running sessions over a secure channel such as IPsec or SSH. Many modern remote display protocols add encryption, but you should confirm that for the one you use instead of assuming.

Second, the servers become a shared target. One compromised host can expose many users' sessions, so isolation, patching and monitoring of the session hosts matter more than any single device.

Third, identity carries the load. If anyone with a stolen password can open a session, the thin client form factor offers no help. Multi-factor authentication on the gateway is the minimum.

Fourth, features that connect the session to the device, such as clipboard sharing, file transfer and USB redirection, can undo the data containment you wanted. Each one is a policy choice to make on purpose.

A constructed example

A call center replaces 200 desktops with thin clients that connect to virtual desktops. The clients boot a fixed image and have no local storage. The team disables clipboard and drive redirection for agents who handle payment data, requires MFA at the gateway, and puts the session hosts in their own network segment with outbound traffic limited to the case management system. When one agent's password is phished, the attacker can reach a session only after passing MFA, and even then can copy nothing out through the clipboard.

How to check or apply this

1. Identify which remote display protocol you use and read how it encrypts and authenticates. Do not assume.
2. Put MFA in front of the session gateway.
3. Turn off clipboard, file and USB redirection by default. Enable per group with a reason.
4. Segment session hosts and restrict their outbound access.
5. Keep the client operating system minimal, locked and centrally updated.
6. Patch and monitor the session hosts as high-value servers.

Quick check

Sources

• RFC 6143, The Remote Framebuffer Protocol
• RFC 4301, Security Architecture for the Internet Protocol
• CISA Cyber Essentials

Last reviewed: 18 October 2026.