Tails vs Qubes vs Whonix: Which Secure OS Fits Your Threat Model?

Tails, Qubes OS and Whonix are the three desktop systems people reach for when an ordinary operating system is too risky. They solve different problems. Tails makes a computer forget you were there. Whonix keeps your real IP address away from the applications you run. Qubes keeps one activity from reaching another. This guide compares how each one works, what it needs, where it breaks, and which to pick. Versions, requirements and advisories were checked against tails.net, qubes-os.org, whonix.org and torproject.org on 10 November 2026.

How Tor itself routes traffic is covered in how Tor works; this page assumes Tor and compares the systems built around it. Where these three sit among the other privacy tools (messengers, disk encryption, Monero, coreboot) is in privacy tools by threat model. For a phone, see the GrapheneOS guide.

Three designs, three threat models

The rows that matter most are isolation and amnesia. Tails is the only one that forgets by default, and Qubes is the only one that compartmentalises everything. Whonix sits between them and fills one gap well: it makes a deanonymising IP leak impossible from inside the Workstation.

Tails: amnesic, Tor for everything

Tails is a Debian-based live system. Tails 7.0, released on 18 September 2025, was the first version based on Debian 13 (Trixie), and it raised the memory requirement from 2 GB to 3 GB. Since Tails 7.12 it has released every two weeks, following the Firefox and Tor Browser cadence. The Tor Project and Tails merged operations on 26 September 2024, and tails.net now states that Tails is made by the Tor Project.

Its design rests on three properties, stated on the How Tails works page and detailed in the Tails documentation:

• Amnesia. Tails never writes to the computer's hard disk and runs only from memory. At shutdown the memory is overwritten with random data, which is the defence against cold boot attacks; this applies to both a normal power off and an emergency shutdown (pulling the USB stick).
• Tor for everything. All connections go through Tor, including from software you install yourself. You cannot reach the internet until Tor connects; Tor Browser refuses connections until then. The documented exception is the clock sync described in step 4.
• Persistent Storage, if you want it. An optional encrypted partition fills the free space on the USB stick and uses LUKS. You choose what persists (documents, Wi-Fi passwords, bookmarks, additional software) and whether to unlock it each session. Tails warns that the partition is not hidden: someone holding the stick can see it exists and could pressure you for the passphrase.

A Tails session from boot to shutdown

1. Boot. Shut the computer down and start it from the Tails USB stick. Nothing on the internal disk is mounted or used.
2. Welcome Screen. Choose language and keyboard. If a Persistent Storage exists, enter its passphrase to unlock it; otherwise the session is fully empty. Under Additional Settings you can set an administration password, change MAC address anonymization, turn on Offline Mode or disable the Unsafe Browser. No administration password is set by default, and Tails does not let you add one after the session starts, so a compromised application cannot set one for itself.
3. MAC address anonymization. On by default: Tails replaces the MAC addresses of your network interfaces with random values for the session, so the local Wi-Fi does not see the laptop's real hardware address.
4. Tor Connection. After joining a network, the Tor Connection assistant offers two routes: connect automatically through a public relay, which shows the local network you are using Tor, or use a bridge to hide that you are connecting to Tor. Connecting automatically first sets the clock by contacting Fedora's captive portal check outside Tor, which Tails documents as an exception to its Tor-only policy; with a bridge you may have to set the clock yourself.
5. Work. Tor Browser, Thunderbird, OnionShare, Metadata Cleaner and LibreOffice are preinstalled. Anything saved outside Persistent Storage lives in RAM only.
6. Shutdown. Power off from the system menu, or pull the stick in an emergency (risking damage to Persistent Storage). Memory is wiped. The host computer keeps no record of the files, sites or networks from the session.

Tails' own warnings page adds the operational rule that matters most: use one session for one purpose. Logging into two accounts on the same site in one session lets the site link them, because both use the same Tor circuit. Restart Tails between activities, and consider a separate USB stick per identity if Persistent Storage could link them.

Tails hardware

Tails works on most PCs under ten years old with a 64-bit x86-64 processor, needs a USB stick of at least 8 GB and 3 GB of RAM to run smoothly. It does not work on Macs with Apple processors (M1, M2 and later), on ARM or PowerPC, on phones or on a Raspberry Pi. Nvidia and AMD Radeon graphics often fail; the project suggests refurbished business laptops such as the ThinkPad X250, T480 or T490.

Whonix: Gateway and Workstation

Whonix is two virtual machines built on Kicksecure, the project's hardened Debian. The Whonix-Gateway runs Tor. The Whonix-Workstation runs your applications on an isolated internal network whose only exit is the Gateway.

That split is the whole point. The Workstation does not know the computer's real external IP address, so a browser exploit, a malicious PDF reader or a misconfigured application that tries to connect around Tor has no route out. Whonix states that DNS, UDP, ICMP and IP leaks are impossible from the Workstation and that even malware with root privileges inside it cannot discover the user's real IP. Tails enforces Tor with a firewall inside one system; Whonix enforces it with a network boundary between two.

