3.2 Full disk encryption

Full disk encryption (FDE) means everything on a device’s internal drive is stored in an encrypted form, and only becomes readable after the device is unlocked. It is baseline protection because it does not ask you to decide what to protect; it protects the whole drive, including files you forgot about, cached data, browser storage, and the hidden working areas that operating systems create. It is also largely invisible once set up, which makes it practical for everyday use.

Why it matters even for low-risk users

Many people dismiss FDE because they do not see themselves as targets. The common misunderstanding is that encryption is only for people with a high profile or sensitive work. In practice, everyday risks are mundane: a laptop left on a train, a phone misplaced in a café, a second‑hand device sold without proper wiping, or a repair shop that examines storage more closely than expected. In those situations, FDE stops anyone from reading the data simply by connecting the drive to another machine.

Real life examples are not dramatic. A student loses a bag containing a laptop with drafts of coursework, saved passwords in a browser, and copies of an ID document for a rental application. A charity worker travels with a work laptop that holds the contact details of volunteers. A freelancer keeps client invoices and tax records. None of these people are “high risk”, yet all would face unnecessary harm if that data were exposed.

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. That 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. Even for personal devices, it reduces the chance that a simple loss becomes a privacy incident.

Pre-boot authentication

When a device is fully encrypted, the data on the drive is unreadable until a decryption key is provided. Pre‑boot authentication is the step where you supply that key before the operating system loads. It may be a password typed at a start‑up prompt, a PIN paired with a hardware security chip, or a combination of factors such as a smart card and PIN in a business environment.

Modern laptops often use a Trusted Platform Module (TPM) to store encryption keys securely. With TPM‑backed encryption, the system can check that the boot process has not been tampered with and only then release the key. This can feel seamless, but it still depends on a secret you control. On many systems a PIN or password is required at start‑up, which means the encryption is not undone simply by turning the device on.

The trade‑off is convenience. A system that auto‑unlocks without any user input is easier to use but weaker against physical attacks, because anyone can start it. Conversely, requiring a start‑up password adds a step each time the device is powered on. For most people, a short but strong passphrase or PIN is the right balance. The mitigation is simple: make the start‑up secret distinct from your everyday login and do not rely on biometrics alone, as 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. When a device is running, the data must be decrypted so it can be used, and the decryption key is held in memory. That is why the state of the machine matters. If the device is fully powered off, the key is not in memory and FDE is at its strongest. If the device is asleep, memory is still powered, and the key can remain accessible to someone with physical access and specialised tools. This is a niche risk, but it is real: certain attacks can read memory contents from a sleeping device, especially if the attacker has time and equipment.

Hibernation is different. In hibernation, the contents of memory are written to disk and the device powers off. If the hibernation file is encrypted as part of the full disk, it is protected, but the safety still depends on how the system resumes. Some systems keep the decryption key in a way that allows fast resume; others require you to re‑authenticate. The practical consequence is straightforward: if you are travelling or leaving a device unattended, shutting it down completely is safer than leaving it asleep.

A common myth is that locking the screen is the same as encrypting the drive. Screen locks protect against casual access but do not protect data if the drive is removed or the machine is analysed offline. Another myth is that “sleep is just as good as off”; it is not. For day‑to‑day use, sleep is fine, but for higher‑risk moments, power the device down and require pre‑boot authentication on next start.

Performance and usability trade-offs

On modern hardware, the performance cost of FDE is typically small. Most CPUs have built‑in encryption acceleration, and modern operating systems are designed to use it. The more noticeable effects are in battery life on older machines and in heavy disk‑intensive tasks such as large file copies or database work. In everyday browsing and office work, most people do not perceive a difference.

Usability trade‑offs are often more significant than performance. If you forget your encryption password and do not have a recovery key, your data can become permanently inaccessible. That is the point of encryption, but it can still be a shock. The mitigation is to record recovery keys safely. For a personal device, that might mean writing it down and storing it in a secure place at home, or keeping it in a trusted password manager. For organisational devices, a managed key escrow system is common.

There are also implications for device servicing and resale. A fully encrypted drive protects data even if the device is wiped incorrectly, but it also means that a repair technician cannot access diagnostic files unless you unlock the system. For resale, you still need to remove your accounts and perform a proper reset, but encryption means the previous data should be unreadable even if fragments remain.

Finally, there is the question of interoperability. Dual‑boot setups, older operating systems, or external rescue tools can be awkward with encryption. If you rely on such tools, plan for how you will access data when the primary system is unavailable. The usual mitigation is to keep a small set of encrypted backups and a recovery USB that can unlock the disk when needed. This adds a little complexity, but it keeps the benefits of full protection without locking you out when something goes wrong.