Full Disk Encryption in 2026: LUKS, BitLocker, FileVault and VeraCrypt Compared

Full disk encryption (FDE) is one of the few security controls that delivers a near-absolute guarantee in a clearly bounded threat model: if someone physically takes your device while it is powered off, they cannot read your files. That guarantee has been quietly expanding for a decade. In 2026, all major desktop and laptop operating systems ship with FDE either enabled by default or one checkbox away. Yet most users enabling it do not know exactly what they are buying — and more importantly, what they are not.

This guide covers the four dominant solutions — LUKS2 on Linux, BitLocker on Windows, FileVault on macOS, and VeraCrypt as a cross-platform option — and gives you the factual basis to choose, configure, and operate each one correctly.

What Full Disk Encryption Actually Protects

The classic scenario is a stolen laptop. Your drive is encrypted with a strong passphrase. The thief boots a live USB, mounts the drive, and finds only ciphertext. Without the key, the data is unreadable. This is the scenario FDE was designed for, and it handles it well.

A related scenario is legal seizure at rest. Customs inspection, a search warrant executed while you are away, a device seized and imaged before you are present. If the device is powered off when seized, FDE holds. Several courts in multiple jurisdictions have wrestled with whether compelling a passphrase is protected speech; the law varies, but the cryptography is sound.

What FDE Does Not Protect

Full disk encryption protects data at rest. Once the OS has booted and decrypted the volume, the data is accessible to any process running on that system — including malware. If an attacker has remote code execution on a running system, FDE offers no protection at all.

Evil maid attacks. If an attacker has physical access to a powered-off device, boots a live OS, modifies your bootloader or kernel, and returns the device before you notice, they can capture your passphrase the next time you type it. TPM-backed solutions (see BitLocker below) mitigate this by measuring the boot chain, but they introduce their own trade-offs.

Cold boot attacks. DRAM retains its content for seconds to minutes after power is removed, longer when cooled. An attacker with physical access immediately after shutdown can freeze the RAM modules, transfer them to another machine, and extract the in-memory encryption keys. Modern mitigations (kernel overwriting key material on suspend, encrypted suspend images) reduce but do not eliminate this risk.

Screen-locked running systems. A laptop on a coffee table, screen locked, is still a running encrypted system. The volume is already unlocked. FDE provides no additional protection in this state beyond what access control (lock screen) provides.

How Full Disk Encryption Works

Modern FDE relies on a symmetric cipher — almost universally AES — operating in XTS mode, which was designed specifically for disk encryption (IEEE Std 1619-2007). AES-XTS-256 means two 128-bit AES keys combined to produce a 256-bit effective key per sector tweak.

The volume encryption key (VEK) is generated randomly when the disk is formatted for encryption. This key never leaves the disk in plaintext. It is stored encrypted by a key-encrypting key (KEK), which is derived from your passphrase via a key derivation function (KDF). LUKS2 uses Argon2id by default; VeraCrypt uses PBKDF2-HMAC-SHA512 or Whirlpool with high iteration counts; FileVault uses PBKDF2.

The KDF is the rate-limiting factor against brute force. Argon2id won the Password Hashing Competition in 2015 and is deliberately memory-hard — each derivation requires a configurable amount of RAM, making GPU-accelerated cracking expensive. A well-tuned Argon2id configuration on a modern laptop targets roughly 1 second of unlocking time, which translates to billions of times slower than raw AES for an attacker.

TPM integration adds a hardware root of trust. The TPM (Trusted Platform Module, mandatory on Windows 11 hardware) can seal the KEK against a set of Platform Configuration Register (PCR) measurements — hashes of the firmware, bootloader, and kernel. If any component changes, the PCR values change, the seal breaks, and the TPM refuses to release the key. BitLocker in its default configuration uses this mechanism. The trade-off: the passphrase is not required at boot on an unmodified system, which is convenient but means a stolen powered-on device (e.g., during a border crossing) is vulnerable.

Panorama by Platform

