Disk encryption: for real this time

A border agent inspects a laptop seized in a control zone. The owner, being questioned in the next room, said “the machine is encrypted.” The agent plugs the laptop into a forensic extraction station. The machine is in sleep mode. FileVault is active. And the encryption keys are in RAM, available, ready to be read. The drive is decrypted hot in under three minutes. The owner was right — the disk is encrypted. It just isn’t protecting anything right now.

The common trap

“My disk is encrypted” is one of the most misunderstood statements in information security. It almost always means “I turned on BitLocker” or “FileVault is checked in preferences.” That is not the same thing as “my data is actually protected right now.”

Disk encryption protects your data in one specific state: when the machine is off. The moment it is powered on and the user is logged in, encryption is effectively inactive — the operating system has loaded the keys into memory, and every file on disk is accessible as if encryption didn’t exist. The relevant question isn’t “is it encrypted?” but “what state is my machine in right now?”

When encryption protects — and when it doesn’t

States where you are protected

Machine powered off (cold state): this is the only state where encryption reliably protects. The disk contains encrypted data, the key is nowhere in memory, and an attacker who steals the disk or the machine cannot read anything without the password or recovery key.

Hibernation (on certain configurations): hibernation writes the contents of RAM to the encrypted disk, then cuts power. When properly configured, this is nearly as good as a full shutdown. On Windows with BitLocker + PIN active, hibernation protects well. On macOS with Apple Silicon, “safe sleep” is encrypted and keys are locked by the Secure Enclave.

States where you are NOT protected

Simple sleep (sleep/suspend): RAM is kept powered. Encryption keys are in RAM. An attacker with physical access can extract those keys — and decrypt the drive — without knowing your password. This is the most dangerous state because it is the default state of laptops when you close the lid.

Machine on, user logged in: encryption is inoperative for mounted volumes. Any data accessible in your session is accessible to an attacker with access to the machine.

Machine on, screen locked: similar to the above. The screen is locked, but volumes are mounted and decrypted. An attacker with physical access can bypass the lock screen via vectors that have nothing to do with disk encryption.

Cold boot attacks: RAM remembers

Princeton’s 2008 study demonstrated that DRAM retains its contents for several seconds to several minutes after power is cut — especially if the memory is cooled. An attacker can cut power, remove RAM sticks, cool them with liquid nitrogen or even cold air, and read encryption keys that were in memory.

This vector is less trivial on modern machines with UEFI Secure Boot, TPM 2.0, and memory soldered directly to the motherboard (as on most recent ultrabooks). But the concept remains valid against highly motivated adversaries — and some enterprise configurations with older workstations remain vulnerable. Against a state-level threat or an actor capable of investing time and equipment, a full shutdown is the only reliable answer.

By OS: what is actually implemented

macOS — FileVault 2

FileVault 2 uses XTS-AES-128 on APFS volumes. Since Macs with the T2 chip (high-end Intel since 2018) and all Apple Silicon (M1 and later), hardware keys are managed by the Secure Enclave and never pass through exposed RAM.

What changes on Apple Silicon: when you close the lid of an M-series MacBook, the Secure Enclave actually locks the decryption keys. Fast boot is possible not because keys remain in RAM, but because they are re-acquired from the Secure Enclave at unlock. This is architecturally much stronger than pre-T2 Intel implementations.

Hibernation vs sleep on Intel: behavior depends on pmset configuration. By default, macOS uses “safe sleep” — it writes RAM to disk before entering deep sleep. On recent Intel Macs with T2, this image is encrypted. On older models, protection is weaker.

Recovery key and iCloud: when activating FileVault, macOS offers to store the recovery key in iCloud. If you accept, your encryption recovery is tied to your Apple account. If that account is compromised, so is the recovery key. For general personal use, this is an acceptable trade-off. For an exposed profile, it is not.

Windows — BitLocker

BitLocker supports several protection modes, and this is precisely where the majority of deployments fail.

TPM-only mode (default in many enterprises): the decryption key is derived from TPM 2.0 at startup. If the PCR measurements (BIOS state, boot loader, configuration) match the recorded values, the disk decrypts automatically — with zero user interaction. Convenient for large fleets. Also problematic: an attacker with access to the powered-on machine, or who can boot into a trusted Windows PE environment, can access the data.

TPM + PIN mode (strongly recommended): you enter a PIN before the OS loads. The key is derived jointly from the TPM and the PIN. Much better. Enable via GPO (Require additional authentication at startup) or from the command line: manage-bde -protectors -add C: -TPMAndPIN.

