Tails Release History: Amnesia, Tor, Persistent Storage and Updates

Tails is a portable Linux operating system that starts from a USB stick, sends its Internet traffic through the Tor network and forgets everything when you shut it down, unless you choose to save something in an encrypted Persistent Storage. As of 24 October 2026 the current release is Tails 7.15.1, published on 23 October 2026 as an emergency release, and the 7.x series is the first built on Debian 13 (Trixie). Since September 2024 Tails has been developed inside the Tor Project.

The project began as Amnesia in June 2009, took over the name and role of an older live system called Incognito in 2010, reached 1.0 in April 2014, and has moved to each new Debian stable base since. This post covers that history with dates from the Tails news archive, then how Persistent Storage, signed upgrades and download verification work, what Tails does and does not protect against, and a step by step install and update routine.

Key takeaways

• Current release. Tails 7.15.1 (23 October 2026) is an emergency release that updates Tor Browser to 15.0.26 and updates the system certificate authorities so that certificates from a compromised certificate authority are blocked. Automatic upgrades to it are available from Tails 7.0 or later.
• Debian bases move with Debian. Tails 2.0 was on Debian 8, 3.0 on Debian 9, 4.0 on Debian 10, 5.0 on Debian 11, 6.0 on Debian 12 and 7.0 on Debian 13, released 18 September 2025.
• Faster cadence since September 2026. Tails says Firefox moved to a two week release cadence and that Tor Browser and Tails followed; Tails 7.12 (3 September 2026) was the first release on that schedule. Emergency releases such as 7.10.1 and 7.15.1 ship outside the schedule.
• Amnesia is the default. Tails runs from memory, does not use the computer's hard disk or swap, and overwrites memory at shutdown. Anything you want to keep must go into Persistent Storage, which is opt in, per feature.
• Persistent Storage is LUKS. It is an encrypted partition that fills the free space on the stick. Since Tails 5.13 (16 May 2023) new volumes use LUKS2 with Argon2id, and Tails 5.14 converts older LUKS1 volumes automatically. Persistent Storage is not hidden: anyone holding the stick can see that it exists.
• Upgrades are signed. Automatic upgrades are Incremental Upgrade Kits described by upgrade description files that are signed with the Tails OpenPGP signing key and checked against the running version to prevent rollback, according to the upgrade design document.
• Verification changed. The download page now verifies images with JavaScript against a checksum file served from tails.net; Tails removed its general OpenPGP verification instructions, keeping them only in the command line install guide for Debian and Ubuntu.
• Tails is safe but not magic. The project's own warnings page says no operating system can protect against compromised hardware, BIOS or firmware, and that Tor exit nodes can observe or tamper with unencrypted traffic.

If you are comparing privacy focused systems, this post sits next to our Qubes OS release history and our GrapheneOS release history. For the distribution Tails is built from, see every Debian release and its security support dates.

What Tails is

Tails stands for The Amnesic Incognito Live System. The About Tails page describes it as a system that "always starts from the same clean state", and lists three ideas that still define it.

Amnesia. Tails never writes to the computer's hard disk and runs only from memory. When you shut it down, the memory is erased. Websites you visited, files you opened, Wi-Fi networks you joined and passwords you typed do not survive the session unless you explicitly saved them.

Tor by default. Every application that reaches the Internet does so through Tor. The design document says Tails "transparently proxies all of amnesia's outgoing TCP Internet traffic through tor" (amnesia is the name of the default user). Non TCP traffic to the Internet, such as UDP datagrams and ICMP packets, is dropped, because Tor only carries TCP.

A toolbox with safe defaults. Tor Browser, Thunderbird, an OpenPGP key manager, a password manager, a metadata cleaner and an office suite, configured so the common choice is the safe one.

Tails is not an installed operating system. You boot a computer from the Tails USB stick, use it, shut it down, and the computer's own operating system is untouched. The system requirements page says it works on most PC computers less than ten years old with a 64 bit x86-64 processor and 3 GB of RAM. It does not work on Mac computers with Apple processors, smartphones, tablets or Raspberry Pi, and 32 bit computers have not been supported since Tails 3.0 in June 2017.

The design document and the PELD idea

Tails publishes an unusually detailed design document. It opens by specifying a "Privacy Enhancing Live Distribution", or PELD, and then describes Tails as an implementation of that specification. The document says it is "heavily based on preliminary work" done for Incognito 2008.1, and that critical parts of the firewall and Tor configuration came from Incognito and the Tor Browser.

The specification uses the keywords MUST, SHOULD and MAY in the RFC 2119 sense, which makes it readable as a set of requirements. Three of them explain most of what Tails does:

• It is REQUIRED that no trace is left on local storage devices unless the user explicitly asks for it, and the system MUST NOT use any filesystem or swap volume on the host machine.
• Volatile memory MUST be erased on shutdown to prevent memory recovery such as a cold boot attack.
• Tools to inspect and clean metadata, such as EXIF data, SHOULD be available.

