Full-Disk Encryption: Why Windows Is Turnkey and Linux TPM Still Is Not

TL;DR

Full-disk encryption (FDE) scrambles everything on your drive so that a lost, stolen, or discarded device is just a useless brick to whoever ends up with it, instead of a copy of your entire life. On Windows (BitLocker) and macOS (FileVault) it is essentially turnkey: a security chip called the TPM unlocks the disk automatically at boot, so you get strong encryption with no daily friction. On Linux the encryption itself (LUKS) is excellent, but the automatic-unlock-via-TPM part is still genuinely unreliable, so the honest advice is different.

• Turn it on everywhere. An unencrypted laptop or phone that goes missing is a data breach; an encrypted one is a lost piece of hardware.
• Windows/macOS: BitLocker and FileVault use the TPM to unlock automatically. It just works. Always save the recovery key.
• Linux: use LUKS with a passphrase at boot. It is boring and bulletproof. TPM auto-unlock on Linux still breaks often, even on modern laptops, so do not rely on it for anything that matters.
• Do not bother with “encrypt my home folder only” on Linux. Full-disk is simpler, faster, and covers everything. But you must have some encryption.
• Windows Home is running BitLocker too, just without the controls: same engine, same XTS-AES 128 default as Pro. Pro does not encrypt more strongly by default, it simply lets you change the cipher (and Intune lets a business set it centrally). Check yours with manage-bde -status.
• External drives are a separate job. BitLocker To Go is Pro only (Home can read an encrypted drive but not create one), macOS and Linux do it free, and VeraCrypt covers everything, including cross-platform drives and encrypted file containers.

Now for the more technical explanation

Should you encrypt your hard drive?

FDE protects data at rest: the state your device is in when it is powered off, suspended, lost, stolen, or sent for disposal. With the disk encrypted, pulling the drive out and reading it on another machine gets an attacker nothing but noise. Without it, every file, saved password, browser session, and cached document is trivially readable.

What FDE does not do: protect you while the machine is unlocked and running. Once you have logged in and the disk is decrypted in memory, encryption is not stopping malware or someone at your unattended keyboard. FDE is about the powered-off, out-of-your-hands scenario, which is exactly the scenario a lost laptop or a decommissioned drive lands in.

The TPM, in one paragraph

A TPM (Trusted Platform Module) is a small security chip (or a firmware equivalent) that can store keys and release them only when the machine boots in a known-good state. It measures the boot process into registers called PCRs (Platform Configuration Registers), and it will only hand over the disk key if those measurements match what it expects. This is what lets Windows and macOS unlock the disk automatically: the TPM checks the boot looks right, releases the key, and you never see a prompt. It is a genuinely clever bit of engineering, and it is also the exact part that Linux still struggles with.

Windows: BitLocker, and it just works

On Windows, BitLocker plus a TPM is about as turnkey as security gets:

• On modern Windows machines the TPM unlocks the drive automatically at boot, so the encryption is invisible day to day.
• Your protection against boot tampering is built in: change the boot environment and BitLocker drops to asking for the recovery key.
• Save that recovery key. It is escrowed to your Microsoft or Entra (Azure AD) account by default, and in a managed environment it lands in Intune or Active Directory. Losing it after a firmware change or board swap is how people lose data. Print it, store it in your password manager, do not skip this.
• Want more than “unlocks for anyone who powers it on”? Add a BitLocker PIN (pre-boot authentication), so the disk will not unlock without a code even if the boot state is perfect. That closes the “stolen laptop just boots to the login screen” gap.

A word on editions, because this trips people up. “BitLocker” proper is a Pro, Enterprise and Education feature. Windows Home gets Device Encryption instead: switched on automatically on qualifying hardware, but restricted to internal fixed drives, with almost no manual control and no BitLocker To Go for removable media. If you are on Home and cannot find BitLocker in Settings, that is why.

It is still BitLocker underneath, though. Device Encryption is not some lesser, separate technology; it is the same BitLocker engine with the controls removed. You can prove it on your own machine: open Command Prompt as administrator and run

manage-bde -status

(single dash, Windows-style, not --status). On an encrypted Home device it reports the volume as BitLocker-protected and names the cipher, typically XTS-AES 128. Note that not every manage-bde subcommand works on Home, because the management surface is what the edition actually removes, but -status does, and so does manage-bde -off C: if you want to turn it back off.

The default cipher is the same on Pro, which surprises people. Both Home’s Device Encryption and Pro’s BitLocker default to XTS-AES 128. Pro’s advantage is not a stronger default, it is that you are permitted to change it, to XTS-AES 256. One catch if you plan to: set it before encrypting, because switching the method on an already-encrypted drive means fully decrypting it first.

In a managed environment, Intune makes it a policy setting. Under Endpoint security → Disk encryption, a BitLocker profile lets you pick from AES-CBC 128, AES-CBC 256, XTS-AES 128 (the default) and XTS-AES 256, and set it independently for operating-system drives, fixed data drives, and removable data drives. So “you cannot choose your cipher” is a consumer-edition restriction rather than a limitation of BitLocker itself.