Recovery key in enterprise: in a managed deployment, recovery keys are typically escrowed in Active Directory or Azure AD — the correct practice. In personal use, many users save to their Microsoft account, sometimes without realizing it (Windows suggests this by default).

Linux — LUKS / dm-crypt

LUKS (Linux Unified Key Setup) is the standard encryption layer on Linux. dm-crypt is the underlying kernel module. It is the most transparent of the three solutions.

Key advantage: no TPM dependency by default, no silent auto-unlock. Protection is based on the passphrase entered at boot. What you type is what protects — full stop.

LUKS2 is the default format on modern distros (Ubuntu 20.04+, Fedora 33+). It uses Argon2id as the KDF (resistant to GPU and ASIC attacks, unlike PBKDF2), supports multiple keyslots, and integrates with Clevis/Tang for network unlock in controlled datacenter environments.

Things to verify: if your system uses an unencrypted swap, keys can leak into swap space. Check that lsblk -f shows your swap partition as crypto_LUKS or that swap is disabled. On configs with LVM-on-LUKS (the entire LVM group inside a LUKS container), swap is automatically protected.

Recovery keys: the worst deployment mistake

The recovery key is the fallback when you forget your password or when the TPM state changes (BIOS update, configuration change). It grants full access to the disk without any other verification. It is also a master key that many people store catastrophically.

What we actually see in practice:

• FileVault recovery key saved in iCloud, on the very machine it is supposed to protect
• BitLocker recovery key in the personal Microsoft account, protected by a weak password without MFA
• Recovery key in a text file on the desktop of the laptop in question
• Recovery key in a “sent to myself” email sitting in Gmail for three years

What you should do:

Option 1 — Paper copy in a physical safe: no digital copy, no cloud. A home safe or a notary’s vault. Slow to access, impossible to remotely compromise.

Option 2 — Encrypted password manager, off-device: if you need a digital copy, put it in a password manager with strong MFA — and explicitly on a different device than the one it protects. Your BitLocker recovery key should not be in Bitwarden installed on the same laptop.

For enterprises: MDM solution (Intune for Windows, Jamf for macOS) with key escrow in an audit-logged vault. Access to the recovery key should trigger an alert and be logged. Never in a shared spreadsheet, never in a Confluence doc with open access.

Verifying it is actually active

Don’t assume — verify. On machines that have been migrated, re-provisioned, or handed off, encryption may be disabled without anyone noticing.

macOS: System Settings → Privacy & Security → FileVault. In terminal: sudo fdesetup status. Should say FileVault is On.

Windows: Control Panel → BitLocker Drive Encryption. In PowerShell: Get-BitLockerVolume -MountPoint C:. The ProtectionStatus field must say On and KeyProtector must list your protection method (TPMAndPIN or similar).

Linux: sudo cryptsetup luksDump /dev/sdaX for volume details. lsblk -f to see the mounted volume hierarchy. dmsetup status for active dm-crypt volume state.

Common mistakes we see constantly

BitLocker without PIN: the enterprise default in many organizations. The machine auto-decrypts. Security only applies against bare disk theft, not against an attacker with physical access to the running machine.

FileVault with recovery key in iCloud on the same device: if someone accesses your iCloud session, they have the recovery key. If your Apple ID is phished or compromised, you’ve lost your disk protection.

Machine in sleep before border crossing: closing the lid “it goes to sleep, it’s encrypted.” No. Full shutdown before any risky situation — border crossing, hotel, conference.

Not verifying it’s active: assuming encryption is active because it was six months ago. Verify after every migration, reinstallation, or machine handoff.

• N1 Verify that FileVault or BitLocker is active and shows 'Protection On'
• N1 Identify your current sleep mode (sleep vs hibernate vs shutdown) and its implications
• N1 Store the recovery key somewhere separate from the device it protects
• N2 Enable automatic hibernation on lid close for travel
• N2 Switch to BitLocker with PIN or LUKS with passphrase (exit TPM-only mode)
• N2 Verify encrypted swap on Linux (lsblk -f)
• N2 Move recovery key to offline storage (safe, encrypted manager on a separate device)
• N3 Full shutdown before border crossings or high-risk zones — no exceptions
• N3 For high-risk profiles: LUKS with strong passphrase, no TPM auto-unlock
• N3 Enterprise recovery key audit: location, access logging, annual rotation