Your Notes Are Encrypted at Rest — Your Laptop Is Almost Never at Rest

Full-disk encryption protects your notes in exactly one of the three states your laptop occupies: powered off. While the machine is asleep, the encryption key is still in RAM. While it is unlocked and running, the guarantee does not apply at all. Here is the state table the setup guides never print.

You close the lid at a café, slide the laptop into your bag, and walk to the counter. The screen is dark. The drive is encrypted — BitLocker, FileVault, or LUKS, depending on your OS. Someone who grabbed the bag in that moment, you tell yourself, could not read your notes.

That is the right instinct. It is also, depending on one power setting you may never have seen, possibly wrong.

Full-disk encryption is one of the strongest privacy controls available to a laptop user. But "encrypted at rest" is a scope, not a badge. It describes a precise condition — the drive is locked — and that condition is not always satisfied when the lid is closed. The setup documentation for all three major platforms describes this limitation in plain language. Almost nobody reads it.

This post works through the three states your machine occupies, explains what the encryption guarantee covers in each, and gives the single free action on each platform that closes the gap. It does not argue that encryption is broken. It argues that the scope of the guarantee is narrower than most users assume — and narrowing that assumption is the whole protection.

What "encrypted at rest" actually promises

Full-disk encryption works by encrypting every sector of the drive with a key. Without that key, the drive's contents are indistinguishable from random noise. "Encrypted at rest" is the statement that the drive is in that locked state — the key is not loaded, and the ciphertext is all a reader can access.

The condition is real and valuable. A powered-off encrypted laptop, left on a train or seized at customs, yields nothing readable to a person who does not hold the key. That protection is documented, durable, and does not depend on any software running. MNMNOTE's companion post on which apps actually hold your keys covers the vendor layer of that question — whose server, whose key, which cipher.¹

What "encrypted at rest" does not say is that the drive is locked right now. It says the drive is locked when it is at rest. The question the setup guides skip is: when is a laptop actually at rest?

The answer is: when it is powered off, or hibernating with the drive locked. In every other state your machine spends its waking life — running, unlocked, or sleeping — the key is already loaded into RAM, and "encrypted at rest" is not the operative guarantee.

This is not a bug. It is an architectural requirement. An encrypted drive can only be read if the key is accessible. The OS loads the key into memory after you authenticate at boot, and keeps it there so that reads and writes can happen without you re-entering your passphrase on every keystroke. The encryption is doing its job. The scope is just not what the phrase sounds like.

The three states your machine lives in

Every laptop alternates among three modes. The encryption guarantee applies differently in each.

The row that surprises people is screen locked. Locking the screen sets an authentication barrier for the next user session. It does not lock the drive or evict the encryption key from memory. The key is still there. The drive is still mounted.²

The row that most people misconfigure is sleeping. Sleep, standby, and suspend — the states triggered by closing the lid or letting the machine idle — leave the running system in RAM with the power barely on. The drive is not locked. The key stays resident. This is the default on every major desktop OS.

Hibernation is the exception. When a machine hibernates, the OS writes the running state to disk, locks the drive, and powers off. On resume, you re-authenticate, the drive unlocks, and the state is restored. The encryption guarantee holds across a hibernate cycle.

The practical implication: your machine is "at rest" in the security sense only when it is off or hibernated. Every other state — including the state it is probably in right now, and in right now when you close the lid — keeps the key loaded.

Windows and BitLocker

Microsoft's documentation states the sleep/hibernate distinction with unusual directness. The BitLocker countermeasures page at learn.microsoft.com reads:³

"The Windows default power settings cause devices to enter sleep mode when idle. When a device transitions to sleep, running programs and documents are persisted in memory. When a device resumes from sleep, users aren't required to reauthenticate with a PIN or USB startup key to access encrypted data. This scenario might lead to conditions where data security is compromised. When a device hibernates, the drive is locked."

That last sentence is the key distinction. Sleep leaves the drive unlocked. Hibernate locks it.

The same page quotes when the key enters memory at all:³

"BitLocker accesses and stores the encryption keys in memory only after preboot authentication is completed."

This is the correct picture: at boot, you authenticate; the key loads; from that point forward it stays loaded until you power off or hibernate. Sleep does not interrupt that. The page's recommendation follows directly:³

"Therefore, organizations that use BitLocker might want to use Hibernate instead of Sleep for improved security."

The strong form of the recommendation goes further:³