Solution	Default cipher	KDF	TPM integration	Open source	Cross-platform
LUKS2 (Linux)	AES-XTS-256	Argon2id	Optional (systemd-cryptenroll)	Yes	No
BitLocker (Windows)	AES-XTS-128 or 256	Scrypt (Win 11 22H2+)	Default on modern hardware	No	No
FileVault 2 (macOS)	AES-XTS-128	PBKDF2	Apple T2/M-series Secure Enclave	Partial	No
VeraCrypt	AES-XTS-256 (or cascades)	Argon2id / PBKDF2	None	Yes	Yes

BitLocker (Windows)

BitLocker ships with Windows Pro, Enterprise, and Education. On Windows 11 hardware manufactured after 2023, device encryption is increasingly enabled by default during the Out-of-Box Experience if you sign in with a Microsoft account — and the recovery key is silently uploaded to your Microsoft account in the cloud. This behavior is documented by Microsoft (learn.microsoft.com) but surprises many users. If you are in a threat model where a government subpoena to Microsoft is a realistic concern, this default is a problem. The mitigation is to configure BitLocker manually with a local account and store your recovery key offline.

BitLocker defaults to AES-XTS-128. Administrators can push AES-XTS-256 via Group Policy. Windows 11 22H2 introduced Scrypt as a KDF option, replacing the older PBKDF2-SHA256 that was criticized for insufficient iteration counts.

FileVault (macOS)

FileVault 2, introduced in OS X Lion (2011), uses CoreStorage or APFS encryption depending on macOS version. On Apple Silicon and T2 machines, the encryption is always active at the hardware level; FileVault adds the passphrase requirement that protects the volume key at rest. The Secure Enclave enforces rate limiting on unlock attempts independently of the OS — an important defense against offline attacks that attempt to bypass the software stack. Recovery keys can be escrowed to iCloud or stored locally; if escrowed to iCloud, Apple holds them.

VeraCrypt

VeraCrypt is the maintained successor to TrueCrypt, which was audited in 2015 (iSEC Partners audit) and found to have no critical vulnerabilities. VeraCrypt has been independently audited as well (Quarkslab, 2016). The current stable release as of June 2026 is 1.26.29.

VeraCrypt’s distinctive feature is hidden volumes: an encrypted container holds a decoy volume (opened with one passphrase) and a hidden volume (opened with another). Under coercion, you reveal the decoy passphrase; the existence of the hidden volume is cryptographically deniable. This feature requires discipline to use correctly — writing to the outer volume can overwrite the hidden volume — but it is the only widely available, audited implementation of plausible deniability for stored data.

Linux Full Disk Encryption Step by Step

Linux full disk encryption is handled by the kernel’s dm-crypt subsystem via the cryptsetup userspace tool. LUKS2 has been the default format since cryptsetup 2.1 (released 2019).

Installation-time setup

Every major distribution installer — Fedora, Ubuntu, Debian — offers FDE as a checkbox option during installation. This is the recommended path for most users. The installer handles partition layout, GRUB configuration, and initial key derivation automatically.

Ubuntu uses LUKS2 with Argon2id and a 32-byte key by default. Fedora uses the same with slightly different Argon2id parameters tuned to the hardware detected at install time.

Manual LUKS2 setup

For external drives or custom configurations:

# Overwrite the partition with random data first (time-intensive but recommended)
sudo dd if=/dev/urandom of=/dev/sdX bs=4M status=progress

# Format the partition as LUKS2 with Argon2id
sudo cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha256 \
  --pbkdf argon2id \
  --iter-time 3000 \
  /dev/sdX

# Open the encrypted partition (maps it to /dev/mapper/secure)
sudo cryptsetup open /dev/sdX secure

# Create a filesystem on the mapped device
sudo mkfs.ext4 /dev/mapper/secure

# Mount it
sudo mount /dev/mapper/secure /mnt/secure

The --iter-time 3000 flag tells cryptsetup to calibrate Argon2id so that key derivation takes approximately 3 seconds on the current hardware. Adjust down (to 2000) if the machine is very slow or up (to 5000) for higher security on fast hardware.

Back up the LUKS header

