Encrypting drives and files: BitLocker, FileVault, LUKS and VeraCrypt

Turn on the full-disk encryption your operating system already ships with, and be clear about what it buys: protection for a device that is powered off, lost, or thrown away. Microsoft states BitLocker's purpose as addressing "data theft or exposure from lost, stolen, or inappropriately decommissioned devices," and nowhere claims it stops malware in your own session.

Encrypted at rest means encrypted while off

BitLocker's FAQ describes the mechanism plainly: encrypted sectors "are decrypted only as they're requested from system read operations." Once Windows has booted and the volume is available, every process running under your account reads plaintext through ordinary file I/O. Ransomware included. The same holds for FileVault, which Apple calls a "built-in encryption capability, to secure all data at rest," and for any mounted LUKS volume.

Microsoft's BitLocker countermeasures documentation is entirely about protecting the key before and during boot: TPM binding, Secure Boot integrity protection via the TPM PCR[7] measurement, DMA port restrictions, anti-hammering on PIN entry, and the TCG Reset Attack Mitigation, better known as the MOR bit, which overwrites memory before keys are extracted into it. All of them target physical access to a powered-off or locked machine, and none is a runtime file protection. Treating disk encryption as an antivirus substitute is the single most common misunderstanding here.

VeraCrypt refuses to use a TPM at all, on the grounds that "the only thing that TPM is almost guaranteed to provide is a false sense of security." The reasoning holds as far as it goes: an attacker with admin rights on a running machine can pull keys from RAM no matter what sealed them. It is still the wrong conclusion for most people, because a sealed key forces a thief to attack a live system instead of just removing the SSD.

Microsoft grades that tradeoff by attacker, not by device. It calls TPM-only "more convenient for sign-in but less secure than the other options," yet still names it the right mitigation for an opportunistic thief who will not open the case. It reserves TPM with a PIN, ideally an enhanced PIN using the full keyboard, for an "attacker with skill and lengthy physical access" and for secure administrative workstations. Its FAQ adds that hardware meeting Windows Hardware Compatibility Program requirements makes a PIN "less critical as a mitigation." Choose by threat model, not by whether the laptop leaves the house.

Full disk, container, per file

Microsoft draws the line between the first and third models in one sentence: "BitLocker helps protect the entire operating system drive against offline attacks, whereas EFS can provide additional user-based file level encryption for security separation between multiple users of the same computer." Full-disk covers everything including swap and temp files, and stops mattering the moment you sign in.

VeraCrypt is the only one of the four that does all three. It creates a virtual encrypted disk inside a file and mounts it as a real disk, encrypts whole partitions and devices, and encrypts a Windows system partition with pre-boot authentication. The container model earns its place in one case: files that stay sealed while the computer is running, because you have not mounted them.

A container is not redundant with your filesystem. Microsoft's own comparison table lists file-system-level encryption as NTFS yes, exFAT no, UDF no, FAT32 no. An exFAT external drive, the default format for cross-platform portability, has zero encryption by virtue of its format.

The recovery key is the actual risk

Losing data to a thief is rare. Locking yourself out is not, and each tool fails differently.

BitLocker throws a volume into recovery mode on a long list of ordinary events Microsoft publishes: clearing or disabling the TPM, a TPM self-test failure, replacing the motherboard, a BIOS or UEFI firmware upgrade, changes to the Platform Configuration Registers used by the validation profile, moving the drive to another computer, docking or undocking a laptop, and wrong PIN entries. TPM firmware updates are the nastiest because they are inconsistent: some clear the TPM outside the Windows API and some do not, so Microsoft advises testing first. Before any planned hardware or firmware change, suspend BitLocker rather than decrypt, which "leaves the drive fully encrypted" and reseals the key on resume without demanding the 48-digit recovery password. Skip it and Microsoft is blunt: BitLocker "is designed to make the encrypted drive unrecoverable without the required authentication."

Two Windows facts contradict a lot of older writing. BitLocker's default is AES-128, not 256, with 256 available through policy, and consumer Device Encryption defaults to XTS-AES 128-bit. And starting in Windows 11 version 24H2, the DMA and HSTI/Modern Standby prerequisites for Device Encryption were removed, so far more machines auto-encrypt than guidance from a few years ago implies. Sign in with a local account only, though, and nothing is escrowed: Microsoft's phrasing is that the device "remains unprotected even though the data is encrypted." Full BitLocker management, unlike automatic Device Encryption, is still gated to Pro, Enterprise, Pro Education/SE and Education; Home is absent from Microsoft's edition table entirely.