The same document is honest about limits that come from Tor itself. It says the system "does not try to conceal it is connected to the Tor network unless Tor bridge relays are used", and that it "is not secure against end-to-end attacks, such as end-to-end timing or intersection attacks".

Where Tails came from: Amnesia, Incognito and the rename

The first public version of what became Tails was released on 23 June 2009 under the name Amnesia. The Tails 1.0 announcement gives that date, and the archived Amnesia 0.2 news item carries it too. Amnesia 0.3 followed on 25 November 2009.

Incognito was an older live CD with a similar goal. On 7 April 2010 the project posted a new project name announcement: the Incognito author had declared Incognito dead on 23 March 2010 and written that Amnesia "should be considered as its spiritual successor". Amnesia was renamed The (Amnesic) Incognito Live System. That is the origin of the acronym. Strictly, this was not a merger of two codebases. Incognito ended, its author pointed users to Amnesia, and Amnesia took on the name, while the design document records that parts of Incognito's configuration had already been reused.

Version 0.5, released on 1 May 2010, was the first under the new name. Version 0.6, on 22 October 2010, noted that released images were now signed with a new OpenPGP key, an early sign of the signing discipline that still underpins the update model. Version 0.7, on 7 April 2011, was built on Debian Squeeze and introduced "a new, safer way to wipe memory on shutdown" that also ran when the boot medium was physically removed.

The Tor Project's merger announcement adds one more detail about those early days: Tails' first release was announced on a Tor mailing list.

Every major Tails release and its Debian base

Tails versions track Debian closely. A new major version usually means a new Debian stable base, and the project has made a point of rebasing early. The Tails 3.0 announcement explains that releasing on the new Debian at the same time as Debian itself meant users got the changes earlier and Tails could find and fix issues while the new Debian was still in development.

The table below lists the milestones, with dates from each release's own news item.

Debian's own releases page confirms that Debian 13 (Trixie) was first released on 9 August 2025, so Tails 7.0 followed about six weeks later. For the support windows of each Debian release, see our Debian release history.

Tails 1.0 to 4.x: building the foundations

By the time of 1.0 in April 2014, the announcement listed the features the team considered essential: a USB installer, automatic upgrades, persistence, support for Tor bridges and MAC address spoofing. The team said 1.0 itself brought few user visible changes and was mostly a maturity milestone. The same release fixed numerous security issues and told all users to upgrade as soon as possible, a pattern that every later announcement repeats.

Tails 2.0 in January 2016 moved to Debian 8. Tails 3.0 in June 2017 moved to Debian 9, dropped 32 bit computers and introduced a new startup and shutdown experience. Tails 4.0 in October 2019 moved to Debian 10.

Tails 5.x: Persistent Storage redesign, Wayland and LUKS2

Tails 5.0 arrived on 3 May 2022 on Debian 11. The 5.x series is where the most important structural change in years happened. The Tails 5.8 announcement calls it "the most important release of Tails in years":

• A new Persistent Storage. After two years of work, the feature was redesigned. You no longer had to restart after creating it or after turning on a new feature, you could change its passphrase from the new application, and you could create it straight from the Welcome Screen.
• Wayland replaced X.Org. Tails says Wayland makes it harder for a compromised application to compromise or misuse another application. Since Tails 4.8, the Unsafe Browser (used only to sign in to captive portals) had been disabled by default because a flaw in another application could start an invisible Unsafe Browser and reveal the user's IP address. Wayland closed that path, so 5.8 re-enabled the Unsafe Browser by default.
• QR code scanning for Tor bridges, to make entering bridges easier.

Then came the LUKS change. Until Tails 5.12 (19 April 2023), Tails created LUKS version 1 volumes with PBKDF2 as the key derivation function. The advisory on weak LUKS1 parameters, posted on 14 June 2023, says these parameters "are weak against a state-sponsored attacker with physical access to your device". Since Tails 5.13 (16 May 2023), new volumes use LUKS2 with Argon2id, and Tails 5.14 (13 June 2023) converted existing Persistent Storage to LUKS2 automatically on first start.

Tails 6.x: Debian 12 and hardware hygiene

Tails 6.0, released on 27 February 2024, was the first version based on Debian 12 and GNOME 43. Its security relevant changes were practical:

• Error detection on Persistent Storage. Tails warns when it hits read or write errors on the USB stick, so you can back up before the stick fails.
• Automatic mounting of external drives, with an offer to unlock encrypted partitions, including VeraCrypt volumes.
• Protection against malicious USB devices. Tails 6.0 ignores any USB device plugged in while the screen is locked. New devices only work if they are plugged in while the screen is unlocked.
• Diceware passphrases in five more languages when creating Persistent Storage.

Tails 7.x: Debian 13, faster boot and a faster cadence

