Disk encryption, really?

I watched a corporate laptop get emptied in under five minutes in a control room. The machine was “encrypted” — IT had certified it, the compliance sticker was stuck to the back. Except it was asleep, lid closed, dropped in a bag in the executive’s car for the length of a lunch. The keys were in RAM, the session open. The person who grabbed the bag didn’t need to know the password. They plugged in a box, bypassed the lock screen, and copied whatever they wanted. The disk was encrypted. The data was not.

The usual trap

“My disk is encrypted.” It’s one of the most misunderstood sentences in all of information security. In 95% of cases it means “I ticked a box in the settings” or “IT turned on BitLockerMicrosoft disk encryption integrated into Windows Pro/Enterprise.See glossary at deployment.” It does not mean “my data is protected right now.” These are two different claims, and the confusion between them is exactly what an attacker with physical access is counting on.

Disk encryption protects your data in one precise, unique state: when the machine is powered off. That’s it. The moment the system is booted and you’re logged in, the decryption keys are loaded into RAM and every file becomes readable as if encryption didn’t exist. The operating system decrypts on the fly, continuously, completely transparently — that’s precisely the point: you shouldn’t feel any difference in daily use. But that transparency for you is also transparency for anyone who gets their hands on the machine in that state.

So the right question is never “is it encrypted?” It’s “what state is my machine in at the moment a third party can reach it?” Powered off, asleep, hibernated, screen locked: these four states offer radically different levels of protection with exactly the same encryption enabled. The dominant narrative — “turn on encryption and you’re safe” — papers over all that nuance. And it’s in that papered-over nuance that nearly every successful data extraction from “encrypted” hardware lives.

The other half of the trap is believing encryption defends against threats it was never meant to cover. Disk encryption does nothing against malware running in your session: the malicious program reads your decrypted files exactly as you do. It does nothing against phishing, against a stolen password, against remote access to your powered-on machine, against a poorly protected cloud backup. Nor does it protect your data once it has left the disk — an emailed attachment, a file copied to a USB stick, a document opened in an app that syncs. Disk encryption answers a single, narrow but real question: “someone takes my hardware physically, what can they get out of it?” Mistaking that point-in-time protection for general protection is like thinking a door lock protects you while the window is wide open.

The four states: when it protects, when it doesn’t

The same encryption, enabled exactly once, protects you completely or not at all depending on the state of the machine. Here are the four, from safest to most exposed.

Machine powered off (cold state). The only state where encryption does its full job. The disk holds nothing but encrypted data, the key is nowhere in memory, and anyone who steals the disk or the machine reads nothing without the passphrase or the recovery key. This is the scenario disk encryption was designed for: theft of powered-down hardware. In that precise case, FileVaultDisk encryption integrated into macOS since OS X Lion.See glossary, BitLocker, and LUKSDisk encryption standard on Linux, via cryptsetup and dm-crypt.See glossary deliver on their promise.

Machine hibernated. Hibernation writes the contents of RAM to the encrypted disk, then cuts power. Configured properly, it’s nearly as solid as a full shutdown, because RAM is flushed and encrypted to disk. On Windows with BitLocker and a PIN, hibernation protects correctly. On Apple Silicon Macs, deep sleep locks the keys in the Secure Enclave. The trap: many machines are configured never to hibernate and to stay in plain sleep indefinitely.

Machine asleep (sleep / suspend). The default state when you close the lid. RAM is kept powered, so the decryption keys are present in it, in the clear. An attacker with physical access can extract them — through memory forensicsDiscipline analyzing digital traces after an incident to reconstruct what happened.See glossary, through a DMACryptographic chip on the motherboard storing keys and attesting boot integrity.See glossary attack on a poorly locked-down Thunderbolt port, or through cold boot — and decrypt the disk without ever knowing your password. It’s the most dangerous state precisely because it’s the state your laptop spends most of its life in.

Machine powered on, screen locked. The volumes are mounted and decrypted. The lock screen is a software door in front of an already-open disk. Bypassing that screen doesn’t touch the encryption at all — it goes after the session authentication system, which has its own attack surface (local accounts, login-screen exploits, debug ports). Encryption, here, plays no protective role whatsoever.

The practical consequence is brutal and counter-intuitive: the machine you believe is “protected because encrypted and locked” in your bag, in a meeting, at the hotel, is in the least protected state there is. Closing the lid secures nothing. Only a full shutdown brings the machine back to cold state.

Put yourself in the attacker’s shoes for two minutes — it’s the only way to understand why state matters more than encryption. You get hold of a laptop in a bag. First thing you do: check if it’s warm, if the LED is blinking, if a screen lights up when you move the mouse. A warm machine asleep is a gift. You plug it into mains so it doesn’t power off, you set it on an analysis station, and you work on a target whose keys are already in memory. The session password doesn’t even interest you. Conversely, a cold, powered-off machine leaves you facing an encrypted block: you can keep it for months, run brute-force against it, and it’ll yield nothing if the passphrase is sound. That asymmetry is exactly what most people cancel out by simply closing the lid instead of shutting down.

