Full disk encryption, and the things it does not protect you from

Why this matters

Encryption is the one control that still works when an attacker has the hardware in their hands, which makes it the answer to a whole family of scenario questions — the stolen laptop, the disposed drive, the machine left in a taxi.

It is also the control most often misunderstood in the other direction. Users and technicians alike describe an encrypted machine as "secure", which invites them to relax about things encryption does nothing for. So this lesson is organised around both halves: exactly what it defends against, and exactly what it does not. The second half is where the exam's distractors live.

The lesson

What encryption at rest actually defends against: a drive that leaves the building

Encryption at rest protects data when the storage is separated from the running system. That single sentence covers every case it helps with.

Concretely, it defends against:

• A laptop stolen while powered off or hibernated.
• A drive removed from a machine and read in another one.
• A disk sent for repair, returned under warranty, or disposed of.
• A machine sold or reassigned without proper sanitisation.

In each case the attacker has the bytes and not the key, and the bytes are noise.

What makes this powerful is that it removes the entire "boot from something else and read the disk" family of attacks, which is otherwise trivial. Without encryption, a Windows password is a lock on the front door of a house with no walls: the account is protected and the data is not.

The state of the machine matters enormously and is worth being precise about:

• Powered off — fully protected. The key is not in memory.
• Hibernated — protected, because the memory image is written to the encrypted volume.
• Sleeping — not protected in the same way. The key is in memory, and attacks against a sleeping machine are practical.
• Running and logged in — not protected at all against anyone using it.

So "shut down rather than close the lid" is genuine advice before travelling, and it is the kind of specific, actionable thing worth telling a user.

BitLocker, FileVault and LUKS, and the recovery key that is the whole system

The three implementations behave the same way and differ in their management.

• BitLocker — Windows, Pro and above for full management. Encrypts whole volumes, integrates with the TPM, and escrows recovery keys to a Microsoft account, to Active Directory, or to a printed file.
• FileVault — macOS. Whole-volume, enabled during setup or afterwards, with the recovery key held by the vendor account or written down at enable time.
• LUKS — the Linux standard. Whole-volume, configured at installation, with passphrase and key-file slots.

The recovery key is the whole system, and this is the part to say out loud to every user:

• It is what gets you in when the TPM refuses, after a firmware update, a hardware change, a boot-order change, or a forgotten passphrase.
• Without it, an encrypted volume is unrecoverable. Not difficult — impossible. That is the design working correctly.
• It must be stored somewhere other than the encrypted machine. A recovery key saved as a file on the drive it unlocks is not a recovery key.

Acceptable places: the user's account with the vendor, a directory service in a managed estate, a password manager, or printed and kept somewhere physically secure. The two-minute job worth doing on every encrypted machine you touch is confirming that the key exists somewhere findable, because the machine will not tell you it is missing until the day it matters.

The TPM, what it stores, and the machine that boots without a prompt

The Trusted Platform Module is a small secure chip — or a firmware equivalent — that stores keys and measures the boot process.

What it stores: keys that cannot be extracted from it. The encryption key for the volume is sealed to the TPM, and the TPM will release it only when the machine boots in the same measured state it was sealed against.

That is why the machine boots without a prompt. The user signs in normally and never sees an encryption passphrase, because the TPM released the key automatically once the firmware, boot configuration and bootloader matched what it recorded. This is a genuine security property and not a shortcut: the key is released only to this machine booting this way, so moving the drive to another machine yields nothing.

What changes the measured state, and therefore triggers a recovery prompt:

• A firmware update.
• Changing secure boot, the boot order, or the firmware mode.
• Adding or removing certain hardware.
• Docking or undocking in some configurations.
• Clearing the TPM.

This is why an apparently unrelated firmware update produces a machine asking for a 48-digit recovery key on Monday morning, and why suspending BitLocker before a firmware update is the correct procedure. It is also why the recovery key's location matters more than anything else in this lesson.

For higher assurance, the TPM can be combined with a PIN or a startup key, so possession of the machine alone is not enough. That is the configuration for data worth protecting against someone who has the laptop.

File and folder encryption against whole-volume, and where each fits

Two granularities exist and they answer different questions.

Whole-volume encryption protects everything on the volume, including temporary files, page files, hibernation files and the traces applications leave without asking. It is transparent — anyone who can sign in sees ordinary files — and it is the right default for laptops and any machine that might leave a controlled space.

File and folder encryption protects specific items, and keeps them protected from other users of the same machine. The Encrypting File System on NTFS ties encryption to a user's certificate; encrypted archives and document passwords do something similar at the application level.

Where each fits:

• Laptop, phone, anything portable → whole-volume, always.
• Shared workstation where one user's files must be private from another → whole-volume plus file-level, because whole-volume does not separate users from each other at all.
• A file being sent somewhere → file-level, because the volume encryption ends at the edge of the volume.

The trap with file-level encryption is key management. EFS keys live in the user's profile; a user profile rebuilt, a password reset by an administrator without the right procedure, or a machine reinstalled without exporting the certificate all produce permanently unreadable files. Whole-volume encryption has one key to look after; file-level encryption has one per user and they are much easier to lose.

What it does not stop: a running machine, a logged-in user, or a phishing email

This is the half that matters for scenario questions, and it is worth being blunt about.

Full disk encryption does nothing against:

• A running machine with a logged-in user. The volume is decrypted for anyone using the session. An unlocked machine is an unencrypted machine.
• Malware running as the user. It reads files through the operating system, which decrypts them on request. Ransomware encrypts an encrypted volume perfectly happily.
• Phishing and credential theft. The attacker signs in as the user, and everything is decrypted for them.
• Data that has left the volume — copied to a memory stick, emailed, uploaded, or printed.
• Backups, unless those are encrypted separately. An encrypted laptop backing up to an unencrypted external disk has moved the problem, not solved it.
• An insider with legitimate access.

The one-line version worth remembering: encryption protects data from people who have the disk, not from people who have the session.

Which is exactly why it sits alongside the rest of this domain rather than replacing it. The screen lock, the standard account, the second factor and the patching all defend the running machine; encryption defends the machine that is no longer running, or no longer yours. A scenario that describes a stolen or disposed device wants encryption; a scenario that describes an intruder using an account does not, and encryption will be in the answers.