Tails 7.0 was released on 18 September 2025 on Debian 13 and GNOME 48, dedicated to the memory of Lunar, a long time contributor to Tails, Tor, Debian and the Reproducible Builds project. Its changes include:

• Startup 10 to 15 seconds faster on most computers, by switching image compression from xz to zstd, at the cost of an image about 10% bigger.
• Linux kernel 6.12.43, Tor Browser 14.5.7 and Tor client 0.4.8.17 at release.
• A higher memory requirement, from 2 GB to 3 GB of RAM, with a notification when the requirement is not met. Tails estimated that fewer than 2% of users were affected.
• Some removals, including the aircrack-ng package from the default image (still installable as additional software).

The 7.0 notes also warn that poor quality USB sticks can make startup 20 seconds slower, and recommend buying from a retailer with a reliable supply chain where counterfeit electronics are common.

Two 7.x releases show the emergency path. Tails 7.10.1 (5 August 2026) updated the Linux kernel to 6.12.100 to fix a vulnerability that Tails said "could allow Tor Browser in Tails to gain administrator privileges", and updated the expat XML library for a set of flaws in applications such as LibreOffice and Git. It also cut 70 MB from images by removing unused firmware. Tails 7.15.1 (23 October 2026) shipped two days after Tor Browser 15.0.26, which blocks compromised intermediate certificates from a certificate authority. Tails explained that someone holding those intermediates could impersonate any website even over HTTPS, that the attack could be performed by a Tor exit node, an exit node's Internet provider or a government, and that onion sites were not affected. Because other applications in Tails rely on the Debian ca-certificates package, Tails also updated the system certificate authorities, not just the browser. Our explainer on that certificate authority compromise covers the wider incident.

How the release cadence works

Tails releases come in three kinds, all announced on the Tails news page and its RSS feed.

Scheduled releases. These carry routine updates: a new Tor Browser, a new Tor client, a newer kernel, firmware for newer hardware, application updates and bug fixes. Tor Browser is built on Firefox Extended Support Release, so Tails' schedule follows the browser's. The Tails 7.12 notes say Firefox was moving to a two week release cadence starting in September 2026, that Tor Browser and Tails were doing the same, and that 7.12 was the first release on the new cadence. The release dates bear that out:

Dates are from the Tails news RSS feed. In the summer of 2026 scheduled releases were four to five weeks apart; since September 2026 a Tails user should expect an update about every two weeks.

Emergency releases. These ship outside the schedule when a vulnerability is serious enough. The Tails release process documentation has a dedicated path for preparing an emergency release, and the announcements are easy to recognise because they open with "This release is an emergency release". 7.10.1 and 7.15.1 are recent examples. Version numbers with a third component, such as 7.9.1, are often but not always emergency releases; 7.9.1 itself was a routine kernel and Tor Browser update.

Major releases. A new major version, such as 6.0 or 7.0, usually means a new Debian base and requires a manual upgrade the first time. Automatic upgrades only work within a series: the 7.15.1 notes say automatic upgrades are available "from Tails 7.0 or later".

How Tails handles security advisories

Tails relies heavily on Debian's security team. The security audits and advisories page quotes Debian's security statement and links the Tails security issue response policy. Most fixes reach users through the release notes rather than standalone advisories. The release notes use a consistent format: what was fixed, an example of how an attacker might use the flaw, a plain statement of likelihood ("This attack is very unlikely but could be performed by a strong attacker"), and whether Tails knows of it being used in practice.

The same page lists two independent penetration tests by an outside firm. The first, published on 10 November 2023, covered the Persistent Storage, the Unsafe Browser and the Wayland work from Tails 5.8. The second, published on 16 May 2025, covered automatic upgrades and recent changes. Tails quotes the second report's conclusion that the auditors "did not find any remote code execution vulnerabilities", and that every issue found required an already compromised amnesia user. In both cases Tails says it fixed issues as they were reported rather than waiting for the report to be published.

How upgrades work: Incremental Upgrade Kits and signed descriptions

Tails has two ways to upgrade a USB stick, both described on the upgrade documentation page. Both keep your Persistent Storage.

Automatic upgrades with Tails Upgrader

After you start Tails and connect to Tor, Tails Upgrader checks whether an upgrade is available and offers to apply it. The check and download both go through Tor. You can also run it later from Apps, Tails, About Tails, then Check for Upgrades.

The documentation lists the advantages: you need only one stick, the download is much smaller than a full image, and "the upgrade mechanism includes cryptographic verification of the upgrade", so you do not need to verify anything yourself.

The upgrade design document explains how that verification works:

1. Upgrade description files. For each product, initial install version, build target and channel, Tails publishes an upgrades.yml file on tails.net. It lists available upgrades, each with a version, a type (major or minor), and one or two upgrade paths. Each path lists target files with a URL, a size in bytes and a SHA-256 hash.
2. Signatures. Each description file is shipped with an OpenPGP detached signature (upgrades.yml.pgp) made with the Tails signing key. The design document says signature verification is done with Sequoia SOP.
3. Incremental Upgrade Kits. An IUK is a SquashFS archive that contains a format version and an overlay with the new initrd, bootloader configuration and a "diff" SquashFS that is stacked on top of the existing system. Tails builds IUKs with a tails-create-iuk program that takes two full images as input.
4. Download and check. The target file can come from any mirror, because mirrors are not trusted. The client checks its size and SHA-256 hash against the signed description.
5. Install. The IUK is applied to the system partition of the stick, and the new version runs after restart.

The design document assesses this system against the attack classes defined by The Update Framework project. The upgrader is immune to rollback attacks because it compares proposed versions with the running version, and signed file sizes limit endless data attacks. An indefinite freeze attack, where an attacker keeps presenting stale metadata, would need control of the Tails website or a broken TLS connection; the document says short lived metadata signatures, as in that framework, would make this stronger, but the framework was not ready for Tails' use case.

Manual upgrades with Tails Cloner

Sometimes an automatic upgrade is not possible: no IUK is published for your version (for example across major versions), there is not enough memory or free space on the system partition, or a previous automatic upgrade failed. In those cases you do a manual upgrade with Tails Cloner, either by downloading a new image to an intermediary USB stick and cloning from it, or by cloning from a trusted friend's up to date Tails.

Automatic upgrades grow over time because each IUK contains all changes since the last manual install; Tails estimates one manual upgrade a year is enough to keep them small.

How images are signed and verified

Tails images are signed with a single long lived signing key. The OpenPGP keys page gives its details: an RSA 4096 primary key created on 18 January 2015, fingerprint A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F, with Ed25519 signing subkeys created in 2024 and 2025 and an expiry date of 22 October 2028. The policy behind it is strict:

• The key can sign and certify but has no encryption subkey. Its only purposes are signing released images and certifying other keys used in Tails development.
• The primary key "is not owned in a usable format by any single individual". It is split cryptographically using gfshare and only used offline, in an air gapped Tails.
• Signing subkeys live on OpenPGP smartcards, so signing happens on the card and the secret material is not exposed to the operating system.
• The primary key expires in less than a year and is extended as needed, and its revocation certificate is split among different people.

The current verification method

How users verify a download has changed several times, and the current approach is a deliberate simplification. The download verification design document explains the reasoning.

HTTPS alone is not enough, because Tails relies on mirrors hosted by third parties that could serve a malicious image, and HTTPS does not protect against interrupted downloads. OpenPGP signatures are stronger in theory, but unless a user can verify the signing key through the OpenPGP Web of Trust, OpenPGP verification "ultimately relies on a correct download of the signing key and signature, and thus on HTTPS".

So the main mechanism today is JavaScript on the download page. It fetches an image description file from https://tails.net/install/v2/Tails/amd64/stable/latest.json, computes the checksum of the file you select locally in your browser, and checks that the checksum appears in the description file. On 24 October 2026 that file listed Tails 7.15.1 with SHA-256 hashes for both the USB image and the ISO.

Tails removed its general OpenPGP verification instructions. The design document gives three reasons: without advanced knowledge, OpenPGP verification gives the same security as the JavaScript check while being more complicated and error prone; none of the project's user personas would have enough OpenPGP knowledge to use the Web of Trust with confidence; and maintaining instructions consumed help desk and writer time. It keeps one exception: the command line install guide for Debian and Ubuntu, because Debian derivatives ship a keyring of Debian developers that can build a real trust path to the Tails signing key.

The JavaScript method has a written threat model. It protects against a malicious image from a rogue mirror. It does not try to protect against a rogue certificate for tails.net, a compromised Tails website or Git repository, or malware in your browser, because any of those could also fake the verification itself.

Tails also supports reproducible builds: anyone can build the ISO, USB image and IUK from source and compare the result with the official files, either with a checksum or with the OpenPGP signature. That lets independent parties check that the published binaries match the published source.

Persistent Storage: what it keeps and how it is protected

What it is

The Persistent Storage documentation describes it as "an encrypted partition protected by a passphrase that occupies all the free space left on the USB stick". You choose whether to unlock it each time you start Tails. If you do not unlock it, the session is fully amnesic.

The page also carries a warning that many users skip: "The Persistent Storage is not hidden. An attacker in possession of your USB stick can know that there is a Persistent Storage." Tails adds that you could be forced or tricked into giving out the passphrase. Persistent Storage protects data at rest against someone who does not know the passphrase; it does not hide the fact that you have data.

What it can keep

Only a fixed list of features can be made persistent. The configuration page lists them:

Tails says it is often asked to persist Tor Browser preferences, Tor configuration, desktop backgrounds and similar settings, and it has not done so. That is intentional. The more you customise, the more your Tails differs from everyone else's.