One Home-specific gotcha: with a local account, Device Encryption does not switch itself on automatically. It expects a Microsoft account, because that is where the recovery key gets escrowed. Signing in locally and assuming you are encrypted is a common and unfortunate mistake, which is another reason to run the command above rather than trust the Settings toggle.

The charitable reading of all this is that Microsoft has removed decisions most home users should not have to make, and reduced the support burden of people locking themselves out. The less charitable reading is the more familiar one: the capability is present on every machine, and the controls are the thing you are paying for.

macOS is much the same story with FileVault and the Secure Enclave: switch it on and it unlocks seamlessly at login, with a recovery key you must keep.

One macOS catch worth knowing, because it is widely misunderstood. FileVault is not on by default. A modern Mac encrypts its data volume either way, which is where the “Macs are always encrypted” line comes from, but with FileVault off that key is protected only by the hardware, not by your password, so anyone who can power the machine on can read everything. The encryption is not the point; tying it to something you know is. Setup Assistant offers FileVault when you first configure a Mac, and it is worth going into System Settings → Privacy & Security to confirm you actually said yes. Once it is on, both platforms have solved the usability problem, which is why FDE adoption on them is high.

Linux: LUKS is superb, the TPM layer is the problem

Here is the nuance, and it is worth being blunt about because a lot of guides gloss over it.

The encryption itself is not the issue. LUKS (Linux Unified Key Setup) is mature, fast, and rock solid. A LUKS root volume with a passphrase you type at boot is one of the most dependable encryption setups in existence. If that is all you want, Linux FDE is a solved problem and has been for years.

The unreliable part is TPM auto-unlock, the Linux attempt to replicate the “BitLocker unlocks silently” experience using the TPM (via systemd-cryptenroll, clevis, or similar). As of 2026 this is still fragile in practice, and here is why:

• The TPM releases the key based on those PCR boot measurements. On Linux, those measurements change constantly through normal life: a kernel update, a firmware/BIOS update, a bootloader change, a Secure Boot key rotation, or a shim/GRUB update can all shift the PCRs.
• When the measurements change, the TPM refuses to release the key, and you are dropped to the recovery passphrase with no warning. In the worse cases the re-enrolment fails, stale policy files interfere, or signed-PCR-policy handling misbehaves. These are not rare edge cases; they are open, actively discussed bugs in the systemd tooling, and people hit them regularly.
• This happens even on modern hardware, including current-generation Intel laptops that on paper have everything they need. The hardware is not really the blocker; the fragility of binding a disk key to a moving boot-measurement target on Linux is.

So the practical position: do not trust TPM auto-unlock on Linux for anything you cannot afford to be locked out of, and especially not for production. It is fine to experiment with on a machine where a surprise recovery prompt is merely annoying. It is not something to build a fleet or a work device around today.

The security catch nobody mentions: TPM-only unlock is bypassable

Even where TPM auto-unlock does work reliably, there is a security reason not to use it on its own. If the TPM releases the disk key with no PIN, then:

• The machine will happily unlock for anyone who powers it on, including a thief. Automatic unlock means the disk decrypts before anyone has proven who they are.
• The key travels from the TPM chip to the CPU over a physical bus, and with brief physical access an attacker can sniff it off that bus with a logic analyser. This is not theoretical; it has been demonstrated against real devices and has a documented CVE.

The fix is the same on every platform: add a PIN. A TPM-plus-PIN setup means the disk will not unlock without something you know, which defeats both “thief just boots it” and passive bus sniffing. If you use the TPM at all, use it with a PIN, never bare.

So what should you actually do on Linux?

• For reliability and production: LUKS with a passphrase at boot. You type a passphrase once at power-on, the disk unlocks, done. It never mysteriously locks you out after an update, it does not depend on PCR gymnastics, and it is not sniffable off a bus because there is no auto-released key. It is the boring answer and it is the right one.
• If a boot passphrase is a genuine dealbreaker (kiosk, headless box, a user who will not tolerate one prompt), and you accept the caveats, use TPM plus a PIN, keep a recovery passphrase enrolled as a fallback, and expect to re-enrol after firmware or kernel changes. Go in knowing it is higher-maintenance.
• Either way, keep a recovery key/passphrase somewhere safe and offline. The number one way to lose a LUKS volume is to rely on auto-unlock and have no fallback the day the PCRs change.

Do not use “encrypt home folder only” on Linux

Older Linux installers offered per-user home directory encryption (eCryptfs). Skip it:

• It has been deprecated and dropped from modern distributions (Ubuntu removed it as an install option years ago), and LUKS full-disk is now the recommended path for new installs.
• It only protects your home directory while you are logged out, and it leaves swap, temp files, logs, and the rest of the system exposed, which is where sensitive data leaks anyway.
• Full-disk LUKS is simpler, faster (it benefits from hardware AES-NI acceleration, so the performance cost is negligible), and covers the whole disk including swap.

The only reason to reach for home-only encryption is if full-disk with a boot passphrase is genuinely impossible for you and you still need something. Even then, understand you are getting partial coverage. The right default for almost everyone is full-disk.