The correct threat model, then, is not “am I at risk of having my bare SSD stolen?” — a rare scenario, which assumes someone unscrews your machine — but “in what situations does my machine leave my control, and what state is it in at that moment?” The honest answer for most people: in a meeting (locked, mounted), on a train (asleep), at the hotel during breakfast (asleep), handed to a repair shop (powered on or asleep), seized at a border (depending on your discipline). In almost all of those cases, sleep or lock dominate, and encryption plays no real protective role.

By OS: what’s actually implemented, and where it breaks

All three systems encrypt. What distinguishes them is what happens at boot and at unlock — and that’s where the real differences in protection play out.

macOS — FileVault 2. XTS-AES-128 encryption on APFS volumes. On Macs with a T2 chip (high-end Intel since 2018) and all Apple Silicon, the hardware keys are managed by the Secure Enclave and never transit RAM in an exposed way. Concretely, on an M-series MacBook, closing the lid triggers a genuine key lock by the Secure Enclave; the quick wake comes from re-acquiring the key at unlock, not from a key left in memory. That’s architecturally far more solid than anything before the T2.

A detail that surprises a lot of Mac users: on Apple Silicon, the system volume is in fact permanently encrypted at the hardware level, independently of FileVault. What FileVault adds is the requirement for a user credential to release the key at boot. Without FileVault, the key is derivable without a password, and a stolen Mac boots straight to the desktop of a passwordless account. In other words, “the disk is encrypted” is technically true even with FileVault off — and completely misleading, because without FileVault the encryption protects you from nothing. It’s the perfect example of the gap between “encrypted” and “protected.” The remaining weak point isn’t technical but organizational: at setup, macOS offers to store the recovery key in iCloud. If you accept, the protection of your disk becomes only as strong as your Apple account — and no stronger. A phished Apple ID, and the key follows.

Windows — BitLocker. The most widely deployed system in the enterprise, and the one most often botched at configuration. BitLocker can run in TPMCryptographic chip on the motherboard storing keys and attesting boot integrity.See glossary-only mode: the key is derived from the TPM 2.0 at boot and, if the boot integrity measurements match, the disk decrypts on its own, with no input at all. That’s the convenient default of many large fleets, because no help desk enjoys handling “I forgot my PIN” tickets. It’s also the hole: a stolen machine with a charged battery boots and decrypts itself up to the login screen, and some attacks (DMA, sniffing the bus between TPM and CPU on insecure hardware) recover the key without knowing anything. Researchers have publicly extracted BitLocker keys by listening to the LPC or SPI bus between a discrete TPM and the processor on cheap machines — the operation needs a soldering iron and a few tens of euros of kit, not a state lab.

TPM + PIN mode, by contrast, requires a code before the OS loads: the key is derived jointly from the TPM and from what you type. The PIN never leaves the secure-boot perimeter, and without it the TPM releases nothing. It’s the only BitLocker configuration I consider serious against machine theft. Enable it via Group Policy (Require additional authentication at startup) or on the admin command line: manage-bde -protectors -add C: -TPMAndPIN. An even stricter variant, TPM + PIN + USB startup key, exists for highly exposed profiles, at the cost of painful day-to-day ergonomics.

Linux — LUKS / dm-crypt. The standard layer under Linux, and conceptually the most transparent: no silent automatic unlock by default, protection rests on the passphrase entered at boot. What you type is what protects you, full stop. LUKS2 (default on Ubuntu 20.04+, Fedora 33+) uses Argon2id as its key-derivation function — resistant to GPU and ASIC attacks, unlike the old PBKDF2. Concretely, Argon2id forces the attacker to commit memory and time to every password attempt, which makes massive GPU brute-force economically uninteresting; PBKDF2, by contrast, fell at industrial rates. LUKS also handles up to eight key slots (keyslots): you can have a human passphrase, a long recovery key stored offline, and a network unlock mechanism (Clevis/Tang) for servers, each in its own slot, independently revocable.

The classic trap under Linux isn’t the encryption of the main disk but what slips past it: swap and /boot. If your swap partition isn’t encrypted, fragments of keys and sensitive data leak to disk in the clear — a full memory dump can land there during a hibernation. The /boot partition is traditionally in the clear because the bootloader must read it before any decryption; an attacker can modify the kernel or initramfs there (the so-called “evil maid” attack) to capture your passphrase at the next boot. The LVM-on-LUKS configuration (the entire volume group, swap included, inside an encrypted container) solves the swap problem; signing the boot via Secure Boot or a /boot on a USB stick you keep on you addresses the evil maid. Quick check: lsblk -f should show your sensitive partitions as crypto_LUKS, not as bare ext4.

The right approach: configure for the state, not for the box