The Dotfiles feature deserves care. It links every file in /live/persistence/TailsData_unlocked/dotfiles into the home folder with symbolic links. The documentation warns that the programs in Tails "are carefully configured with security in mind", that changing defaults can weaken security, and that "changing the default settings can break your anonymity" because Tor and Tails rely on users looking alike. The Additional Software feature carries a similar warning: packages included in Tails are tested for security, and installing more "might break the security built into Tails".

How it is built

The Persistent Storage design document describes the implementation:

• An encrypted LUKS volume on the Tails stick, labelled TailsData.
• A configuration file at /live/persistence/TailsData_unlocked/persistence.conf that maps source paths to destination paths. Each persistent file or folder is either bind mounted or linked with a symlink.
• A privileged backend, the tps backend, which is a D-Bus activated systemd service exposing the org.boum.tails.PersistentStorage interfaces on the system bus.
• An unprivileged GTK settings application and a command line tool (tpscli) that call the backend.
• Hooks that run on activation and deactivation, for example to add a bookmark for the Persistent folder.
• A check for conflicting applications: if you turn on the Thunderbird feature while Thunderbird is running, Tails asks you to close it first, so the application does not end up writing to the wrong place.

Each feature has three flags borrowed from systemd: active, enabled and masked. The design document also covers privilege separation between the root backend and the unprivileged interface, and symlink attack defences.

How it is encrypted

The documentation says encryption uses LUKS and dm-crypt, the standard Linux disk encryption system, with default parameters. As covered above, the key derivation function changed in 2023:

The argon2id advisory includes rough estimates of the electricity cost of guessing passphrases made of random words. They show why passphrase length matters as much as the algorithm:

Tails stresses these are "very rough estimates", and that any such attack also needs physical access to the device, expensive equipment and professional skills. Two worked readings make the table concrete. First, moving from PBKDF2 to Argon2id at the same passphrase length multiplies the estimated cost by 1,000 in every row: four words go from $1,000 to $1,000,000. Second, adding one more random word multiplies the cost by 10,000 in every row: on Argon2id, going from four words to five takes the estimate from $1,000,000 to $10,000,000,000. So the algorithm change is worth a little less than one extra word, and a long passphrase still matters more than the key derivation function. The project's standing advice is a passphrase of 5 to 7 random words, which Tails' own passphrase generator produces.

Backups and recovery

Persistent Storage lives on a single USB stick, so it is only as durable as that stick. Tails 5.14 added full backups by cloning Persistent Storage to a backup Tails stick with Tails Installer, and there is a backup utility for faster incremental updates of an existing backup. The backup documentation walks through both. Tails 6.0's error alerts are meant as an early warning that the stick is failing.

What Tails protects against, and what it does not

Tails is clear that it is not a complete answer to every threat. The warnings page is titled "Tails is safe but not magic!" and it is the most useful page on the site for setting expectations.

What Tails is designed to do

• Leave no trace on the computer. No use of the host's disks or swap; the design document says the swapon binary is replaced by a no op script.
• Erase memory at shutdown and on media removal. The design document says most memory is erased at the end of a normal shutdown through the kernel's freed memory poisoning (init_on_free=1), and that a watchdog triggers memory erasure when the boot USB is unplugged or the DVD ejected. The cold boot attack page explains why: data in RAM can survive for up to several minutes after power off.
• Route all Internet traffic through Tor with a firewall that drops non TCP traffic to the Internet and allows each local service only to the users that need it.
• Separate Tor circuits by application. The stream isolation design says Tails specific tools such as the upgrader use their own SOCKS port, and Tor Browser uses its own fine grained isolation, so unrelated activity does not share a circuit by default.
• Randomise MAC addresses by default, so the hardware address of your network card does not identify the computer to the local network, as described on the MAC address anonymization page.
• Resist some local attacks. Since 6.0, USB devices plugged in while the screen is locked are ignored.

What Tails says it cannot do

The warnings page groups the limits into three areas.

Your own activity can reveal you. Files often carry metadata (location, camera, author, timestamps), so Tails includes a metadata cleaner. Using one Tails session for several purposes lets an observer link those activities, because websites can tell when two accounts use the same Tor circuit. Tails recommends restarting between activities, and even using a separate Tails stick for each area of your life if the contents of Persistent Storage could link them.

Tor has limits. Your Internet provider can see that you connect to Tor, though not which sites you visit; bridges hide the Tor connection itself. Sites you visit can see that you use Tor because the list of exit nodes is public. The exit node can observe traffic that is not encrypted end to end, and can pretend to be the destination server if you ignore certificate warnings. An adversary able to watch the timing and shape of traffic at both ends of a circuit might deanonymize users; Tails says it does not know of such end to end correlation attacks being used in practice, but no low latency anonymity network can rule them out. The Tor Project's support pages cover the same limits from the network side.

Untrusted computers are a problem. Tails can run safely on a computer that has a virus in its usual operating system, but it "cannot always protect you" when installing from an infected computer, when running on a computer with compromised BIOS, firmware or hardware, or when using an untrusted computer. A hardware keylogger records keystrokes no matter what operating system runs. The page says plainly: "No operating system can protect against BIOS and firmware attacks", because every operating system depends on firmware to start.