Apple prints the bluntest warning of the four: if you forget your login password, cannot reset it, and also forget your recovery key, "you won't be able to log in, and your files and settings will be lost forever." On Apple silicon and T2 Macs all FileVault key handling happens in the Secure Enclave and keys are never directly exposed to the CPU, making the hardware part of the key. For organizations, Apple advises against the old shared Institutional Recovery Key, which "can't be used to access recoveryOS," in favor of a per-device Personal Recovery Key escrowed to a device management service, or a Bootstrap Token that macOS 10.15.4 and later escrows automatically on first login by a Secure Token enabled user.

Linux: the defaults are already right, the header is not backed up

cryptsetup is actively maintained, with v2.8.7 released on 2026-07-21. LUKS has defaulted to aes-xts-plain64 since cryptsetup 1.6.0, and LUKS2's default password KDF switched from Argon2i to Argon2id in 2.4.0, which the release notes justify as giving "better protection to side-channel attacks while still providing protection to time-memory tradeoffs." That matches RFC 9106, the Argon2 specification, which is Informational, dates from 2021, has not been obsoleted, and requires that "Argon2id MUST be supported." The memory-hard property is the point: the default "has a large-memory property and massively reduces the advantages of GPUs and FPGAs" against anyone brute-forcing your passphrase.

What you do need is a header backup. The cryptsetup FAQ names the failure directly: "Overwriting the LUKS header in part or in full is the most common reason why access to LUKS containers is lost permanently." There is no passphrase recovery path and no escrow. Back up the header with cryptsetup luksHeaderBackup before partitioning work, firmware flashes, or anything else that writes near the start of the device, and store it off the encrypted disk.

VeraCrypt: no vendor, no safety net, and a recent hidden-volume bug

VeraCrypt's current stable release is 1.26.29, published in June 2026. It added Argon2id as an alternative KDF, but only for non-system volumes, so system-partition encryption still relies on PBKDF2. That release also fixed CVE-2026-53762 and CVE-2026-54073, the second of which is worth acting on: hidden volumes created with quick format used an allocation shortcut that "wrote plaintext zero sectors at 128 MiB intervals," undermining the plausible deniability that is the entire reason hidden volumes exist. If you created one that way on an older build, recreate it. Check your download source: the project's repository names veracrypt.jp as primary and veracrypt.io as a mirror, and the older veracrypt.fr address now redirects there.

The slow mount is deliberate: where TrueCrypt used 1,000 iterations for a system partition and at most 2,000 for containers, VeraCrypt defaults to 200,000 and 500,000.

There is no recovery path. VeraCrypt states it has implemented no backdoor and never will, and that the project cannot recover your data because it does not know and "cannot determine the password you chose." The only route back in is brute force, which for a strong password could take "thousands or millions of years." That makes VeraCrypt the highest access-risk option of the four. Write the passphrase down and store it physically.

Moving an encrypted drive between operating systems

BitLocker To Go covers USB sticks, SD cards and external disks formatted NTFS, FAT16, FAT32 or exFAT, but every mechanism Microsoft documents for opening one, the Control Panel item, manage-bde.exe, and the recovery screen, is Windows-side. Microsoft never mentions macOS or Linux, so treat Windows-only native access as an inference from that silence, not a stated guarantee. Encrypting an external drive with Mac Disk Utility gives an APFS-encrypted volume, since Apple's instruction is to "format it as APFS and encrypt it with a password to protect its contents," and Windows has no native APFS support: Microsoft's comparison page names NTFS, exFAT, UDF and FAT32 as the four main Windows file systems. LUKS is Linux-only in practice, and cryptsetup's documentation never discusses Windows or macOS interoperability.

For a drive that has to work on two or more platforms, format it exFAT and put a VeraCrypt container on it. VeraCrypt is the only one of the four with official installers for Windows, macOS and Linux from a single project. On a Mac it needs macOS Monterey 12 or later plus macFUSE or FUSE-T, with the FUSE-T build recommended for Apple silicon, so budget one extra install per Mac.