"For scenarios requiring protection against these advanced attacks, configure a TPM+PIN protector, disable standby power management, and shut down or hibernate the device before it leaves the control of an authorized user."

The action on Windows: Change your power plan so the machine hibernates when you close the lid, rather than sleeping. In Settings → System → Power & Sleep → Additional power settings → Choose what closing the lid does, set "On battery" and "Plugged in" both to "Hibernate." Require authentication on resume.

One scope note from the same documentation: the sleep/authentication bypass concerns configurations that use TPM-only mode. A TPM+PIN configuration requires the PIN on resume from sleep as well. If you have already configured BitLocker with a PIN requirement, the resume-from-sleep gap may be narrowed on your machine — verify in your current power and BitLocker configuration.³

Linux and LUKS

The Linux Unified Key Setup (LUKS) situation is clarified best by the cryptsetup-luksSuspend man page — a subcommand whose entire purpose is to close exactly this gap.⁴

The luksSuspend command is described as follows:⁴

"Suspends an active device (all IO operations will block and accesses to the device will wait indefinitely) and wipes the encryption key from kernel memory."

The command exists because the key is otherwise resident. If luksSuspend is needed to remove the key, the key was there. Normal suspend on a LUKS volume does not run luksSuspend — it leaves the device active and the key in place. Running cryptsetup luksSuspend <device> before suspend, and cryptsetup luksResume <device> on wake, is the manual path to a key-clean suspend on Linux.⁴

The man page also states the scope of what luksSuspend does and does not cover:⁴

"While the luksSuspend operation wipes encryption keys from memory, it does not remove possible plaintext data in various caches or in-kernel metadata for mounted filesystems."

This is an honest and important caveat. Wiping the LUKS key prevents the drive from being read, but pages of plaintext that were loaded into the filesystem cache before the suspend are not wiped by luksSuspend. Powered-off is still cleaner than suspended-with-luksSuspend.

The action on Linux: Whether you use a hook that calls luksSuspend before suspend, or simply prefer to hibernate, the practical rule is the same as Windows: if you want the drive locked, lock the drive explicitly. A closed lid alone does not do it.

macOS and FileVault

Honest gap notice: Apple's Platform Security guide covers FileVault key handling across sleep, standby, and the destroyfvkeyonstandby PMset option. That documentation was not retrieved and verbatim-verified for this post — the source renders via JavaScript, and two fetch attempts during research returned navigation only, not body text. Filing an unverified claim about FileVault's sleep behavior would be a privacy mis-scope on the platform many readers use.

What can be said without filling the gap from memory: the same logic applies to any OS. If the volume is mounted and the key is in memory, sleep does not lock the drive. Apple does provide destroyfvkeyonstandby as a documented PMset option. Consult Apple's Platform Security guide directly — support.apple.com/guide/security/ — for current, primary-source information on FileVault key handling across power states, before assuming that closing the lid on a FileVault-encrypted Mac is equivalent to powering it off.

The physics — what DRAM retains after power is cut

The state table above describes what the OS does. There is a physical layer beneath it.

In 2008, J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten — researchers from Princeton University, the Electronic Frontier Foundation, and Wind River Systems — published "Lest We Remember: Cold Boot Attacks on Encryption Keys" at the 17th USENIX Security Symposium.⁵

Their finding on DRAM behavior:⁵

"Contrary to popular assumption, DRAMs used in most modern computers retain their contents for several seconds after power is lost, even at room temperature and even if removed from a motherboard."

The implication:⁵

"We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access."

Applied to a laptop in sleep mode:⁵

"They pose a particular threat to laptop users who rely on disk encryption products, since an adversary who steals a laptop while an encrypted disk is mounted could employ our attacks to access the contents, even if the computer is screen-locked or suspended."

The paper is also direct about how well the attack works:⁵

"Our results below suggest that disk encryption, while valuable, is not necessarily a sufficient defense. We find that a moderately skilled attacker can circumvent many widely used disk encryption products if a laptop is stolen while it is powered on or suspended."

Two important caveats. First, this research is from 2008. Modern hardware — DDR4 and DDR5 systems, platforms with firmware-level memory encryption, machines where the encryption key is TPM-bound rather than stored as a plaintext value in general RAM — has better properties than the hardware the paper characterized. The basic threat model it describes is documented as an ongoing concern by the vendors themselves, which is why they recommend hibernate over sleep.

Second, the paper's honest summary of mitigation:⁵

"Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them."