How the 2024 merger with the Tor Project changed governance

On 26 September 2024 the Tor Project and Tails announced that they had "joined forces and merged operations". The Tails announcement and the Tor Project blog post carry the same text.

According to both, Tails approached the Tor Project in late 2023 because Tails "had outgrown its existing structure". The aim was to let the Tails team focus on maintaining and improving Tails while the Tor Project's larger organisation handled operations. The announcement notes a long history of collaboration: Tails' first release was announced on a Tor mailing list 15 years earlier, Tor and Tails developers had worked closely since 2015, and Tails had recently been a sub grantee of Tor. intrigeri, named in the announcement as Team Lead for Tails OS at the Tor Project, said the hardest part of running an independent project for 15 years had been fundraising, finance and HR rather than the technology.

What changed in practice, based on what the two sites now show:

• Organisation. Tails is a team within the Tor Project rather than a separate project with its own operational structure.
• Infrastructure. The Tails news mailing list is now hosted on lists.torproject.org, as the news page shows, and the upgrade design document names the same list as a release announcement channel.
• Donations. Donations go to the Tor Project, with the option to earmark them for Tails through the Tails donation page "until further notice".

Tails still publishes its own releases, advisories and design documentation at tails.net, with the same signing key and policy.

Tails compared with Qubes OS with Whonix and a normal laptop with Tor Browser

People often weigh Tails against two alternatives: Qubes OS running Whonix, and an ordinary installed operating system with Tor Browser. They answer different questions.

Whonix consists of two virtual machines: a Whonix Gateway that runs Tor and a Whonix Workstation that runs applications on an isolated network, so the workstation does not know the computer's real external IP address. On Qubes, Whonix is installed as two templates on top of the Qubes hypervisor, as the Qubes-Whonix page describes.

None of these protects against compromised firmware or hardware. For Qubes' own architecture and support model, see our Qubes OS release history.

One honest note on isolation: Tails runs on one kernel, so a kernel privilege escalation from an application can compromise the whole session. That is why emergency releases such as 7.10.1 exist.

Step by step: download, verify, install, configure and update

This walkthrough follows the Tails command line install guide for Debian and Ubuntu, with commands as published there. Most people should use the graphical installation paths on the install page, which use the in browser verification; the command line path is shown because it is the one that still documents OpenPGP verification end to end.

You need a USB stick of at least 8 GB, about half an hour to download (the image is about 1.8 GB) and a trusted computer.

1. Verify the Tails signing key through the Debian keyring

Import the Tails signing key:

wget https://tails.net/tails-signing.key
gpg --import < tails-signing.key

Install the Debian keyring and import the key of a Debian and Tails developer from it:

sudo apt update && sudo apt install debian-keyring
gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --export intrigeri@debian.org | gpg --import

Check the certifications on the Tails signing key:

gpg --keyid-format 0xlong --check-sigs A490D0F4D311A4153E2BB7CADBB802B258ACD84F

The guide says the output should include a line beginning with sig!3 from intrigeri, meaning he verified and certified the key with a level 3 check. If you cannot see that certification, you may have a malicious copy of the key, and you should stop. If it is there, certify the key locally with your own key:

gpg --lsign-key A490D0F4D311A4153E2BB7CADBB802B258ACD84F

2. Download the image and its signature, then verify

The file names below are for 7.15.1, the current release on 24 October 2026; substitute the current version.

wget --continue https://download.tails.net/tails/stable/tails-amd64-7.15.1/tails-amd64-7.15.1.img
wget https://tails.net/torrents/files/tails-amd64-7.15.1.img.sig
TZ=UTC gpg --no-options --keyid-format long --verify tails-amd64-7.15.1.img.sig tails-amd64-7.15.1.img

The guide says the output should show "Good signature from Tails developers" and a signature date matching the one it publishes. As a second, independent check, compare the image's SHA-256 with the value in the image description file:

sha256sum tails-amd64-7.15.1.img
curl -s https://tails.net/install/v2/Tails/amd64/stable/latest.json | grep -A1 '"sha256"'

On 24 October 2026 the description file listed 32eba91c65cd184206eb7c8e9b504277442cf17aae7816815a1d9401e9736761 for the 7.15.1 USB image.

3. Identify the USB stick before you write anything

Warning: the next step overwrites the target device completely. Writing to the wrong device destroys its data, including your computer's own disk.

The Tails guide identifies the stick by listing devices before and after plugging it in:

# With the USB stick unplugged
ls -1 /dev/sd?
# Plug the USB stick in, then run again
ls -1 /dev/sd?

The new entry is your stick. Confirm it with size and model before going further:

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINT

Check that the device you noted shows usb as its transport, has the size you expect, and is not mounted as part of your running system. If you are not sure, stop.

4. Write the image

