Encrypting pagefile.sys: the EncryptPagingFile setting and what it protects against

Windows ships a feature most defenders never enable: full encryption of pagefile.sys with a per-boot ephemeral key. It is a one-line fsutil flip. It costs almost nothing on hardware from the last decade. And it is the difference between a clean carve and a wall of high-entropy noise when an offline disk lands on my desk.

This post is the practitioner view: what it does, what it does not, how it stacks with BitLocker, and what to do about it when you find it set.

The setting

fsutil behavior set EncryptPagingFile 1

After a reboot, every page Windows writes to pagefile.sys is AES-encrypted. Specifically:

A 256-bit AES key is generated at boot, kept in non-paged kernel memory, and destroyed at shutdown.
The Memory Manager hands pages to NTFS with a per-write IV. NTFS encrypts inline before the bytes hit disk.
The key is never written anywhere. Not to the disk, not to the TPM, not to the LSA. It is not recoverable even by the user who turned the setting on.

Query the state:

fsutil behavior query EncryptPagingFile

0 is off (the default), 1 is on. The corresponding registry value, useful when you are reading an offline SYSTEM hive:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    EncryptPagingFile (REG_DWORD) = 1

The same machinery is governed via Group Policy at Computer Configuration → Administrative Templates → System → Filesystem → NTFS → Configure encryption for the page file.

What this protects against

The threat model is offline disk access after the system was running. Concretely:

A laptop is stolen while powered off. Disk image is taken. Without EncryptPagingFile, last-session pagefile contents are readable in cleartext. With it, they are AES output and the key is gone.
A server's internal disk is pulled during maintenance and imaged.
A VM snapshot is captured but the running RAM is not.

The constant: the system was running, then is off, and someone is reading the disk afterwards. The encryption protects the afterward read.

What it doesn't protect against

A live system being acquired. The ephemeral key is in RAM. A process with kernel access (or a WinPMem, DumpIt, Magnet RAM Capture run) can recover it and decrypt the file on the fly. Forensic acquisitions on a running host should capture RAM first, then pagefile.
hiberfil.sys. Hibernation dumps RAM to disk wholesale. The pagefile contents inside that snapshot were already encrypted-after-write, but the live application memory containing the keys and the plaintext was not. hiberfil.sys is therefore the bigger leak surface on a laptop that lid-closes constantly. Mitigation: BitLocker on the volume.
A crash dump (MEMORY.DMP). Same situation. The dump captures RAM, including the key.
A Linux dual-boot swap partition. EncryptPagingFile is NTFS-only.

The pattern: anything that captures RAM defeats it. Anything that captures only the disk after shutdown is defeated by it.

Interaction with BitLocker

BitLocker encrypts the whole volume, including pagefile.sys. So why both?

Scenario	BitLocker alone	+ EncryptPagingFile
Disk imaged after clean shutdown	Protected	Doubly protected
Disk imaged while system running	TPM-unsealed	Pagefile still safe
BitLocker recovery key compromised	Exposed	Pagefile still safe
`MEMORY.DMP` extracted from disk	TPM-unsealed	Same (dump is not pagefile)

EncryptPagingFile survives a BitLocker compromise because its key never touches disk. For security-sensitive systems, use both. The CPU overhead is negligible on any AES-NI capable hardware, which is everything since 2010.

Performance cost

Not measurable on hardware from the last decade. AES-NI has been standard since Westmere. The pagefile is not a hot-path workload on hosts with adequate RAM. If you are seeing meaningful slowdown, the underlying issue is that you are paging too aggressively, not the encryption. Add RAM.

What it means for forensic analysis

This is the part directly relevant to me.

If you receive an offline disk image with EncryptPagingFile = 1:

The pagefile is unrecoverable. Period. The key is gone. Signature carves return nothing. String dumps return nothing. The Page map shows almost every page in the high-entropy bucket. There is no recovery path.
Pivot to alternatives. RAM dump if there is one. hiberfil.sys (not pagefile-encrypted). MEMORY.DMP. The live lsass.exe if the host is still up. EDR telemetry. Network flow logs. AmCache, Prefetch, Shimcache, EVTX, SRUM for execution evidence. Browser history for URLs. LNK files and jump lists for user interaction. The recycle bin and USN journal for file lifecycle. The pagefile was one source. There are many.

If you have the live system, before powering it off:

Acquire RAM first. The pagefile key lives there.
Then acquire pagefile while the kernel is still up. Raw NTFS reads give you the decrypted view via the live filesystem driver. The bytes on disk are still ciphertext, but the read goes through the kernel which decrypts in flight.

If you are the one advising on hardening:

Recommend EncryptPagingFile = 1 for laptops and any host that might leave physical custody.
Combine with BitLocker for the volume.
Do not disable pagefile entirely. You lose crash dumps and the modified-page list optimisation. See should you delete pagefile.sys.

How to verify it is actually working

After the reboot, check entropy on a captured sample. From a forensic Linux boot:

ent pagefile.sys
Entropy = 7.99 bits per byte.

7.99/8 is essentially random. That is what AES output looks like. An unencrypted pagefile typically scores 6.5 to 7.5, dragged down by structured regions, zero-fill, and high-frequency ASCII strings.

Or run the universal sniff test:

strings -a pagefile.sys | head -50

With EncryptPagingFile = 1 you will see essentially no English strings. Without it you see URLs, registry paths, command lines, file paths in spades.

Why isn't it on by default

Microsoft's historical reasoning is a mix of crash-dump compatibility, kernel-debug usability, and "it requires a reboot". A pagefile encrypted with an ephemeral key complicates windbg, and MEMORY.DMP is written through the pagefile during BSOD time, which has had edge cases. For most enterprise endpoints none of those reasons outweigh the security benefit. Turn it on by GPO.