Whonix runs on a Type II hypervisor (KVM on Linux, VirtualBox on Windows, Linux and Intel Macs) or on Qubes as Qubes-Whonix. Outside Qubes, the minimum is 1 GB of free RAM (with the Gateway cut to 256 MB), 10 GB of disk and a CPU with VT-x or AMD-V; for best performance Whonix suggests 8 GB of RAM in total, budgeted as 2 GB for the host, 2 GB for the Gateway and 4 GB for the Workstation. On Apple Silicon, Whonix says running is still for developers only and no downloadable image exists.

Whonix keeps state between sessions like any VM. On KVM and VirtualBox you can pick Live Mode from the boot menu, which discards everything at the end of the session. Whonix lists Live Mode as unavailable on Qubes-Whonix.

Qubes-Whonix

On Qubes, Whonix arrives as two templates, whonix-gateway-18 and whonix-workstation-18. The Gateway runs as the service qube sys-whonix, and anon-whonix is the default Workstation qube. You can create more Gateway and Workstation qubes from the same templates, which lets you keep separate identities in separate Workstations. Whonix's system requirements page gives the reason this is its strongest setup: on Qubes an attacker must subvert the Xen hypervisor, which is far harder than exploiting a host operating system.

Qubes OS: security by compartmentalisation

Qubes is a desktop operating system that starts from the assumption that every program has exploitable bugs, and limits what a compromised one can reach. Each compartment is a qube, implemented as a Xen virtual machine. Windows from each qube share one desktop but carry an unforgeable coloured border, so you can see which qube a window belongs to.

The pieces, as the Qubes glossary and docs define them:

• dom0 is the admin qube Xen starts first. It runs the management toolstack and has direct access to most hardware. In the default install it is also the only interface qube, the one that handles the display. Everything depends on it staying clean, so you do not browse or open files there.
• sys-net holds the network card and its drivers. sys-firewall sits between it and your app qubes: in the default setup an app qube uses sys-firewall as its net qube, which in turn uses sys-net. A qube with its net qube set to none is offline.
• sys-usb takes the USB controllers, so a malicious USB device talks to an untrusted qube rather than dom0. The installer can create it for you. If your only keyboard is USB, read the USB qube warnings first: a USB qube that takes your sole controller can lock you out of dom0.
• Templates hold the root file system. App qubes borrow it read-only and keep only their own /home and /usr/local, so you update software once in the template, and software installed directly in an app qube is gone after a restart.
• Disposables are stateless qubes created from a disposable template (default-dvm by default) and destroyed after use.
• Split GPG keeps private keys in a separate qube with no network. The mail client in another qube asks it to sign or decrypt. You approve access, that approval stays valid for 5 minutes by default, and every use of the key shows a notification. The keys never enter the qube that reads untrusted email.

Qubes is not an anonymity system by itself. Its FAQ states that it does not claim special privacy properties in non-Whonix qubes, including disposables, and that when you need privacy you should use Whonix qubes.

Worked example: opening an untrusted PDF in a disposable

A PDF arrives in your work email qube. On a normal desktop, a malicious PDF that exploits the viewer gets the same access as you. On Qubes, the steps from the Qubes disposables guide are:

1. In the work qube's file manager, right-click the PDF and choose Edit/View in disposable qube. From a terminal in the same qube, the view-only form is:

   copy

   [user@work ~]$ qvm-open-in-dvm --view-only -- 'invoice.pdf'

2. Qubes sends the file over its qrexec protocol (the qubes.OpenInVM service) to a new disposable named like disp1234, built from the work qube's default disposable template. The PDF viewer opens in a window with that disposable's border colour.

3. If the PDF is malicious, it compromises disp1234 and nothing else. The disposable has none of the work qube's files or mail, and its root file system comes from a template it cannot write to.

4. Close the viewer. Closing the first application opened in a disposable shuts it down and deletes it, exploit included.

5. Without --view-only, a file you edit and save in the disposable is copied back over the original. Use --view-only for anything you only need to read.

6. To keep a safe copy, right-click and choose Convert in disposable qube (or run qvm-convert-pdf). A disposable renders each page to an RGBA bitmap and sends back only the pixels to rebuild a clean PDF; the original moves to ~/QubesUntrustedPDFs. The result is larger and has no searchable text.

If you do not want the disposable online at all, set the disposable template's net qube to none. A malicious file then has no network to call home on.

Qubes hardware

The documented minimum is a 64-bit Intel or AMD CPU with Intel VT-x with EPT or AMD-V with RVI, plus Intel VT-d or AMD-Vi (the IOMMU, which lets Qubes hand the network card and USB controllers to their own qubes), 6 GB of RAM and 32 GB of free storage. The recommendation is an Intel CPU with VT-x with EPT and VT-d, 16 GB of RAM, 128 GB on a fast SSD and Intel integrated graphics. Qubes advises against AMD processors because of inconsistent security support on client platforms, and recommends CPUs that still receive microcode updates, since some vulnerabilities can only be fixed in microcode. Installing Qubes inside a VM is not recommended.