Turning encryption on is a five-minute decision you make once. Making it genuinely protective comes down to three settings that almost everyone forgets.

First setting: the pre-boot lock. On BitLocker, that’s the PIN (TPM + PIN mode). On LUKS, it’s the passphrase at boot (already the default). On macOS Apple Silicon, the Secure Enclave plays this role natively as soon as FileVault is on. Without that lock before the OS loads, encryption protects only against theft of the bare disk pulled out of the machine — not against theft of the whole machine, which is the realistic scenario. It’s the difference between “protected against someone who unscrews my SSD” and “protected against someone who walks off with my laptop.”

Second setting: the lid-close behavior. Force hibernation or shutdown rather than plain sleep for any mobile context. On Windows, hibernation after a short idle delay. On Linux, configure suspend-then-hibernate or disable sleep in favor of hibernation. The goal: have the machine leave the state where keys live in RAM on its own, without depending on your discipline.

Third setting, the most sabotaged: recovery-key storage. The recovery key grants full access to the disk with no other verification. It’s a master key. Storing it in iCloud on the machine it protects, in a Microsoft account without MFA, in a text file on the desktop, or in an email “sent to yourself,” cancels the encryption through the back door. The rule is simple: the recovery key lives on a medium separate from the device it protects. A paper copy in a safe, or a password managerApplication storing and generating unique passwords for each service.See glossary encrypted with strong MFA installed on another device. Never on the machine in question.

One last point about the recovery key that almost nobody bothers to explain: it isn’t only there to bail out a forgotten password. On BitLocker, the TPM measures the boot state; any firmware update, change to boot order, or BIOS reset alters those measurements and triggers a recovery-key prompt at the next power-on. That’s normal behavior, not an attack — but if the key is nowhere to be found, you’re locked out of your own machine after a single slightly aggressive Windows update. Hence the importance of a clean escrow: the key must be recoverable by you, somewhere you control, and inaccessible to anyone else. Those two requirements pull in opposite directions, and that tension is the whole challenge of storing it.

And before any of that: verify that it’s actually on. On machines that have been reassigned, migrated, or re-provisioned, encryption sometimes turns itself off without anyone noticing — a system reinstall that doesn’t re-enable FileVault, an added unencrypted volume, a fleet inherited from an acquisition. sudo fdesetup status on macOS should show FileVault is On. Get-BitLockerVolume -MountPoint C: on Windows should show ProtectionStatus: On with a protector of type TpmPin — if you see only Tpm, you’re in PIN-less mode, to be fixed. sudo cryptsetup luksDump /dev/sdaX on Linux confirms the format (LUKS2) and the derivation function (argon2id). You verify, you don’t assume — and you re-verify after every heavy maintenance operation.

What it means in practice

Mistakes we see all the time

• BitLocker with no PIN, the deployment default. The machine decrypts itself at boot. Protection against bare-disk theft only, not against theft of the machine.
• FileVault recovery key in iCloud, on the Mac it protects. Compromising the Apple ID is enough to recover the key. Encryption becomes only as strong as the iCloud password.
• Machine put to sleep before a border. “It’s encrypted, I’m just closing the lid.” No: the keys are in RAM, the hot search reads the disk. Full shutdown, always.
• Unencrypted swap under Linux. The main disk is on LUKS, the swap is in the clear, and sensitive fragments land there. Check with lsblk -f.
• Assuming without verifying. Encryption was on six months ago, so it’s on today. False after any migration, reinstall, or machine reassignment.

Actionable checklist

• N1 Verify that FileVault / BitLocker / LUKS is actually on (fdesetup status, Get-BitLockerVolume, cryptsetup luksDump)
• N1 Identify the current lid-close behavior: sleep, hibernate, or shutdown
• N1 Store the recovery key on a medium separate from the device it protects
• N2 Enable a pre-boot lock: BitLocker PIN (TPM+PIN), LUKS passphrase, Secure Enclave on Mac
• N2 Force hibernation or shutdown on lid-close when mobile (≤ 5 min)
• N2 Check swap encryption under Linux (lsblk -f) or switch to LVM-on-LUKS
• N2 Untick cloud storage of the recovery key for exposed profiles
• N3 Systematic full shutdown before a border, customs, or a mature interception zone
• N3 For highly exposed profiles: LUKS with a strong passphrase, no automatic unlock
• N3 Annual audit of enterprise escrow: who reads the keys, logging, hardware MFA on the vault

Going further

Implementations move fast — always check the official documentation for your exact version. Apple’s FileVault documentation(opens in a new tab) details the role of the Secure Enclave by hardware, and Microsoft’s BitLocker documentation(opens in a new tab) covers TPM + PIN configuration via GPO. For Linux, the cryptsetup project page(opens in a new tab) remains the reference on LUKS2 and Argon2id. And to understand why a full shutdown isn’t paranoia, the Princeton paper on cold boot attacks(opens in a new tab) is still relevant fifteen years after publication.