A thin client is a compact computer designed for a single purpose: accessing applications and resources stored on a remote server. There is no heavy local processing and no sprawling local storage. The device is a window, and the work happens somewhere else.
You find them everywhere. Doctors use them in clinics. People working in banks use them at their desks. Operators use them on factory floors. They quietly run reception counters, call centers, and control rooms across countless industries.
Thin clients have become part of the digital workspace that many modern organizations are actively adopting. The model is straightforward: an organization’s data is stored centrally, in a data center or in the cloud, and employees connect to their virtual desktops remotely, often through exactly such a device.
The promise of the digital workspace
Centralizing information this way has real advantages. It scales easily, and it makes management flexible and centralized. Instead of maintaining hundreds of individual machines, an organization manages one pool of virtual desktops and hands out lightweight windows to reach them.
It looks tidy on an architecture diagram. Data stays put, devices stay cheap, and administration stays in one place.
The endpoint nobody watches
An important reason for this, oddly enough, is the lack of attention paid to endpoint security. The server, the data center, and the network are often hardened and audited. The little box sitting on the desk, the actual point where a human touches the system, tends to be taken for granted.
That oversight has consequences. We conducted a study and found more than ten different attack scenarios involving thin clients.
What it means for a business
None of this is abstract. Consider a contractor that provides remote services to its customers, such as equipment maintenance.
One of its engineers remotely connects to the server of one of its smaller customers. That customer’s server turns out to be infected, and as a result the contractor’s thin client becomes infected too, for example through a vulnerability in a thin client component. The engineer then uses that same infected machine to connect to the server of another customer, a large industrial company. Now the attacker can perform any action in the engineer’s name, up to and including disrupting technological processes.
This is not hypothetical: Norsk Hydro, 2019
Norsk Hydro, a large Norwegian aluminum company, was hacked in 2019. The entry point was probably an RDP server in the virtual desktop infrastructure. As a result, 22,000 computers in 40 countries were infected. Production halted at several sites and supply chains suffered. The total loss was estimated at 65 million dollars.
Why patching alone cannot keep up
How do you prevent incidents like these? The usual answer is patching. Experts discover a vulnerability, the vendor releases a patch, the owner installs it, and the cycle repeats endlessly.
But this reactive approach makes it almost impossible to keep pace with attackers who move faster every year. By the time one hole is closed, three more are open.
So the focus has to shift: from covering every vulnerability in time, to making vulnerabilities, known and unknown, genuinely hard to use. For that, security must become an inherent part of the system design rather than a layer bolted on afterwards.
This is the idea behind the secure by design philosophy and, more specifically, the Cyber Immunity approach, which explains exactly how to put it into practice. It provides a methodology for organizing the development process and defining what each step should produce, along with design requirements for building a system that is secure by construction, cost-effectively.
Where Boot2Desk comes in
Boot2Desk is a practical attempt to turn those principles into a concrete operating system: a temporary, security-focused desktop built on Debian 13, designed so that an intruder has as little room to work with as possible. Read the full Boot2Desk article.
Applied to a thin client, this philosophy protects the one thing that matters most: a secure connection to a remote server. Because the security is part of the architecture, even compromising one component does not automatically violate the system’s critical properties. The attack has somewhere to land, but nowhere to spread.
The design decisions are deliberate, and each one removes a path an attacker would otherwise use:
- Running entirely from RAM The OS loads into memory, and the session is never written permanently to disk. Switch the machine off, and the state is gone.
- No persistent storage No persistent overlay and no hidden partition quietly keeping the user’s changes between reboots. If information shouldn’t survive the session, the system shouldn’t have a mechanism for keeping it.
- Restricted access to internal drives Boot2Desk cannot reach or write to SATA, NVMe, and eMMC devices, limiting local data exposure and the traces malicious code can leave behind.
- Isolated applications Firejail sandboxes programs like Firefox ESR and Remmina, AppArmor limits what each process can reach, and seccomp filters the system calls they may make.
- A strict network policy nftables enforces a deny-by-default firewall that blocks inbound connections and limits outbound traffic, with no unnecessary services or background chatter.
- A build that can be reviewed The system is assembled locally from public Debian sources, so configurations, package lists, and security rules are open to inspection before the image is ever built.
A secure system should never depend on a single safeguard. If one protection is bypassed, the rest of the system should not automatically be exposed. That is why Boot2Desk stacks several independent barriers instead of trusting one. The goal is not only to detect an attack, but to limit what an attacker can actually do once something goes wrong.
Where this makes a difference
A temporary, tightly restricted desktop helps wherever the machine or its surroundings cannot be fully trusted:
- Consultants and contractors handling sensitive information across many customer environments
- Remote access while traveling or on public networks
- Shared workstations and educational environments
- Incident response, where a known clean boot environment is essential
- Industrial and high-security settings, where a computer serves as a limited access point to other systems
What these cases share is the need to get a job done without leaving unnecessary local data behind, and without granting the session more privileges than the task requires.
Making attacks harder from the start
Cybersecurity should not only be about reacting faster once something has happened. It should also be about building systems where as little as possible can go wrong, and where a single failure does not bring the whole thing down.
No single measure guarantees that a system will never be compromised. But by cutting down the number of possible attack paths, neutralizing a significant share of the attacks aimed at thin clients, and limiting the consequences of an intrusion, we make it far harder for an attacker to succeed.
Boot2Desk does not replace the rest of a security effort. The physical environment, user behavior, network design, and the systems you connect to all still matter. But by reducing persistent state, restricting resource access, and isolating applications, several common risks are lowered already at the design stage.
That is the idea at the heart of Boot2Desk: a computing environment built to do its job, leave as little behind as possible, and start over from a clean state on the next boot.