Disk encryption and the moment it stops protecting you
What full disk encryption is actually doing
Full disk encryption, or FDE, scrambles the data on your storage drive so that anyone who reads the raw bytes without the right key sees noise instead of files. On Windows that’s BitLocker. On macOS it’s FileVault. On Linux it’s usually LUKS. Mechanically they work in similar ways: a strong encryption key locks the drive, and that key itself is protected by something you supply, a passphrase, a PIN, or a login password tied to hardware like a TPM (Trusted Platform Module) or Apple’s Secure Enclave.
When you turn the machine on, you (or the hardware chip on your behalf) prove you’re allowed to unlock it. Once that happens, the operating system holds the decryption key in memory and transparently decrypts data as programs read it and encrypts it again as they write it. You never see this happening. That’s the whole point: it’s invisible while the system is running and completely opaque while the system is off.
The problem it actually solves
FDE exists for one specific threat: someone gets physical possession of your storage while it’s powered down, and tries to read it directly. Think a stolen laptop, a lost phone, a drive pulled from a decommissioned server, or a hard disk sent for repair and never wiped. Without encryption, plugging that drive into another machine gets you the entire filesystem, no login screen required. With encryption, the drive is unreadable without the key, and brute-forcing a modern passphrase-derived key is not something that’s realistically happening on consumer hardware.
This is a genuinely strong, well-understood protection for exactly that scenario. It’s also the scenario most people picture when they hear “encryption,” which is why it’s easy to overestimate what else it covers.
Where the protection actually ends
Full disk encryption protects data at rest. The moment the drive is unlocked, that protection is off duty, not because it failed, but because that was never its job.
Here’s the mechanical reason. Once you log in and the key is loaded into memory, the operating system decrypts files on demand for any process that asks, including malware, including a remote access tool, including someone who walks up to your unlocked screen. FDE has no concept of “this request is suspicious.” It just answers the request with plaintext, because from its perspective the system has already been authenticated. Everything after that point is the job of your account permissions, your screen lock, your antivirus, and your own judgment about what you click on, not the disk encryption layer.
This is also why a stolen laptop that’s merely asleep, rather than shut down, is a different and weaker situation than one that’s fully powered off.
Sleep, hibernation, and shutdown are not the same thing
When a computer is fully shut down, the encryption key isn’t held anywhere accessible. It has to be reconstructed from your passphrase or your TPM-gated credential the next time you boot. That’s the state FDE is strongest in.
Sleep mode keeps the system’s memory powered, including the decryption key sitting in RAM so the machine can resume instantly. If someone has the device while it’s asleep, they’re attacking a machine that already has the vault open, they just need to get past the screen lock, which is a much shallower barrier than re-deriving an encryption key from scratch. This is also the premise behind cold boot attacks, where an attacker rapidly cools and pulls RAM chips to extract keys before they decay, or exploits a machine’s memory before it’s fully wiped on power loss. These attacks require physical access and specific hardware handling, they’re not a casual risk for most people, but they illustrate the underlying point: a key sitting in memory is not the same as no key existing at all.
Hibernation is its own middle case. It writes memory contents, potentially including sensitive state, to disk before powering down. Modern implementations on BitLocker, FileVault, and LUKS-based systems generally encrypt the hibernation file as part of the encrypted volume, but the exact guarantee depends on your OS version and configuration, which is a good reason to check your own settings rather than assume.
The passphrase is doing more work than people think
FDE’s cryptography is only as strong as the thing gating access to the key. A drive encrypted with AES and unlocked by a four-digit PIN or a password reused from a shopping site is not meaningfully harder to get into than an unencrypted one, once someone has enough attempts or enough patience against a weak entry point.
TPM-backed auto-unlock, where the machine decrypts itself on boot without asking you for anything because the hardware chip vouches for it, is convenient and fine for the “lost drive” threat model. But it means that anyone who gets the device itself, already logged into an active session or able to boot it, is functionally past encryption entirely. Pairing TPM unlock with a PIN or requiring a login password closes that gap, because now possession of the hardware alone isn’t sufficient.
What full disk encryption was never going to cover
It’s worth being specific about the boundary, because “I have encryption on” gets treated as a finished sentence when it’s really the start of one.
FDE doesn’t protect files once they leave the drive. A document encrypted on your disk is plaintext the moment you email it, upload it, or sync it to cloud storage, because at that point you’re looking at a copy sitting on someone else’s infrastructure under its own separate protections, or lack of them.
It doesn’t protect against malware that runs while you’re logged in, since malware operates inside the same unlocked session you do.
It doesn’t protect against someone who has your login credentials, whether they got them by guessing, by phishing, or because you told them.
It doesn’t protect a device shared between multiple logged-in users the same way separate accounts and permissions would.
And it says nothing about your other devices, your backups, or your browser history. Encryption is a property of one storage volume, not a property of you.
What’s actually worth doing
None of this means full disk encryption is a weak control, it’s a good one, and it’s worth having on every laptop and phone you own. The point is knowing exactly what it buys you so you don’t lean on it for problems it was never built to solve.
For most people the practical version of “use it well” is fairly short. Turn on FDE if it isn’t already on, most modern operating systems enable it by default or offer it as a single settings toggle. Use a real passphrase or a PIN rather than relying purely on biometric or TPM-only unlock if the device ever leaves your hands. Shut down rather than sleep when a device is traveling somewhere it could be lost or seized, since a powered-off drive forces a full key re-derivation instead of just a screen unlock. And treat encryption as one layer among several, alongside account security, software updates, and basic caution about what you install and click, rather than the single fact that makes a device “secure.”
Full disk encryption answers a specific question well: can someone read this drive if they get it while it’s off. It was never built to answer what happens once you’re logged in, and that’s a different set of habits entirely.
Want more explainers like this one that stay specific about what a tool actually does and doesn’t do? Check out the rest of the site here.