That line is still the accurate characterization. The remedy is not a cryptographic breakthrough. It is a power setting: prefer hibernate over sleep.

The honest limits — what no setting removes

Hibernate closes the sleep gap. Powering off closes the hibernate gap. But there are limits that neither action eliminates.

The first is the residual DRAM window. Even a powered-off machine retains some DRAM content for seconds — and longer if the chips are cooled. An attacker who can reach a machine within seconds of power-off, and cool the RAM before removal, extends that window. The paper characterizes this as a bound on what an operating system can promise — not as a realistic attack on most users.

The second is the unlocked-running state. When you are using your machine, the key is in memory, the drive is mounted, and the encryption is doing nothing to protect the plaintext from a process running as you. This is correct and expected — it is the whole point. At-rest encryption protects data from a reader who accesses the drive without your session — not from software running inside your session. The application-layer version of this threat — what an adversary can read if they control code running in your browser — is a different problem, covered in the companion post on AES-GCM key derivation and browser encryption.⁶

The third is that "local-first" describes where the data lives, not whether it is locked. A locally stored note has one at-rest protection path: the drive. That path works when the drive is locked.

The reframe that belongs here: at-rest encryption is one control over one state. It is a genuine and valuable control. The property your notes carry is not "always encrypted" — it is "encrypted when the drive is locked." MNMNOTE's post on encrypted journaling and format durability accepts this guarantee as settled and asks what survives alongside it over decades.⁷ The question this post answers is simpler: which state are you in right now?

Frequently Asked Questions

Is my laptop encrypted when the screen is locked? The screen lock requires authentication to resume, but does not lock the drive. The encryption key remains in kernel memory. Screen lock prevents casual access to your session — it does not change the state of the encrypted volume. The drive-level encryption guarantee applies when the drive is locked, which requires powering off or hibernating.

Does closing the lid lock the drive? Not by default. On Windows and most Linux desktop environments, closing the lid triggers sleep — a low-power state that preserves the running system in RAM. The drive stays mounted and the key stays resident. To change this, configure your power plan to hibernate on lid close rather than sleep.

What is the difference between sleep and hibernate? Sleep keeps the running state in RAM with minimal power — the key stays in memory and the drive stays mounted. Hibernate writes the running state to disk, locks the drive, and powers off fully. On resume from hibernate, the drive must be unlocked — which means re-authenticating. Microsoft's BitLocker documentation recommends hibernate over sleep for improved security.³

Does a TPM make sleep safe? A TPM-only BitLocker configuration still exposes the key in RAM during sleep, and resume does not require re-authentication — which is the documented gap. A TPM+PIN configuration requires the PIN on resume and closes that specific bypass. Check your BitLocker configuration to confirm which protector is active.

What is a cold-boot attack? A cold-boot attack exploits DRAM's physical inertia — memory contents persist briefly after power is cut. An attacker who accesses a recently powered-off or sleeping machine and reads the RAM within that window may recover encryption keys. The 2008 Halderman et al. USENIX paper demonstrated this on hardware of that era.⁵ Modern platforms have mitigations, but vendors still recommend powering off or hibernating rather than relying on sleep.

Does this affect note apps differently from other files? No. The state table applies to every file on the encrypted volume. Note apps are called out here because "are my notes private?" is a question note users ask, and the answer depends on the drive state — not the app. A local markdown file on an encrypted drive is as protected as any other file when the drive is locked, and equally unprotected when it is not.

How do I check whether my Linux machine runs luksSuspend on suspend? Check whether your init system or suspend hook calls cryptsetup luksSuspend before suspending. On systemd-based systems, look at your systemd-sleep hooks or the scripts in /usr/lib/systemd/system-sleep/. The luksSuspend man page describes the expected behavior.⁴

What about FileVault on macOS? Apple's Platform Security guide documents FileVault key handling across sleep and standby, including the destroyfvkeyonstandby PMset option. The FileVault sleep behavior was not verbatim-verified for this post — consult support.apple.com/guide/security/ directly for primary-source information on macOS key handling across power states.

The encryption label on your drive is accurate. The scope it covers is narrower than the phrase suggests — and that scope does not follow the lid when you close it. One power setting moves your machine into the state where the guarantee actually holds. The alternative is to trust a promise that the vendor's own documentation says is not being made.

Notes stored locally on your own device are only as private as the state the device is in. mnmnote.com keeps your notes on your device — what you do with the lid is still yours to decide.

References