This step is critical and almost universally skipped by first-time users. The LUKS header contains the key slots and the encrypted volume key. If it is corrupted — by a failing drive, a botched partition operation, or a random write — the data on the volume is permanently and irrecoverably lost.

# Back up the header to an external location
sudo cryptsetup luksHeaderBackup /dev/sdX \
  --header-backup-file /path/to/external/drive/sdX-luks-header.img

# Verify the backup is readable
sudo cryptsetup luksDump --header /path/to/external/drive/sdX-luks-header.img

Store this header backup in at least two physically separate locations. It does not contain the passphrase — the header alone cannot decrypt your data — but without it you cannot even attempt decryption.

If a header is corrupted and you have no backup, some professional data recovery services list LUKS header reconstruction as a supported operation, but success is not guaranteed and depends on the extent of corruption.

Encrypting External Drives and USB Keys

The same cryptsetup luksFormat workflow applies to USB drives. On Windows, BitLocker To Go handles external drives and is readable on any Windows Pro or Enterprise installation without additional software. On macOS, the Finder’s “Encrypt” option on an APFS-formatted drive uses FileVault-style encryption. VeraCrypt containers are portable across all three platforms, making them the pragmatic choice for drives that move between operating systems.

One operational note: a LUKS-encrypted drive that is unlocked and mounted does not require re-authentication for the duration of the session. Unmount and close the mapper before leaving the drive unattended.

sudo umount /mnt/secure
sudo cryptsetup close secure

Passphrases, Backup, and Operational Realities

Choosing a strong passphrase

The KDF limits the attacker’s throughput, but it cannot compensate for a weak passphrase. A six-word Diceware phrase (EFF wordlist) provides approximately 77 bits of entropy — sufficient against any realistic offline attack with Argon2id properly configured. Eight words (roughly 100 bits) is comfortable for a drive you expect to remain relevant for a decade.

Avoid dictionary phrases, names, dates, or anything you would use as a password on a web service. The passphrase protects a key you cannot change (without re-encrypting the entire volume), so treat it accordingly.

The backup problem

This is where full disk encryption kills more data than attackers ever will.

An encrypted drive is a single point of failure. If the drive dies, the LUKS header is corrupted, or you forget the passphrase, the data is gone. There is no recovery path. Encryption does not make data more resilient — it makes it more fragile in the absence of a backup strategy.

The canonical answer is an off-site encrypted backup. The backup itself should be encrypted at rest (so you are not trading disk encryption for unencrypted cloud storage), and the encryption should be end-to-end so the cloud provider cannot access plaintext.

Back up the LUKS header separately from the data. Store recovery keys (BitLocker) or FileVault personal recovery keys in a physically secure location — printed on paper in a safe is a legitimate strategy for keys you hope never to use.

Verdict

For most users, the right choice is the built-in solution for their OS, properly configured:

Linux: LUKS2 at installation time via the distribution installer. Back up the LUKS header immediately. Consider systemd-cryptenroll with a TPM for PIN-based unlock if the hardware supports it.
Windows: BitLocker with AES-XTS-256 via Group Policy, using a local account, with the recovery key stored offline — not in your Microsoft account.
macOS: FileVault enabled, recovery key stored locally (not escrowed to iCloud unless that trust model is acceptable), with Time Machine backups to an encrypted volume.
Cross-platform / portable drives / hidden volumes: VeraCrypt 1.26.29. Audit-backed, open source, and the only mainstream option with plausible deniability.

FDE is a solved problem at the technical level. The failure modes are almost entirely operational: forgotten passphrases, lost recovery keys, no header backups, and misunderstanding the threat model. Solve those, and your data at rest is protected against a realistic adversary with physical access.

For the historical context on how these tools were discussed before they became mainstream, see the archived Secure Desktops mailing list discussions, which tracked this space from 2015 to 2017 when LUKS2 and the new KDF standards were still being finalized.

Related reading: Tails OS and LUKS Persistent Storage covers how Tails uses LUKS to protect the persistent storage volume across sessions. Qubes OS enables full disk encryption by default at installation, integrated with its domain-isolation security model.