Replace tails.img with your image path and device with the device you confirmed, for example /dev/sdb:

sudo dd if=tails.img of=device bs=16M oflag=direct status=progress

The installation is complete when the prompt returns. Restart the computer and choose the USB stick from the boot menu.

5. Create and configure Persistent Storage

1. Start Tails. In the Welcome Screen, choose to create a Persistent Storage, or later choose Apps, Tails, Persistent Storage.
2. Pick a passphrase of 5 to 7 random words. Tails suggests one; use it or generate your own with dice.
3. Turn on only the features you need. A reasonable minimal set is Persistent Folder plus whichever single application you rely on, such as GnuPG or Thunderbird. Leave Dotfiles and Additional Software off unless you have a specific reason.
4. Restart and unlock the storage in the Welcome Screen when you need it. Start without unlocking when you do not.

To confirm your storage uses LUKS2 with Argon2id, set an administration password in the Welcome Screen, open Apps, System Tools, Root Console, and run:

lsblk
# Find the partition above TailsData_unlocked, for example sda2
sudo cryptsetup luksDump /dev/sda2 | grep -E 'Version|PBKDF'

The argon2id advisory says Version should read 2 and PBKDF should read argon2id. The luksDump command only reads the header and does not change the volume.

6. Back up Persistent Storage

Clone your Persistent Storage to a second Tails stick with Tails Installer, or update an existing backup with the backup utility, following the backup guide. Keep the backup stick somewhere physically separate.

7. Keep it updated

1. Each time you connect to Tor, let Tails Upgrader check for upgrades and apply them. It verifies signatures for you.
2. Subscribe to the Tails news RSS feed or mailing list so you hear about emergency releases even if you have not started Tails recently.
3. When the upgrader says a manual upgrade is needed, typically for a new major version, follow the manual upgrade path with Tails Cloner from a freshly verified image.
4. Check your version any time with Apps, Tails, About Tails.
5. Consider one manual upgrade a year to reset the size of future automatic upgrades.

Common mistakes

• Running Tails on hardware you do not trust. Tails cannot defend against a hardware keylogger, modified firmware or a compromised BIOS. The warnings page is explicit, and no amount of software configuration changes that.
• Installing from a compromised computer. Downloading and writing Tails from an infected operating system can corrupt the stick. Tails recommends installing from a trusted system or cloning from a trusted friend, and not plugging your Tails stick into another running operating system.
• Logging into personal accounts. An account linked to your identity identifies you to that service. Mixing it with other activity in the same session links that activity too. Restart between activities with different identities.
• Keeping too much in Persistent Storage. Every enabled feature is data that exists on the stick, can be found by anyone who has it, and might link activities together. Turn on what you need and nothing else.
• Changing defaults with Dotfiles or extra packages. Custom configuration makes your Tails stand out and can weaken security. Additional software is not tested by Tails.
• Assuming Persistent Storage is hidden. It is visible to anyone holding the stick. Encryption protects contents, not existence.
• Keeping a short or old LUKS1 passphrase. If your storage was created before Tails 5.13 and you never upgraded through 5.14, or your passphrase is four words or fewer, follow the argon2id advisory.
• Skipping emergency releases. The 7.10.1 notes described a flaw that could let a malicious website take control of Tails.
• Pulling the stick out as a habit. Unplugging triggers an emergency shutdown that erases memory, but Tails warns it can corrupt Persistent Storage.

FAQ

What is the latest version of Tails?

As of 24 October 2026, Tails 7.15.1, an emergency release from 23 October 2026. Automatic upgrades to it are available from Tails 7.0 or later.

What Debian version is Tails based on?

Tails 7.x is based on Debian 13 (Trixie), starting with Tails 7.0 on 18 September 2025. Tails 6.x was based on Debian 12 (Bookworm), 5.x on Debian 11 (Bullseye), 4.x on Debian 10 (Buster), 3.x on Debian 9 (Stretch) and 2.x on Debian 8 (Jessie).

How often does Tails release updates?

Since Tails 7.12 on 3 September 2026, scheduled releases come about every two weeks, following Tor Browser and Firefox's two week cadence. Emergency releases ship in between when a serious vulnerability needs fixing.

Is Tails Persistent Storage encrypted?

Yes. It is a LUKS encrypted partition using dm-crypt. Volumes created since Tails 5.13 (16 May 2023) use LUKS2 with the Argon2id key derivation function, and Tails 5.14 converted older LUKS1 volumes automatically. The passphrase is the weak point, so Tails recommends 5 to 7 random words.

Can someone tell that my USB stick has Tails Persistent Storage on it?

Yes. Tails states that Persistent Storage is not hidden and that someone with the stick can know it exists. Encryption protects the contents without a passphrase, not the fact that the storage is there.

How do I verify a Tails download?

The download page verifies the image in your browser by computing its checksum and comparing it with a checksum file served from tails.net. On Debian or Ubuntu you can also verify the OpenPGP signature after building a trust path to the Tails signing key through the Debian keyring, as the command line install guide describes.