External drives are a separate job

Everything above concerns the drive inside the machine. External and portable drives need their own decision, and this is where the three platforms diverge sharply.

Windows: BitLocker To Go, Pro only. Encrypting a USB stick or a backup drive with BitLocker is a feature called BitLocker To Go, and it is not in Windows Home. Home will happily unlock and read a drive encrypted elsewhere if you have the password, but it cannot create one. On Home your options are to encrypt the drive on a machine running Pro, upgrade the licence, or use a third-party tool. It is a fair thing to be irritated about: a security feature behind an edition upgrade, on the one platform of the three that charges for it.

macOS: free and built in. Right-click the drive in Finder, choose Encrypt, set a password, and it encrypts in place while you carry on using it. Alternatively format it as APFS (Encrypted) in Disk Utility. The drive needs the GUID Partition Map scheme and an Apple filesystem, so an exFAT or FAT32 drive has to be reformatted first. Every Mac, no tiers, no cost.

Linux: LUKS again. The same tool that handles the system disk handles externals, with no edition or licence involved.

The catch across all three is portability. A BitLocker To Go drive expects Windows, an APFS-encrypted drive is unreadable on Windows without third-party software, and LUKS is effectively Linux-only. If the drive genuinely needs to move between systems, none of the native tools is the answer.

VeraCrypt: the cross-platform option, and the flexible one

VeraCrypt (the maintained successor to TrueCrypt) is free, open source, and runs on Windows, macOS and Linux. That makes it the sensible pick for any drive that crosses platforms, and the obvious answer for Windows Home users shut out of BitLocker To Go. It also gives you three quite different shapes to work with, which is the part people tend not to realise:

• Encrypt the whole external drive. The direct equivalent of BitLocker To Go. Plug it in, mount it in VeraCrypt, use it normally.
• Encrypt one partition and leave another in the clear. On a multi-partition drive you can protect one partition and leave the other as plain exFAT. You get a readable area any machine can open sitting alongside a protected area that needs the password, which is useful when a single drive carries both the innocuous and the sensitive.
• Use an encrypted file container. The neatest of the three. You create a single file of whatever size suits, 1 MB or 100 GB, and it sits among your ordinary files looking like nothing in particular. Its contents are entirely inaccessible until you mount it in VeraCrypt, at which point it behaves like a drive. Because it is just a file, it copies onto any filesystem, travels through sync services, and backs up like anything else.

A container plus cloud storage needs one warning, though. To OneDrive, Google Drive or Dropbox the container is a single opaque file, so any change inside it re-syncs the whole thing. Save a 1 MB document inside a 10 GB container and the sync client sees a 10 GB file that changed, and uploads all 10 GB, not the megabyte you actually altered. Dropbox has historically done clever block-level “delta” syncing that uploads only the changed parts, but it is unreliable for VeraCrypt containers and breaks after client updates, and OneDrive and Google Drive generally re-send the entire file regardless. Multiply that by every device also syncing the folder and a small edit becomes a large, slow, repeated transfer, with a real risk of sync conflicts corrupting the container if two machines write at once. The practical guidance: keep cloud-synced containers small and few, mount them only briefly, and never mount the same container on two devices at the same time. If you want client-side encryption for an active cloud folder, a per-file tool like Cryptomator fits far better, because it encrypts each file separately and only the changed file re-syncs.

VeraCrypt also ships as a portable app, so it runs straight from the stick with nothing installed, which is exactly what you want on a machine that is not yours.

One honest caveat on that last point: portable does not mean privilege-free. VeraCrypt loads a device driver to do on-the-fly encryption, and loading drivers requires administrator rights on Windows. The portable build saves you an installation, but it will not rescue you on a locked-down corporate machine where you are a standard user.

The bonus: encryption makes disposal trivial

There is a payoff beyond theft protection. If a drive was fully encrypted its whole life, then securely wiping it later is as simple as destroying the key (a “crypto-erase”): with the key gone, every byte on the disk is permanently unreadable, instantly, no multi-hour overwrite required. This is why turning FDE on from day one is worth it even if you are not worried about theft today. It turns “how do I securely destroy this drive” into “reset it.” (The data destruction guide goes into this.)

The short version

Encrypt every device, always. On Windows and macOS, BitLocker and FileVault use the TPM to make it effortless, so there is no excuse; just turn it on and save the recovery key, and add a PIN if you want pre-boot protection. On Linux, use LUKS with a passphrase at boot, because it is completely dependable, and steer clear of TPM auto-unlock for anything important: in 2026 it still breaks on ordinary firmware and kernel updates, even on modern laptops, and TPM-only-with-no-PIN is bypassable anyway. Do not bother encrypting just your home folder. And keep your recovery key, because the encryption is only as good as your ability to get back in.

Related

• Data destruction and crypto-erase: why encryption makes wiping easy
• Phishing-resistant MFA and device compliance
• Backing up before you encrypt: system rollback is not a backup
• File sync is not a backup: why your offline backup drive needs encrypting

Written by Tom Langston, IT Infrastructure and Cybersecurity.