3.2 Full disk encryption

Full disk encryption (FDE) stores everything on a device's internal drive in encrypted form, readable only once the device is unlocked.

It is baseline protection because you do not have to decide what to protect. It covers the whole drive, including files you forgot about, cached data, browser storage and the hidden working areas operating systems create. Once set up it is largely invisible, which makes it practical for everyday use.

Why it matters even for low-risk users

Myth: encryption is only for people with a high profile or sensitive work. Reality: everyday risks are mundane:

• a laptop left on a train;
• a phone left behind in a café;
• a second-hand device sold without proper wiping;
• a repair shop that looks at your storage more closely than expected.

In all of these, FDE stops anyone reading the data simply by connecting the drive to another machine.

Real examples are not dramatic:

• a student loses a bag with a laptop holding coursework drafts, browser-saved passwords and a copy of an ID document for a rental application;
• a charity worker travels with a work laptop holding volunteers' contact details;
• a freelancer keeps client invoices and tax records.

None of them is "high risk". All of them would face unnecessary harm if that data got out.

In the UK, personal data often includes material covered by the UK GDPR and the Data Protection Act 2018, and organisations are expected to take proportionate measures to protect it. This is not a legal treatise, but the practical point is simple: if you are responsible for someone else's data, FDE is a basic safeguard. On personal devices too, it stops a simple loss becoming a privacy incident.

Turning it on across platforms

Good news: on modern devices FDE is built in and free. The main job is knowing where to switch it on and how to keep the recovery key. The principle is the same everywhere: enable it, store the recovery key somewhere you will still have it if the device dies, then largely forget about it.

Platform by platform:

• Windows: the feature is BitLocker, the standard choice on Windows Pro and Enterprise, configured in system settings or managed centrally at work. Where BitLocker is in use, the recovery key is often backed up to your Microsoft account: convenient, but it means a copy sits with Microsoft, a trade-off worth understanding.
• Windows Home catch: it offers a more limited "Device Encryption" that depends on specific hardware and a Microsoft account, and on some machines it is not enabled at all. Check, do not assume.
• macOS: the feature is FileVault, in system settings under privacy and security. Easy to enable, and you choose whether to store the recovery key with Apple or keep it yourself. Keeping it yourself is the more private option if you can store it safely.
• Linux: usually LUKS, most easily by ticking "encrypt the disk" during installation. Retrofitting it to an existing system is possible but more involved, so do it at install time.
• Phones: the reassuring case. Modern iPhones and Android phones are encrypted by default, tied to your passcode.

That phone point is one of the strongest reasons to set a proper passcode rather than a trivial one: the encryption is only as good as the secret protecting it, as discussed in 2.1.

Across every platform, the habit that matters most is recording the recovery key somewhere independent of the device, because, as the usability section below explains, encryption that locks out its own owner has failed.

Pre-boot authentication

On a fully encrypted device, the drive is unreadable until a decryption key is supplied. Pre-boot authentication is where you supply that key, before the operating system loads. It might be:

• a password typed at a start-up prompt;
• a PIN paired with a hardware security chip;
• a combination, such as a smart card and PIN in a business setting.

Modern laptops often store keys in a Trusted Platform Module (TPM). With TPM-backed encryption, the system checks the boot process has not been tampered with and only then releases the key. It can feel seamless, but it still depends on a secret you control. On many systems a PIN or password is required at start-up, so the encryption is not undone just by switching the device on.

The trade-off is convenience:

• Auto-unlock with no input: easier, but weaker against physical attacks, because anyone can start it.
• Start-up password: one more step every time you power on.

For most people, a short but strong passphrase or PIN is the right balance. Make the start-up secret different from your everyday login, and do not rely on biometrics alone: fingerprints and face recognition generally unlock the operating system after boot rather than protecting the drive itself.

Sleep, hibernation and memory risk

Encryption protects data at rest. While a device is running, data has to be decrypted to be used, and the decryption key is held in memory. So the state of the machine matters:

• Fully off: the key is not in memory. FDE is at its strongest.
• Asleep: memory is still powered, and the key can remain reachable by someone with physical access and specialised tools. Niche but real: some attacks can read memory from a sleeping device, especially given time and equipment.
• Hibernating: memory is written to disk and the device powers off. If the hibernation file is encrypted as part of the full disk it is protected, but safety still depends on how the system resumes. Some keep the key handy for fast resume; others make you re-authenticate.

The practical upshot: when travelling or leaving a device unattended, shut it down completely rather than leaving it asleep.

Myth: locking the screen is the same as encrypting the drive. Reality: screen locks stop casual access but do nothing if the drive is removed or the machine is analysed offline.

Myth: "sleep is just as good as off". Reality: it is not. Sleep is fine day to day, but for higher-risk moments, power down and require pre-boot authentication on the next start.

Performance and usability trade-offs

On modern hardware, the performance cost is typically small. Most CPUs have built-in encryption acceleration, and modern operating systems use it. You might notice it in battery life on older machines, or in heavy disk work such as large file copies or databases. For browsing and office work, most people see no difference.

Usability matters more than speed. Forget your encryption password with no recovery key and your data can be gone for good. That is the point of encryption, but it is still a shock. So record the recovery key safely:

• personal device: written down and kept somewhere secure at home, or in a trusted password manager;
• organisational device: a managed key escrow system is common.

Servicing and resale:

• A repair technician cannot reach diagnostic files unless you unlock the system.
• An encrypted drive protects data even if the device is wiped incorrectly. When selling, you still need to remove your accounts and do a proper reset, but previous data should be unreadable even if fragments remain.

Finally, interoperability. Dual-boot setups, older operating systems and external rescue tools can be awkward with encryption. If you rely on them, plan how you will reach your data when the main system is unavailable. The usual answer is a small set of encrypted backups and a recovery USB that can unlock the disk. A little extra complexity, full protection kept, and no locking yourself out when something goes wrong.

Device encryption is not cloud encryption

A crucial and widely misunderstood limit: FDE protects the device in your hand, not the copies of your data that live elsewhere. The moment files leave the encrypted drive (synced to a cloud account, backed up to a provider's servers, shared into a messaging service), they are covered by that service's protections, not your device's encryption.

A perfectly encrypted laptop does nothing for the photos and documents it is quietly uploading to a cloud account. There, they sit under whatever security the provider chooses to apply.

This has become sharply practical in the UK:

• Most mainstream cloud backups are encrypted in a way that lets the provider access the data, so it can be handed over in response to a legal demand.
• A smaller number of services offer true end-to-end encrypted backups, where not even the provider can read them.
• But, as set out in 17.5, one major provider withdrew exactly that option for UK users in 2025 after government pressure.

The result: device encryption remains strong and lawful, while cloud encryption of your data is precisely the protection under the most active pressure.

So be deliberate about where your data actually rests. Treat FDE as protection against loss and theft, which it does well, and assume anything synced to a standard cloud account is potentially accessible to the provider and, through it, to others. For genuinely sensitive material, keep your own encrypted backups under keys you control (the container approach in 3.4) rather than relying solely on a provider's cloud.

Encryption on one device and encryption of your data everywhere it travels are two different problems. Solving the first does not solve the second.