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

Windows quietly ships with a feature that encrypts the contents of pagefile.sys with a per-boot ephemeral key. It's a one-line fsutil command, it costs almost nothing at runtime, and most defenders don't know it exists.

This post covers what it does, what it doesn't do, how it interacts with BitLocker, and — relevant for this site — how it affects forensic analysis of pagefile.

The setting

fsutil behavior set EncryptPagingFile 1

After a reboot, every write to pagefile.sys is encrypted. Specifically:

• A 256-bit AES key is generated at boot, stored in non-paged kernel memory, and destroyed at shutdown.
• The Memory Manager hands pages to NTFS with a per-write IV; NTFS AES-encrypts each page before it lands on disk.
• The key is never written to disk, never exported, and not recoverable — including by the user who set it.

Read it back:

fsutil behavior query EncryptPagingFile

0 means off, 1 means on. The default is 0 on most Windows builds.

What this protects against

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

• A laptop is stolen while powered off. Disk image is taken. Without EncryptPagingFile, the pagefile contents from the last session are readable in cleartext (modulo NTFS journaling normal behavior). With it, they're AES-encrypted with a key that no longer exists.
• An internal disk is removed from a server during maintenance and imaged.
• A VM snapshot is captured but the running RAM isn't.

Note the constant: the system was previously running, then is now off, and someone is reading the disk after the fact. The encryption protects against 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 (Wraith, DumpIt, WinPMem, or just an authorized kernel debugger) can recover the key and decrypt pagefile.sys on the fly.
• A hibernation file (hiberfil.sys). Hibernate writes RAM to disk; if EncryptPagingFile was on, the pagefile contents in RAM at hibernate time were already encrypted-after-write — but the live application memory was not. hiberfil.sys is therefore the bigger leak surface on a laptop that lid-closes (= hibernates) frequently. Mitigation: BitLocker, which encrypts the volume hiberfil.sys lives on.
• A crash dump (MEMORY.DMP). Same situation — RAM contents, not pagefile-encrypted.
• A swap partition on Linux dual-boot. EncryptPagingFile is a Windows NTFS feature only.

Interaction with BitLocker

BitLocker encrypts the whole volume, which includes pagefile.sys. You might therefore wonder why you'd want EncryptPagingFile on top. The reasoning:

The key insight: EncryptPagingFile survives a BitLocker compromise because its key never touches disk. For security-sensitive systems, use both. The runtime cost is negligible (NTFS does the AES inline on modern hardware that has AES-NI).

Performance cost

In practice, none worth measuring on hardware from the last 10 years. AES-NI is on every CPU since Westmere (2010). The pagefile is not a hot-path workload on systems with adequate RAM.

If you're seeing measurable performance loss, the actual problem is that you're paging too much, not the encryption — fix the RAM provisioning.

What it means for forensic analysis

This is the part directly relevant to this site.

If you're an analyst handed an offline disk image with EncryptPagingFile = 1 set:

• The pagefile is unrecoverable. The key is gone. The carving techniques this parser implements all fail — the bytes look like random high-entropy noise.
• You'll see high_entropy dominate the Page map tab. That's the signature of properly-encrypted pages.
• What to do instead: pivot to other sources — RAM dump if you have one, hiberfil.sys (which is not pagefile-encrypted), MEMORY.DMP, the live lsass.exe if the system is still up, EDR telemetry, network flow logs.

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

• Acquire RAM first. The pagefile key lives in there.
• Then acquire pagefile while the kernel is still up — you'll get the decrypted view via raw NTFS read.

If you're advising on hardening:

• Recommend EncryptPagingFile = 1 for laptops and any system that might leave physical custody.
• Combine with BitLocker.
• Don't disable pagefile entirely; you'll lose crash dumps and the modified-page-list optimisation. See should you delete pagefile.sys.

How to verify it's actually working

After setting and rebooting, you can confirm by looking at the file's content entropy. Use this parser on a small captured sample, or ent pagefile.sys from the command line:

ent pagefile.sys
Entropy = 7.99 bits per byte.

7.99 / 8 means essentially random — what you'd expect from AES output. A non-encrypted pagefile typically scores 6.5–7.5 thanks to its high proportion of structured (low-entropy) regions and zero-fill.

You can also boot from a forensic Linux USB and try to grep the file:

strings -a pagefile.sys | head

With EncryptPagingFile = 1, you'll see essentially no English strings. Without it, you'll see a flood — URLs, command lines, file paths, the works.

Why isn't it on by default?

Microsoft's answer is roughly "compatibility and crash-dump usability":

• A pagefile that's encrypted with an ephemeral key complicates kernel debugging.
• MEMORY.DMP is written through the pagefile during crash time, and there are edge cases historically where the dump writer had trouble with encrypted pagefile.
• The setting is per-machine and requires a reboot.

For most enterprise endpoints, none of these reasons outweigh the security benefit — turning it on via a GPO is a good idea.

Group Policy

The same setting is exposed via:

Computer Configuration → Administrative Templates → System → Filesystem → NTFS → "Configure encryption for the page file"

…or directly as the registry value:

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

Related

• Should you delete or disable pagefile.sys? — the alternative.
• Finding credentials in pagefile.sys — why you'd want to encrypt it.
• Limitations of pagefile.sys analysis — including what an encrypted pagefile looks like to a carver.