Meeting the list does not guarantee Qubes runs. Check three sources before buying: Qubes-certified hardware (developer certified; the Star Labs StarFighter and StarBook Horizon were certified on 21 October 2026 for Qubes 4.3.1 or newer, in specific configurations only: the StarBook Horizon in its Core i3-N305 build and the StarFighter in its Intel builds, not the AMD one), the community-recommended list, and the Hardware Compatibility List (HCL), which records community test reports and is described by the project as neither recommending nor disrecommending a machine.

What each one fails at

Tails

• No compartments. Everything in a session shares one system. The Qubes FAQ makes this point directly: live systems such as Tails are monolithic, so if the session is compromised, all data and activity in it is exposed. AppArmor confines Tor Browser, which limited the 2019 escape below, but a browser exploit still sees whatever you do in that browser.
• Host firmware and hardware. Tails' warnings page says no operating system can protect against a hardware keylogger or a BIOS or firmware attack. It also says a Tails stick installed from a compromised operating system might be corrupted, and advises against plugging the stick in while another operating system is running.
• Running Tails in a VM. The host and the hypervisor can watch everything Tails does, and malware on the host breaks Tails' protections.
• A root exploit can bypass Tor. Tails' design documents describe how it enforces Tor: an iptables firewall in the same system that runs your applications blocks all outbound traffic except Tor. Root can change that firewall. Tails' own administration password page warns that an attacker who gets the password could reveal your IP address, and Whonix's comparison page makes the same point about a root exploit. Whonix moves the firewall into a separate VM for this reason.
• Linking yourself. Two identities in one session, or files with metadata, undo the anonymity. Tails ships Metadata Cleaner for the second.

Whonix

• A compromised host compromises everything. Whonix's warning page says it cannot protect a system whose trusted computing base is compromised by malware, firmware trojans or malicious hardware: every Whonix VM, Tor process and supposedly anonymous communication on that host is compromised too. Whonix in VirtualBox on a daily Windows machine is only as safe as that Windows machine.
• Hypervisor bugs. The same page quotes a Google Project Zero researcher who demonstrated a KVM escape: such attacks are achievable for a well-financed adversary, and bugs in KVM, Hyper-V, Xen or VMware will be exploited in the wild sooner or later. Isolation raises the cost of an attack and leaves that residual risk in place.
• Persistence by default. A Workstation that was compromised once stays compromised until you restore it, unless you use Live Mode or Qubes disposables.

Qubes

• Hardware compatibility. The single most common reason people give up. Check the HCL and certified list for your exact model before buying.
• No GPU acceleration. The FAQ says Qubes renders graphics on the CPU outside dom0 and has no GPU virtualisation. GPU work means passing a whole dedicated GPU to one qube, which exposes it to that qube's compromise and needs a second GPU to draw the desktop. Video editing and gaming belong on another machine.
• Memory and suspend. sys-net, sys-firewall, sys-usb and your app qubes all run as separate VMs, which is why 16 GB of RAM is the recommendation. Laptop suspend and resume vary by model; the documentation keeps a dedicated suspend troubleshooting page.
• No amnesia, no anonymity by default. Qubes keeps state and does not hide your IP outside Qubes-Whonix.
• The hypervisor is software. See QSB-121 below.

All three: the Tor exit

Every Tor-based system inherits Tor's limits (exit relays and end-to-end correlation), covered in how Tor works. Tails' warnings page adds the practical rules: treat a certificate warning in Tor Browser as a possible machine-in-the-middle attack by the exit and use New Identity to change it, expect websites to see you use Tor because exit addresses are public, and use a bridge if your local network must not see it.

Advisories that show the limits

These come from the projects' own advisory pages. Each one shows where a model holds and where it does not.

Which one to use

Journalist working from a borrowed or untrusted laptop: Tails. It needs no installation on the computer, leaves no record on it, and works on most PCs from the last ten years. Restart between sources or identities, connect through a bridge where using Tor is itself dangerous, and remember it cannot beat a hardware keylogger on a computer you do not control. If the laptop is a recent Mac with an Apple processor, Tails will not boot on it.

Security researcher who wants one daily machine: Qubes, with Qubes-Whonix for Tor. Keep email, browsing, client work, malware samples and keys in separate qubes; open every attachment in a disposable; put GPG keys behind Split GPG; send research traffic that must be anonymous through sys-whonix. Buy hardware from the certified or community lists first, budget 16 GB of RAM or more, and install dom0 updates when a QSB lands.

Someone who wants Tor at home: Whonix, or Tor Browser. If your concern is websites and your ISP tracking you, Tor Browser on your normal computer is enough. If you need to run other applications over Tor and want an IP leak to be impossible from inside the guest, run Whonix in KVM on a Linux host you keep clean. Whonix in VirtualBox on a daily Windows machine protects you from a compromised Workstation and does nothing about a compromised Windows. If you also want the session to vanish, use Live Mode or boot Tails.

Everyone else. Most people's threats are ad tracking, breaches and a stolen laptop. Full-disk encryption, a password manager and occasional Tor Browser use cover those. For what the hidden services side of Tor actually contains, see what is the dark web.

The short version: Tails forgets, Whonix hides your address from your own applications, and Qubes contains what goes wrong. Pick the property your threat model needs, and combine them (Qubes-Whonix, or Tails on a dedicated laptop) when it needs more than one.