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.
Turning it on across platforms
One reason full disk encryption is worth recommending to almost everyone is that, on modern devices, it is built in and free; the main task is simply knowing where to switch it on and how to keep the recovery key. The details differ by platform, but the principle is the same everywhere: enable it, store the recovery key somewhere you will still have it if the device dies, and then largely forget about it.
On Windows, the feature is called BitLocker, and it is the standard choice on Windows Pro and Enterprise editions, configured through the system settings or managed centrally in a workplace. A notable catch affects Windows Home: 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, so it is worth checking rather than assuming. Where BitLocker is in use, the recovery key is often backed up to your Microsoft account, which is convenient but also means a copy sits with Microsoft — a trade-off worth understanding. On macOS the feature is FileVault, found in the system settings under privacy and security; it is straightforward to enable and gives you the choice of storing the recovery key with Apple or keeping it yourself, and keeping it yourself is the more private option if you can store it safely.
On Linux, encryption is typically set up with LUKS, most easily by choosing the "encrypt the disk" option during installation; retrofitting it to an existing system is possible but more involved, so enabling it at install time is far simpler. Mobile devices are the reassuring case: modern iPhones and Android phones are encrypted by default, with the encryption tied to your passcode, which is one of the strongest practical 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 all of these, the single habit that matters most is recording the recovery key somewhere independent of the device itself, because, as the usability section below explains, encryption that locks out its own owner has failed.
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.
Device encryption is not cloud encryption
A crucial and widely misunderstood limit of full disk encryption is that it 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, or shared into a messaging service — they are governed by that service's protections, not by your device's encryption. A perfectly encrypted laptop offers no protection at all for the photographs and documents that the same laptop is quietly uploading to a cloud account, because there they sit under whatever security the provider chooses to apply.
This distinction has become sharply practical in the UK. Most mainstream cloud backups are encrypted in a way that lets the provider itself access the data, which means it can be handed over in response to a legal demand. A smaller number of services offer true end-to-end encryption of 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 is that device encryption remains strong and lawful, while the encryption of your data in the cloud is precisely the protection under the most active pressure.
The practical response is to be deliberate about where your data actually rests. Treat full disk encryption as protecting the device against loss and theft, which it does well, but assume that 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 at rest on one device and encryption of your data everywhere it travels are two different problems, and solving the first does not solve the second.