Does Tails protect against keyloggers and firmware attacks?

No. Tails' warnings page says no operating system can protect against hardware alterations such as physical keyloggers, or against BIOS and firmware attacks. Use a computer you trust and keep it in a safe place.

Is Tails part of the Tor Project?

Yes. Tails and the Tor Project merged operations on 26 September 2024. Tails is now a team within the Tor Project and still publishes its own releases and documentation at tails.net.

Can I run Tails in a virtual machine?

Yes, using the ISO image, and the virtualization page describes GNOME Boxes and virt-manager on Linux. It also warns that the host operating system and the virtualization software can monitor everything you do in Tails, and that traces are likely to be left on the host's disk, for example through swapping. Tails warns you when it detects it is running in a virtual machine.

Where Safeguard fits, honestly

Safeguard does not secure Tails. It is not an endpoint product, it does not scan Tails images, firmware or the computers Tails runs on, and Tails updates come only from the Tails team and Debian. The overlap is narrow and indirect.

What Tails shows well is a mature software update chain: signed metadata, hashes for every target file, rollback checks, reproducible builds, and fast emergency releases when an upstream component such as the kernel, an XML parser or a certificate store needs fixing. Teams that build and ship their own software need the same discipline for the open source dependencies and container images in their products. That is where Safeguard works.

Tails' own release notes show how much of an operating system's risk arrives through upstream components it did not write, from the Linux kernel to an XML library and a certificate bundle, and how much depends on shipping the fixed versions quickly. The software your team builds has the same shape of risk in its dependencies and base images, even though Safeguard plays no part in securing Tails itself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It is the dependency equivalent of a Tails emergency release: a known fixed version, applied and tested quickly, with a person approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. Run it on your normal development workstation rather than in Tails: Tails is built for amnesic, anonymous sessions, while dependency scanning belongs where your code and build tools live.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Granting tools one at a time follows the same principle as Tails' firewall allowlist, which gives each local service only to the users that need it: once your projects are in Safeguard, you can ask which of them contain a given component and version without opening up more than that question needs.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• About Tails
• Tails news index
• Tails news RSS feed
• Tails design document
• Tails upgrade design
• Tails download verification design
• Tails Persistent Storage design
• Tails stream isolation design
• Tails release process
• Tails security issue response policy
• Verifying a Tails image for reproducibility
• Install Tails from Debian or Ubuntu using the command line and GnuPG
• Install Tails
• Download and verify (for USB sticks)
• Tails image description file (latest.json)
• Tails OpenPGP keys
• Upgrading a Tails USB stick
• Persistent Storage
• Configuring the Persistent Storage
• Creating the Persistent Storage
• Making a backup of your Persistent Storage
• Installing additional software
• Warnings: Tails is safe but not magic!
• System requirements and recommended USB sticks
• Tails features
• Running Tails in a virtual machine
• Protection against cold boot attacks
• Shutting down Tails
• MAC address anonymization
• Tor Browser in Tails
• Connecting to the Tor network in Tails
• Unsafe Browser
• Security audits and advisories
• Weak cryptographic parameters in LUKS1
• Security audit of Persistent Storage and Tor integration (10 Nov 2023)
• Security audit of automatic upgrades and recent changes (16 May 2025)
• Amnesia 0.2 (23 Jun 2009)
• Amnesia 0.3 (25 Nov 2009)
• New project name (7 Apr 2010)
• Tails 0.5 (1 May 2010)
• Tails 0.6 (22 Oct 2010)
• Tails 0.7 (7 Apr 2011)
• Tails 0.10 (4 Jan 2012)
• Tails 1.0 (29 Apr 2014)
• Tails 1.1 (22 Jul 2014)
• Tails 2.0 (26 Jan 2016)
• Tails 3.0 will require a 64-bit processor
• Tails 3.0 (13 Jun 2017)
• Tails 4.0 (22 Oct 2019)
• Tails 5.0 (3 May 2022)
• Tails 5.8 (20 Dec 2022)
• Tails 5.14 (13 Jun 2023)
• Tails 6.0 (27 Feb 2024)
• Tails 7.0 (18 Sep 2025)
• Tails 7.12 (3 Sep 2026)
• Tails 7.15.1 (23 Oct 2026)
• Uniting for Internet Freedom: Tor Project and Tails Join Forces, tails.net
• Uniting for Internet Freedom: Tor Project and Tails Join Forces, Tor Project blog
• New Release: Tor Browser 15.0.26, Tor Project blog
• Tor Project support: About Tor
• Tor specifications
• Tor Browser design document (historical)
• Debian releases
• Debian 13 trixie release information
• About Whonix
• Qubes-Whonix

Last reviewed: 24 October 2026. Tails now releases about every two weeks, with emergency releases in between; check the Tails news page for the current version before installing or upgrading.