Compartmentalisation: when Qubes OS and Whonix are the right step

Desktop-level compartmentalisation — splitting tasks into isolated virtual machines — is one of the heaviest security measures an individual can implement independently. It is also one of the most over-recommended: too often suggested for people for whom a well-hardened ordinary laptop is already more than enough.

This guide helps you decide whether this step is justified for your situation, how to choose between the available approaches, and what a realistic first deployment looks like.

When compartmentalisation actually makes sense

VM-level compartmentalisation protects against a specific threat scenario: an adversary who has already gained access to one context on your system — through a compromised application, a malicious document, or a rogue website — and is trying to reach other contexts from there.

This scenario is real for:

• journalists and activists who work daily with sensitive sources, and for whom the separation between work, anonymous activities and private life is operationally critical
• researchers and analysts who regularly open untrusted files or websites as part of their work
• people facing a concrete threat of targeted attacks by a well-motivated adversary — state actors, organised crime, lawfare scenarios

Compartmentalisation is not the right tool if:

• your main risks are account takeovers, phishing or data breaches — hardware 2FA, a password manager and good account hygiene are the right tools for those
• your system is not yet encrypted or your password management is weak — fix those layers first
• you do not have the technical willingness to manage a system that demands more than a regular laptop — a half-configured Qubes system you do not understand is not an improvement

The threshold is concrete: do you have a daily working situation where cross-context contamination is a realistic risk, and are you willing to carry the operational load? Then this is the right route. Otherwise a well-hardened Linux or a well-configured macOS/GrapheneOS setup is a better investment of your time.

What compartmentalisation does and does not solve

What it solves:

• a compromised browser in an untrusted qube cannot reach your documents in work
• a malicious PDF you open in a separate qube cannot reach your real network or other qubes
• identities remain technically separated, even on one physical machine

What it does not solve:

• a weak password, a compromised email account, or social engineering
• metadata you inadvertently reveal through your activities
• physical access to the machine — encryption does that job, not compartmentalisation
• behavioural mistakes: if you copy information yourself between contexts that should stay separate, the technical separation does not help

Compartmentalisation protects the boundaries between contexts. It does not protect against mistakes within a context, and it is not a substitute for good account security and operational discipline.

The three approaches: Qubes, Whonix and Tails

Qubes OS — daily compartmentalisation

Qubes OS is an operating system that uses virtualisation as its core, not as an extra layer on top. Each task runs in its own isolated environment (a “qube”), but all windows appear on one desktop. The underlying Xen hypervisor provides the separation.

When Qubes is the right choice:

• you want to work daily with clearly separated contexts on one laptop
• you have adequate hardware (see below) and the willingness to manage a more complex system
• you have a concrete threat model where cross-context compromise is a realistic risk

When Qubes is not the right choice:

• you occasionally need an anonymous session — use Tails
• you only want Tor routing without cross-contamination — use Whonix on a regular Linux
• your hardware does not meet the requirements, or you do not have time for the maintenance

See the Qubes OS review for a detailed assessment of suitability, hardware requirements and daily use.

Whonix — architectural IP leak protection

Whonix works through two virtual machines: a Gateway that routes all network traffic through Tor, and a Workstation where you actually work. The Workstation has no direct internet access — only through the Gateway. Even if the Workstation is fully compromised, your real IP address cannot leak, because the Workstation never knew it.

Whonix is most commonly used as part of Qubes OS, but can also run on a regular Linux hypervisor (KVM, VirtualBox).

When Whonix makes sense:

• you have a situation where IP leak protection needs to be architecturally guaranteed, not dependent on application behaviour
• you work daily from a fixed Tor environment — journalists with source contact, researchers in high-risk areas
• you are already using it inside Qubes as an additional isolation layer for the most sensitive contexts

See the Whonix review for a comparison with Tails and an assessment of the architecture.

Tails — amnesic sessions without traces

Tails is a different kind of tool: it runs from a USB stick, leaves no traces on the host machine by default, and forgets everything after each session. Every application goes through Tor.

When Tails is the right choice:

• you occasionally need an anonymous session without persistent traces
• you are working on a machine you do not fully trust
• you do not want to manage a permanent Qubes system but do need strong occasional anonymity

Tails is not a replacement for Qubes as a daily system, and Qubes is not a replacement for Tails when you specifically want no persistence. They complement each other.

Summary: how to choose

Situation	Approach
Daily work, keeping multiple identities separated	Qubes OS
Structural IP leak protection for daily Tor use	Whonix (inside Qubes or standalone)
Occasional anonymous session, no traces	Tails
All three needed simultaneously	Qubes + Whonix qube + Tails USB alongside

A realistic first deployment of Qubes OS

Hardware

Qubes OS is demanding. Practical minimum requirements:

• RAM: 16 GB — 8 GB is insufficient for multiple qubes running simultaneously
• CPU: Intel with VT-x and VT-d, or AMD with AMD-V and AMD-Vi/IOMMU — required for PCI passthrough and hardware isolation
• Storage: SSD, at least 128 GB — Qubes uses significantly more disk space than a regular Linux installation
• Before buying: check the HCL (Hardware Compatibility List) for your specific laptop before installing

Not all hardware works well. A laptop not on the HCL can have problems with graphics drivers, network hardware or suspend/resume.

First setup: what runs in which qube

Start with the default qubes Qubes OS creates, and only add more once you have mastered that baseline:

• personal — private matters, trusted websites, personal email
• work — work-related tasks, but nothing that needs to be anonymous
• untrusted — everything you do not trust: unknown links, downloads, suspicious attachments
• vault — offline vault with no network, for passwords, keys, sensitive documents. This is where your KeePassXC runs.

Do not configure a network connection on vault. Only copy things to or from vault deliberately — via the built-in inter-qube clipboard (Ctrl+Shift+C / Ctrl+Shift+V).

Operational discipline that makes the system work

The technical separation is only effective if you also respect the boundaries behaviourally:

• open suspicious attachments always in untrusted, never in work or personal
• never copy files from a low-trust qube to a high-trust qube without thinking deliberately
• treat each qube as a separate computer in terms of what you do and do not put in it
• use sys-net and sys-firewall as they come; do not change them until you understand what they do

Why people fail with Qubes

Too many qubes at once. Start with four. Add more only once you understand the basics. A system with twenty qubes you can no longer overview is not an improvement.

Hardware that does not work properly. Check the HCL before buying or installing. A laptop that does not wake from sleep, a wifi card that does not work, or a graphics driver that crashes makes the system unusable.

Underestimating the maintenance. Qubes requires updates at multiple levels: dom0, each TemplateVM, and individual qubes. If you defer updates for weeks, the system falls behind. That undermines the exact purpose.

Treating Qubes as the only defence layer. Qubes protects the boundaries between contexts. If your account security is weak, you reuse passwords, or you open phishing emails without thinking, Qubes does not fix that.

No fallback. If you use Qubes as your only system and it crashes or you forget a password, you are locked out. Keep a backup of your vault contents on a separate encrypted medium.

Stopping point: when to stay on regular Linux

Qubes is the right choice for people with a concrete compartmentalisation need. For everyone else, a well-configured Linux — with full disk encryption, strong account security, hardware 2FA and good browser hygiene — is a better use of the available time and attention.

If you are unsure whether Qubes is necessary, the answer is probably no. That is not a weakness — it is an honest assessment of your threat model.

Next step

Evaluate the tools

• Qubes OS review — hardware requirements, daily use, pros and cons
• Whonix review — the two-VM architecture, comparison with Tails

Make sure the basics are in place first

• Secure laptop guide — if you are not yet sure whether Qubes is the right next step
• VeraCrypt: encrypted storage — for the vault qube and external storage
• Hardware security keys — account security that complements Qubes, not replaces it

Use this in context

• Profile: high risk — if compartmentalisation is part of a broader operational approach
• Profile: journalist and activist — if source protection is the reason for making the switch