Beyond BitLocker: The Three File-Level Encryption Layers Microsoft Hides in Plain Sight

1. "BitLocker Is On"#

A Windows 11 laptop sits on a desk at the user's lock screen. TPM-only BitLocker, secure boot clean, automatic login disabled. The owner stepped away to take a call.

An attacker with physical access boots it normally. The TPM unseals the volume master key against PCR[7] and PCR[11]. Microsoft Learn states the Secure Boot anchor verbatim: "By default, BitLocker provides integrity protection for Secure Boot by utilizing the TPM PCR[7] measurement" ^[1]. PCR[11] is widely documented in TCG-aware BitLocker references as the boot-manager / BitLocker access-control measurement; the cited Wikipedia BitLocker article confirms TPM-PCR sealing in general terms ^[2]. The point that matters is that TPM-only BitLocker seals against a subset of platform-state PCRs, and the unseal happens automatically when the boot chain has not been tampered with. NTFS mounts. The login prompt appears. The attacker now stands in front of a fully decrypted volume without having authenticated as any user.

What is, and what is not, still protected at this exact instant?

The expected reaction is "the data on disk is plaintext to whoever can read the running kernel; isn't that the whole point of why people add a PIN to BitLocker?" That reaction is half right. The volume is plaintext, yes. But not every file on it is readable.

Files marked with the EFS attribute are still encrypted. Files inside a Personal Data Encryption (PDE) protected folder are still encrypted. A DOCX labelled "Confidential - All Employees" by a Purview sensitivity label is still encrypted. Three different cryptographic mechanisms, three different protection-key roots, three different reasons the attacker is staring at ciphertext while the volume is mounted.

This is the gap the rest of the article walks. It is the gap most security architects know exists in the abstract -- "BitLocker is on" does not mean "every file is locked" -- and which most do not know is closed by three structurally distinct technologies that have been hiding in plain sight since 2000.

Three layers, three reasons, three different roots, three different attack surfaces. That is the article.

sequenceDiagram
participant Hardware as TPM and PCRs
participant Boot as Boot Manager
participant OS as Windows Kernel
participant User as Human at Keyboard
Hardware->>Boot: PCR[7], PCR[11] match
Boot->>OS: VMK released, NTFS mounts
OS->>OS: Volume now plaintext to kernel
OS->>User: Lock screen presented
Note over OS,User: Attacker stands here, with a plaintext volume and no authenticated user
User-->>OS: Hello PIN or biometric (eventually)
OS->>OS: Per-user secrets unseal

2. Historical Origins: Windows 2000 and the Birth of EFS#

It is 1999. Laptops are appearing on every executive's desk. Theft is rising. The only protection NTFS offers against an attacker who walks off with a machine is the access control list, and the ACL is checked by the kernel of the operating system that mounted the disk. Boot a different operating system off floppy or CD, mount the NTFS volume as a foreign filesystem, and the ACL is just metadata to be ignored. The cryptographic protection of the data is exactly nothing.

Microsoft's NTFS team responded by adding the first cryptographic primitive to the filesystem itself. Windows 2000 reached general availability on February 17, 2000 (after a December 15, 1999 release-to-manufacturing milestone) and shipped the Encrypting File System -- EFS ^[3]. The mechanism is documented in the 1999 Microsoft technical paper Encrypting File System for Windows 2000 ^[4]. The original Microsoft Research URL for this paper now returns HTTP 404. A binary PDF mirror is preserved at cypherspace.org, but the PDF is image-streamed and the body text is not retrievable for direct quotation. The Microsoft author list could not be verified against the primary text, so this article cites the paper anonymously. The Microsoft Learn EFS Win32 reference, still on the docs site today, states the design plainly: "The Encrypted File System (EFS) provides an additional level of security for files and directories. It provides cryptographic protection of individual files on NTFS file system volumes using a public-key system" ^[5].

That sentence carries three design choices the rest of EFS hangs from. File-level, not volume-level. NTFS attribute, not separate database. Public-key system, not symmetric password. Each of those choices was deliberate. Each fixes a problem the architects of NTFS in 1999 actively worried about.

The file-level choice answered the "what if BitLocker is on" question seventeen years before BitLocker existed. NTFS already protected files at the access-control layer; what the team wanted was a way to make a particular file unreadable to a different user account on the same machine, not just to a foreign operating system. Volume encryption could not do that. The volume is one thing; users are many. So encryption belonged on the file.

The NTFS-attribute choice answered the integration question. EFS encryption lives in a named stream attached to the file, $EFS. The Windows API surface stays the same: CreateFile, ReadFile, WriteFile, CopyFile all work transparently against an encrypted file when called by an authorised user. Microsoft Learn is explicit about how the integration works: "When the source file is encrypted, CopyFile and CopyFileEx rely on the EFS service (hosted in lsass.exe) to create the target file and apply keys used in encryption of the source file" ^[5]. Encryption was made invisible to existing applications. That was the only way a 1999 enterprise was going to deploy it.

The public-key choice answered the recovery question. Public-key crypto lets the file have multiple wrappers around the same symmetric content key -- one for the user, one or more for designated recovery agents. An organisation that lost the user's private key (employee leaves, password forgotten, hard drive moved to a different machine) could still recover the file using a recovery agent the IT team controlled. The first Microsoft response to "what happens when a user forgets their password?" was Group-Policy-enforced Data Recovery Agents (DRAs) ^[6]. In Windows 2000, the default DRA was the local Administrator account. From day one, EFS encryption was meant to be reversible by someone other than the file owner.

EFS is on the disk now. So what does the encrypted file actually look like? What does NTFS store, and where does the key live?

3. How EFS Works -- And Why It Was Always Per-User#

The EFS key chain is the most important diagram in this article. Read it once carefully; every limitation of EFS that practitioners hit in production drops mechanically out of these arrows.

flowchart TD
Plain[Plaintext file] -->|AES with FEK| Cipher[Ciphertext on NTFS]
FEK[Per-file FEK, symmetric] -->|RSA-wrap| W1[Wrapper for user public key]
FEK -->|RSA-wrap| W2[Wrapper for DRA public key]
W1 --> EFSAttr[EFS named stream on the file]
W2 --> EFSAttr
UserPriv[User EFS RSA private key] -->|stored in| Profile[APPDATA Microsoft Crypto RSA SID directory]
Profile -->|sealed by| ClassicDPAPI[classic DPAPI master key]
ClassicDPAPI -->|derived from| Logon[User logon secret, NTLM hash plus salt]

The chain has four layers. The bottom layer is the file contents themselves, encrypted with a freshly generated symmetric key called the File Encryption Key.

The FEK is symmetric for performance: AES on the file body, not RSA. The Wikipedia EFS article notes that "the FEK (the symmetric key that is used to encrypt the file) is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted FEK is stored in the $EFS alternative data stream of the encrypted file" ^[6]. The same paragraph adds the second wrapper, the one without which enterprise EFS deployments would not work.

The cipher inside the FEK has not been static. EFS shipped with one default cipher in Windows 2000 and has moved several times since; the precise Windows 2000 default is disputed across secondary sources. Rather than commit to a version we cannot verify, this article notes that the FEK cipher has changed across releases. AES has been the default since Windows XP SP1 ^[6]; a later Windows 10 release moved the default key size from AES-128 to AES-256. Microsoft Group Policy / FIPS-compliance guidance documents the AES-128 to AES-256 default-key-size change at Windows 10 1709, but the cited Wikipedia EFS article's algorithm table lists only "AES" without a specific key size, so this article hedges on the exact version while keeping the AES-since-XP-SP1 anchor verbatim from Wikipedia.

Now look at the top of the chain. The user's EFS RSA private key sits in the user's roaming profile, in the path %APPDATA%\Microsoft\Crypto\RSA\<SID>\. This same directory is where cipher.exe /R writes self-signed DRA certificates and where cipher.exe /K writes the user's own EFS keypair if one does not yet exist. Operational confusion lives here, because the same directory holds both per-user EFS keypairs and any recovery-agent certificates the user has imported. The private key is not stored in the clear. It is sealed by classic Data Protection API (DPAPI), Microsoft's per-user key-derivation system that wraps user-scoped secrets with a master key derived from the user's logon credential.

Wikipedia's EFS article states the consequence in one terse sentence: "In Windows 2000, XP or later, the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name ... any compromise of the user's password automatically leads to access to that data" ^[6]. The cryptographic identity of the file's owner is the user's logon credential, by construction.

That is the design. Now mechanically derive the consequences.

Per-user, not per-process#

The unwrapping principal of the EFS chain is the user SID. There is no place in the chain where an application identity could insert itself as a separate consumer. If you log on as Alice, every process running as Alice can ask the EFS service in lsass.exe to unwrap any file Alice owns. The EFS service is a single user-mode endpoint; it does not gate on the calling process.

Contrast this with Credential Guard and the LSAIso enclave, which deliberately move secret material into a Virtualization-Based Security enclave that even a kernel-mode caller in the host VTL cannot read. EFS is per-user; LSAIso is per-process-with-attestation. Different threat models, different mechanics. Credential Guard's LSAIso isolation is the kernel-mode equivalent of "the application sees plaintext only if the application is the right application." EFS predates this design vocabulary by a decade and a half; its arrows simply do not include an application-identity step.

Password reset destroys access#

If the only thing protecting the user's EFS RSA private key is classic DPAPI keyed off the user's password, then anything that breaks the user-password-to-master-key derivation also breaks the user's access to every EFS-encrypted file they own. Resetting a user's password from a domain administrator account does exactly this. Wikipedia warns in plain terms: "any compromise of the user's password automatically leads to access to that data" ^[6] -- which is the same statement read the other way. Lose the password, lose the data. The DRA exists precisely so that the organisation still has access; the user, however, is locked out.

Decryption on cross-volume or cross-protocol copy#

EFS is bound to NTFS. When a file is copied to a different filesystem -- FAT32, exFAT, or pre-24H2 ReFS -- the destination cannot store the $EFS stream, and the file is decrypted in transit. Wikipedia again: "Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32. Finally, when encrypted files are copied over the network using the SMB/CIFS protocol, the files are decrypted before they are sent over the network" ^[6].

This is not an EFS bug; it is what falls out when the encryption is implemented as a filesystem attribute and the destination filesystem has no equivalent. The cryptography ends where the attribute ends.

Opt-in, per file#

EFS is enabled by setting the encrypt-attribute on a file or folder via right-click Properties > Advanced > Encrypt contents to secure data, or via cipher.exe /e. The user has to remember to do it. The volume default is unprotected. That is the entire mechanism: there is no "encrypt every file Alice creates in her profile" policy in classic EFS. PDE, twenty-two years later, finally addresses this.

Mutually exclusive with PDE#

Microsoft Learn states the mutual exclusion plainly: "No, Personal Data Encryption and EFS are mutually exclusive" ^[8]. A file cannot have both an EFS wrapper and a PDE wrapper at the same time. We will see why in §5; for now, register that the two layers compete at this layer of the stack, not compose.

Every limitation of EFS drops mechanically out of one design decision: the protection root is the user's logon secret. EFS is per-user because the cryptographic identity is the user. To close the gaps EFS leaves, you cannot keep using the user's logon secret as the root. You need a different root.

// Illustrative only. Real EFS uses CNG primitives inside the EFS service in lsass.exe.
// Do not run this against real keys or files.

function encryptFileWithEFS(plaintext, userPublicKey, draPublicKeys) {
// 1. Generate a per-file symmetric File Encryption Key (FEK).
const fek = randomBytes(32); // AES-256 since Windows 10 1709

// 2. Encrypt the file body with the FEK.
const ciphertext = aesEncrypt(plaintext, fek);

// 3. RSA-wrap the FEK to every authorised principal.
const wrappers = [];
wrappers.push({ sid: 'user-sid', wrappedFek: rsaWrap(fek, userPublicKey) });
for (const dra of draPublicKeys) {
  wrappers.push({ sid: dra.sid, wrappedFek: rsaWrap(fek, dra.publicKey) });
}

// 4. Store wrappers in the file's $EFS attribute. Body is on disk.
return { body: ciphertext, efsAttribute: wrappers };
}

// Decryption is the reverse: locate the wrapper for the calling user's SID,
// unwrap the FEK with the user's EFS private key (loaded from
// %APPDATA%\Microsoft\Crypto\RSA\<SID>\ and unsealed by classic DPAPI from
// the user's logon secret), then AES-decrypt the body.
console.log('EFS encryption shape: one FEK, multiple RSA wrappers');

EFS is per-user because the cryptographic identity is the user. To close the gaps EFS leaves, you have to change the root. That is what the next twenty-six years of Windows file-data protection do, one root at a time.

4. Six Generations of Closing Each Other's Gaps#

Each generation of Windows file-data protection is engineered to close a gap left by the previous one, and each new layer introduces a different protection-key root because each gap has a different threat model. Here is the twenty-six-year sequence.

timeline
title Windows file-data protection generations
2000 : EFS ships with Windows 2000
: Per-user per-file, RSA wrap, classic DPAPI root
2003 : RMS ships with Windows Server 2003
: Per-content envelope, identity service authorization
2006 : BitLocker ships with Windows Vista
: Volume-level, TPM-sealed VMK
2013-2014 : Azure RMS reaches general availability
: Tenant key in Azure, cross-organisation default
2018-2019 : Microsoft Information Protection unifies labels
: Same RMS engine, single labelling plane
2022 : Microsoft Purview brand consolidation
: MIP becomes Microsoft Purview Information Protection
2022 : Personal Data Encryption ships in 22H2
: Hello-bound DEK via DPAPI-NG
2022 : Windows Information Protection sunsets
: "Honest employees" tool retired
2024 : PDE for known folders ships in 24H2
: Desktop, Documents, Pictures auto-encrypted

Each year row in this diagram is anchored to a primary source cited inline in the corresponding generation section below: the Windows 2000 EFS milestone ^[3], the Windows Server 2003 RMS debut and lineage ^[9], the November 30, 2006 BitLocker release ^[2], the Azure Rights Management general-availability lineage ^[10], the Microsoft Information Protection brand and its April 2022 consolidation into Microsoft Purview ^[11], the Windows 11 22H2 / 24H2 Personal Data Encryption rollout ^[12], and the Windows Information Protection sunset ^[13]. Mermaid syntax does not accept pandoc inline citations inside the diagram body, so the citations live in the prose immediately after.

Generation 1 -- EFS (2000)#

Covered in §2 and §3. One paragraph recap: per-user, per-file, opt-in, RSA-wrapped FEK, user EFS RSA private key sealed by classic DPAPI from the user's logon secret. Root: the user's password. Threat model: a different user on the same machine, or a foreign operating system that mounts NTFS without honouring ACLs.

Generation 2 -- BitLocker (2006)#

Six years after EFS, Microsoft moved encryption off the file and down to the volume. BitLocker shipped with Windows Vista on November 30, 2006 ^[2]; the consumer launch of Vista that included it followed on January 30, 2007 ^[2]. The cipher in the first BitLocker release was AES-CBC with Niels Ferguson's Elephant Diffuser, a manipulation-resistance construction documented in the 2006 Microsoft technical paper AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista ^[14]. Niels Ferguson is the named cryptographer behind BitLocker's original cipher mode. He is the only individual this article names with primary-source confidence. Most other work in this space ships team-attributed.

Later releases moved to XTS-AES with 128-bit or 256-bit keys; XTS-AES has been the default since a Windows 10 release in the mid-2010s ^[2].

The cipher mode is not the point. The point is what changed in the root. BitLocker's Volume Master Key (VMK) is sealed in the TPM against a set of Platform Configuration Registers, and released automatically when the registers match the expected boot state.

The human is removed from the encrypt-this-file decision. There is no per-file opt-in; the volume protects everything, including system files, swap, and hibernation. There is no per-user wrapping; the VMK is one thing, the volume is one thing.

This is why BitLocker does not subsume EFS. The two layers protect different things. BitLocker protects the volume at rest, before the OS boots; EFS protects per-file per-user after the OS has mounted the volume and a particular user has logged on. The "BitLocker is on" vignette in §1 is exactly the gap BitLocker structurally cannot close: BitLocker is unlocked the moment the TPM unseals, and the unseal happens before any human authenticates.

Generation 3 -- RMS and Azure RMS (2003, 2013-2014)#

Three years after EFS, Microsoft shipped a completely different shape of file encryption with Windows Server 2003: Rights Management Services. Wikipedia traces the lineage: "Active Directory Rights Management Services (AD RMS, known as Rights Management Services or RMS before Windows Server 2008) is a server software for information rights management shipped with Windows Server" and "RMS debuted in Windows Server 2003, with client API libraries made available for Windows 2000 and later" ^[9].

RMS solved a different problem from EFS or BitLocker. The question was: can a document remain encrypted when emailed outside the organisation, or copied to a USB stick, or stored in a shared folder a different user has read access to? EFS could not -- decrypted on cross-protocol copy. BitLocker could not -- the volume is unlocked. RMS introduced a different shape: each protected document carries an envelope that includes a wrapped Content Encryption Key and a policy reference, and decryption requires the consumer to obtain a use license from the RMS service against an authenticated identity.

A few years after AD RMS shipped, Microsoft moved the RMS engine to the cloud as Azure RMS. The protection topology stayed the same: per-content CEK, tenant root key, use-license issuance against an identity service. What changed is that the identity service is now Microsoft Entra ID and the root key sits in Azure (or, with Bring Your Own Key, in an Azure Key Vault customer hold) instead of on a Windows Server. Microsoft Learn defines Azure RMS as "the main cloud-based encryption service from Microsoft Purview Information Protection" and notes that "Encryption settings remain with your data, even when it leaves your organization's boundaries" ^[10].

This is the "travels with the file" generation. Email a CEK-wrapped DOCX to an external recipient; the recipient still needs a use license from Azure RMS; the document does not become plaintext just because it changed hands.

Generation 4 -- MIP, then Microsoft Purview Information Protection (late 2010s, 2022)#

The late-2010s reorganisation is fundamentally a policy-plane unification, not a new engine. Azure Information Protection's classification and labelling, the Office unified labelling client, and a growing set of policy controls were brought together under the Microsoft Information Protection (MIP) name in the late 2010s. The encryption engine underneath stayed Azure RMS.

In April 2022, the entire compliance, classification, and information-protection portfolio got a single brand: Microsoft Purview. The April 19, 2022 launch blog post explained the consolidation: "To meet the challenges of today's decentralized, data-rich workplace, we're introducing Microsoft Purview ... that help you govern, protect, and manage your entire data estate" ^[11]. The same post's product-naming table mapped "Microsoft Information Protection" to "Microsoft Purview Information Protection" directly. Same engine. Same envelope shape. New name.

For the practitioner, this matters less than it looks. The on-disk artifact of a Purview-labelled document is the same CEK-wrapped envelope it was under MIP, AIP, and AD RMS. The label is metadata; whether the label applies encryption depends on the label's settings. Microsoft Learn states the engine plainly: "Unless you're using S/MIME for Outlook, encryption that's applied by sensitivity labels to documents, emails, and meeting invites all use the Azure Rights Management service from Microsoft Purview Information Protection" ^[16].

Generation 5 -- PDE (December 2022)#

December 8, 2022. Microsoft announced Personal Data Encryption in a Tech Community post with a title that telegraphs the threat model: Introducing Personal Data Encryption, securing user data before login and under lock ^[17]. The verbatim contrast with BitLocker, from the same post, is the cleanest statement of the gap PDE closes:

"Bitlocker provides full volume encryption and Bitlocker protected data is available when the device boots up, whereas PDE protected data is available only after the user authenticates to Windows Hello for Business at login or to unlock the screen."

That sentence carries the entire design. BitLocker unlocks at boot. PDE unlocks at Hello sign-in. The post-boot pre-logon window the §1 vignette dwelled in is exactly the window PDE was built to close. PDE shipped with Windows 11 22H2 ^[12]. The cipher is AES-CBC with a 256-bit key ^[12]. The protector binds to a Windows Hello for Business credential, not to a password.

The PDE FAQ adds the second key constraint: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" ^[8]. Password sign-in does not unlock PDE content. RDP does not unlock it. Other users on the same machine do not unlock it. We will walk the full mechanism in §5 and §6; for now, register that the root is Windows Hello for Business, not the user's password.

Generation 6 -- PDE for Known Folders (Windows 11 24H2)#

The 22H2 release of PDE was API-only ^[17]. Applications could call Windows.Security.DataProtection.UserDataProtectionManager.ProtectStorageItemAsync to wrap an individual file, but Windows itself did not encrypt anything by default. That changed with Windows 11 24H2.

Microsoft Learn describes the 24H2 addition: "Starting in Windows 11, version 24H2, Personal Data Encryption is further enhanced with Personal Data Encryption for known folders. Once enabled, the Windows folders Desktop, Documents, and Pictures, along with their contents, are automatically encrypted" ^[12]. The CSP node tree (configured via Intune or any MDM that speaks ./User/Vendor/MSFT/PDE) gained ProtectFolders/ProtectDesktop, ProtectFolders/ProtectDocuments, and ProtectFolders/ProtectPictures for this purpose ^[18]. The PDE CSP itself was added in 22H2 (build 10.0.22621), while the known-folder nodes are gated to 24H2 (build 10.0.26100) and later ^[18].

For the first time since EFS, Windows shipped a per-user file-encryption mechanism that did not require the user to opt every individual file in. The default for the three best-known per-user folders -- if the administrator enables it -- is encrypted.

The dead-end branch -- Windows Information Protection (2016 to mid-2022)#

One more entry belongs on the timeline. Windows Information Protection, originally Enterprise Data Protection, was Microsoft's mid-2010s attempt at "container-style" data separation: corporate files in a container, personal files outside the container, copy-paste between them gated by policy. Microsoft Learn's /previous-versions/ landing page for WIP states the design intent: "Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience" ^[13].

The same page is candid about the limit: "While Windows Information Protection can stop accidental data leaks from honest employees, it is not intended to stop malicious insiders from removing enterprise data" ^[13]. WIP was sunset in mid-2022 and the recommended replacement was the Microsoft Purview Information Protection plus Microsoft Purview Data Loss Prevention combination ^[13].

Each generation chose a different protection-key root. That is the most important observation in the article -- and it has been hiding in plain sight since 2003.

5. Three Layers, Three Roots, Three Threat Models#

BitLocker, EFS, PDE, and Purview sensitivity labels use four different protection-key roots because each one closes a different gap, and each gap has a different threat model. That is by design.

The four roots:

Let us walk each root one at a time. The story changes at every row.

flowchart LR
subgraph BitLocker
BL_VMK[VMK] --> BL_TPM[TPM, sealed against PCRs]
end
subgraph EFS
EFS_FEK[Per-file FEK] --> EFS_Priv[User EFS RSA private key]
EFS_Priv --> EFS_DPAPI[classic DPAPI master key]
EFS_DPAPI --> EFS_Logon[User logon secret]
end
subgraph PDE
PDE_DEK[Per-file DEK] --> PDE_DPAPING[DPAPI-NG protector]
PDE_DPAPING --> PDE_Hello[Windows Hello for Business credential]
end
subgraph Purview
P_CEK[Per-content CEK] --> P_Tenant[Tenant root key]
P_Tenant --> P_KV[Azure Key Vault, BYOK or DKE]
P_License[Use license] --> P_Entra[Microsoft Entra ID authorization]
end

Root 1 -- BitLocker, the TPM-sealed VMK#

BitLocker terminates at the TPM. The VMK wraps the Full Volume Encryption Key; the TPM seals the VMK against the platform's PCR measurements; if the boot chain has not been tampered with, the TPM releases the VMK without any human input. That is the entire mechanism, and it is exactly why "BitLocker is on" leaves the gap the §1 vignette walks through. The threat BitLocker addresses is the powered-off device on a thief's workbench. It is mute against everything that happens after the OS has booted.

Root 2 -- EFS, the user EFS RSA private key sealed by classic DPAPI#

EFS terminates at the user's logon credential. Microsoft Learn defines the EFS service surface as a public-key system for individual files ^[5]. Wikipedia walks the chain end to end: per-file FEK, RSA-wrapped to the user's EFS public key, private key sealed by classic DPAPI from the user's logon secret ^[6].

The threat EFS addresses is a different user on the same machine, after both have signed on at one point or another. It is mute against three other things: the user's own ransomware (which runs as the user and can decrypt every EFS file the user owns), password reset (which destroys the DPAPI derivation and locks the user out unless a DRA is configured), and cross-protocol copy (decrypted before SMB transit).

Root 3 -- PDE, a DPAPI-NG protector bound to a Windows Hello credential#

PDE terminates at Windows Hello for Business. Microsoft Learn states the binding directly: "Personal Data Encryption is a security feature that provides file-based data encryption capabilities to Windows. It utilizes Windows Hello for Business to link data encryption keys with user credentials" ^[12]. The PDE FAQ confirms the unlock condition: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" ^[8].

The likely engineering mechanism is a DPAPI-NG protection descriptor. DPAPI-NG (Microsoft's "Next Generation" Data Protection API, in Windows 8 and later) is the only Windows API surface that publicly documents Hello-bound key release. Its protection-descriptor grammar accepts a small set of principal types, documented at Microsoft Learn: SID=, SDDL=, LOCAL=user, LOCAL=machine, WEBCREDENTIALS=, CERTIFICATE=HashID:sha1_hash_of_certificate, and CERTIFICATE=CertBlob:base64String ^[19]. Microsoft's own protection-descriptor reference adds: "The protection descriptor you specify automatically determines which key protection provider is used" ^[19].

Microsoft has not published a mechanism document that says, in those words, "PDE uses NCryptProtectSecret with a protection descriptor naming the Windows Hello for Business credential." What Microsoft has published is the binding ("it utilizes Windows Hello for Business to link data encryption keys with user credentials") and the API surface ("DPAPI-NG, with Hello-aware protectors"). The two compose in exactly one way that fits the verified primaries. Treat the protection-descriptor binding as the likely engineering mechanism rather than the directly-stated one. The DPAPI-NG protection-descriptor grammar is broader than just Hello. The same API surface backs WinRT user-profile secrets, web-credentials-vault items, and certificate-protected blobs. PDE is one consumer; the API itself is general.

flowchart TD
Plain[Plaintext file] -->|AES-CBC 256-bit| Cipher[Ciphertext on NTFS]
DEK[Per-file Data Encryption Key] -->|wrap| DPAPING[DPAPI-NG NCryptProtectSecret]
DPAPING -->|protection descriptor| Desc["Hello-bound principal, likely SID or LOCAL=user"]
Desc --> HelloKey[Hello-bound asymmetric key in TPM]
HelloKey -->|released by| Auth[Windows Hello PIN or biometric sign-in]

The arrows above are the cleanest single-page summary of PDE. From Microsoft Learn: the file body uses "AES-CBC with a 256-bit key" ^[12]. From the PDE FAQ: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" ^[8]. From the DPAPI-NG reference: the API surface includes NCryptCreateProtectionDescriptor, NCryptProtectSecret, and NCryptUnprotectSecret for exactly this purpose ^[7]. From the protection-descriptor reference: the rule grammar accepts principal types that include SID and LOCAL principals, which is where the Hello-bound binding lives ^[19].

The threat PDE addresses is the laptop at the lock screen with a plaintext volume, in the user's own absence. PDE files are unreadable until the user re-authenticates to Hello, even though BitLocker has long since released the volume.

This is, importantly, the only place in the four-layer story where "DPAPI-NG is involved" is true. EFS uses classic DPAPI, not DPAPI-NG. Purview labels use Azure RMS, not DPAPI-NG. BitLocker uses neither. The folk-knowledge framing "DPAPI-NG under everything" collapses three different roots into one and obscures the actual architecture.

Root 4 -- Purview labels, the Azure RMS tenant key plus Entra ID authorization#

Purview sensitivity labels (where the label applies encryption) terminate at the Azure Rights Management tenant key and at Microsoft Entra ID. Microsoft Learn states the engine: "Unless you're using S/MIME for Outlook, encryption that's applied by sensitivity labels to documents, emails, and meeting invites all use the Azure Rights Management service from Microsoft Purview Information Protection" ^[16].

The on-disk envelope contains the wrapped CEK and policy metadata, and the wrapped CEK can be re-issued to any authorised principal. When Bob in Contoso emails an "Internal" labelled DOCX to Alice in Fabrikam, Azure RMS issues Alice a use license against her Entra ID identity, provided that the document's policy admits her. The cross-organisation default is on by default ^[10].

The tenant root can vary. Microsoft Learn describes the topology: "The root key for your Azure Rights Management service can either be: Generated by Microsoft ... Generated by customers with Bring Your Own Key (BYOK)" ^[15]. Above BYOK sits Double Key Encryption, which puts a customer-controlled key in series with the Azure-held key.

The threat Purview labels address is the file that leaves the organisation. A Purview-encrypted file emailed to a personal Gmail account, copied to a USB stick, uploaded to a third-party SaaS -- still encrypted, still requires a use license from Azure RMS against an authenticated identity, still subject to the policy the original author attached. BitLocker, EFS, and PDE all stop at the local volume or local user; Purview labels are the only one of the four that follows the file across machines, tenants, and protocols.

The asymmetry is the design#

A single unifying root would have collapsed real distinctions. If everything terminated at the TPM, no protection could survive the file leaving the device. If everything terminated at the user's password, no per-content cross-tenant story would be possible. If everything terminated at Entra ID, the offline laptop at a lock screen would have no answer when the network is unreachable. The four-root architecture is what it is because the four threats are what they are.

Three layers, three protection-key roots, three threat models. The asymmetry is the point: each root exists precisely because the threats are different. A single unified root would not be an improvement -- it would collapse real distinctions.

Now that you know the roots, you can ask the right questions about the state of the art: what does each layer ship today, and how do you compose them?

6. State of the Art: Each Layer in 2026#

Each layer ships today, supported, documented, and deployed. Here is what each one actually looks like as of mid-2026.

EFS in 2026#

EFS still ships in Windows 11 and Windows Server 2025. It is documented at the Win32 file-encryption reference ^[5]. It is deprecated for new development -- the recommended replacement for new per-file scenarios on Entra-joined Hello-using devices is PDE ^[8] -- but the implementation is intact, Group Policy still ships DRA configuration, and existing EFS-encrypted files continue to work.

What EFS does not work on:

• ReFS before 24H2. Historically the $EFS attribute had no home on ReFS, so EFS-protected files were decrypted in transit when copied to a ReFS volume. Windows 11 24H2 and Windows Server 2025 added file-system-encryption support to ReFS ^[6], so the absolute "no home" framing is now out of date; on older ReFS, the cryptography still ends at the volume boundary.
• FAT32 / exFAT on legacy Windows. Wikipedia notes that "Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32" ^[6]. Windows 10 1607 and Windows Server 2016 added EFS support on FAT and exFAT ^[6], which softens the absolute version of that statement; the cryptography still ends at SMB transit and at any destination the source EFS service does not recognise as compatible.
• System files and root directories. Not encryptable; the chicken-and-egg problem of needing to read the user's profile before the user has authenticated.
• Compressed files. EFS and NTFS file compression are mutually exclusive on the same file.

The default cipher inside the FEK has been AES since Windows XP SP1 ^[6]; the default key size moved from AES-128 to AES-256 in a later Windows 10 release. Operationally, the most common source of confusion is cipher.exe /K, which generates a fresh self-signed EFS certificate for the current user if one does not already exist; the certificate goes into the user's personal store, the private key into %APPDATA%\Microsoft\Crypto\RSA\<SID>\, and the EFS service in lsass.exe from then on prefers the new certificate for new wraps. Existing EFS files do not rewrap themselves.

The DRA story works cleanly only in classic AD-domain deployments where Group Policy can push a recovery-agent certificate to every machine and the EFS service knows to add the DRA wrapper at encryption time. In an Entra-joined-only environment, the AD-domain DRA story does not transplant cleanly; this is one of the seven live operational problems we will catalogue in §9.

PDE in 2026#

Personal Data Encryption ships on Windows 11 22H2 and later, in Enterprise and Education SKUs ^[12]. As of Windows 11 24H2, the known-folder auto-encryption mode brings Desktop, Documents, and Pictures under PDE without requiring per-file API calls ^[12].

The prerequisites are strict, and they are spelled out on the PDE overview page: "The devices must be Microsoft Entra joined or Microsoft Entra hybrid joined. Domain-joined devices aren't supported" and "Automatic Restart Sign On (ARSO) must be disabled" ^[12]. The configure page emphasises the ARSO point: "Winlogon automatic restart sign-on (ARSO) isn't supported for use with Personal Data Encryption. To use Personal Data Encryption, ARSO must be disabled" ^[21].

PDE has two protection levels, defined by how long after sign-in the content remains decrypted in memory. The original announcement explains both:

"Level 1(L1) security protects contents during the early boot stage -- from the time that the machines boots, until the user logs in using Windows Hello for Business credentials. Level 2(L2) security protects data from the time the user's device locks till the device is unlocked using Windows Hello for Business credentials." ^[17]

L1 is "protected from boot until first sign-in." L2 is "protected from lock until next unlock." L1 is the default; L2 is opt-in and stricter, because re-decrypting on every unlock is more disruptive to apps that hold open file handles.

The Configuration Service Provider node tree:

• ./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption -- introduced in 22H2, build 10.0.22621 ^[18].
• ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDesktop -- introduced in 24H2, build 10.0.26100 ^[18].
• ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDocuments -- 24H2 ^[18].
• ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectPictures -- 24H2 ^[18].

For per-file application use, the WinRT API is Windows.Security.DataProtection.UserDataProtectionManager.ProtectStorageItemAsync ^[22]. The class provides static methods to obtain an instance for the current or a provided user, and instance methods that include GetStorageItemProtectionInfoAsync, ProtectBufferAsync, ProtectStorageItemAsync, TryGetDefault, TryGetForUser, and UnprotectBufferAsync, along with the DataAvailabilityStateChanged event ^[22]. ※ The UserDataProtectionManager API was introduced in Windows 10 1903 (build 10.0.18362), under Windows.Foundation.UniversalApiContract v8.0 -- predating the 22H2 ship of PDE itself by three years.

The gotchas list is long enough that the PDE FAQ enumerates each one:

• Password sign-in fails. Hello-only release; a user who signs in with a password (e.g., via Ctrl-Alt-Del fallback after a Hello failure) cannot read PDE content.
• RDP fails. Microsoft Learn states it explicitly: "No, it's not supported to access protected content over RDP" ^[8].
• Other-user fails. Each user's PDE content is bound to their own Hello credential.
• Mutually exclusive with EFS. PDE and EFS are mutually exclusive on the same file (see §3).
• OneDrive sync sees plaintext. "Personal Data Encryption's encryption only applies to local data saved to the disk. Applications accessing the files, including OneDrive when it syncs data, get cleartext data" ^[8]. This is the price of "transparent decryption" for the calling user's processes.
• Memory dumps can expose keys. "Kernel-mode crash dumps and live dumps can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" / "Hibernation files can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" ^[21].

Microsoft Purview Information Protection in 2026#

Purview's labelling and encryption story is the most operationally distinct of the four, because the encryption is enforced by a cloud service. Microsoft Learn enumerates the four guarantees the engine makes for a label-encrypted file:

• "Can be decrypted only by users authorized by the label's encryption settings"
• "Remains encrypted no matter where it resides, inside or outside your organization, even if the file's renamed"
• "Is encrypted both at rest (for example, in a OneDrive account) and in transit (for example, email as it traverses the internet)"
• Encryption is applied automatically by the chosen label settings ^[16].

Where the tenant root key sits is configurable:

• Microsoft-managed by default. The root key is generated and held by Microsoft in Azure. This is the default for most tenants and the lowest-friction option.
• BYOK. The customer generates the root key (typically in a Thales HSM or equivalent), uploads it to an Azure Key Vault under their control, and Azure RMS uses the customer's Azure-held key as the tenant root ^[15].
• DKE. Two keys, one held by Microsoft and one held on-premises by the customer, both required for decryption ^[20]. The DKE path narrows what Microsoft can do for the customer in exchange for the strongest possible client-side root.

Microsoft Learn frames DKE as a high-end option: "Highly sensitive (about 5% of data)" is the documentation's own scoping language ^[20]. The page makes the trade-off candid: "DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot" ^[20]. DKE is the "crown jewels" tier; using it for everything would blind every Microsoft 365 server-side service from search to Copilot to compliance.

Labels are applied to documents in three ways:

• Manually, by users in Office desktop, Office on the web, or Outlook, via the Sensitivity menu.
• Automatically, when a Purview auto-labelling policy matches a trainable classifier or content-inspection rule.
• On the wire, via Exchange transport rules that label messages as they leave the organisation.

Once applied, the label's encryption settings (if any) determine which authorised principals can request a use license. Microsoft Learn states the cross-organisation default: "By default, collaboration with other organizations that already have a Microsoft 365 or a Microsoft Entra directory is automatically supported" ^[10]. The travels-with-file guarantee is enforced precisely because the file's wire format embeds the wrapped CEK and the policy reference: a recipient who has the file but cannot obtain a use license from Azure RMS holds ciphertext.

Those are the layers you compose. But the practitioner reasonably asks: what about everything else? What about WIP, macOS, Linux, third-party DRM?

7. Competing Approaches Within and Beyond Windows#

Four within-Windows alternatives and three cross-platform alternatives the reader will ask about. Two of them are dead ends.

Group Policy plus NTFS ACLs#

NTFS ACLs are not encryption. They are OS-enforced access control: the kernel checks the ACL before satisfying a ReadFile. Boot a different operating system that does not honour NTFS ACLs and the protection is gone. EFS exists because ACLs alone are not enough; nothing in this article displaces ACLs, but ACLs alone do not appear on any of the four roots above.

BitLocker To Go#

BitLocker To Go is BitLocker for removable media -- USB sticks, external drives. It uses the same XTS-AES cipher and the same VMK/FVEK topology, with the recovery key delivered to Active Directory, Entra ID, a Microsoft account, or a printout depending on the policy ^[2]. Treat it as the same Generation 2 root as BitLocker proper, restricted to removable storage.

Windows Information Protection -- the dead branch#

Already named in §4. Microsoft Learn's /previous-versions/ page is the canonical citation for the deprecation ^[13]. The same page is candid about why WIP did not survive: "While Windows Information Protection can stop accidental data leaks from honest employees, it is not intended to stop malicious insiders from removing enterprise data" ^[13]. The honest-employees framing is the most precise statement of WIP's threat model -- and of its limit. The recommended replacement is the Microsoft Purview Information Protection plus Microsoft Purview Data Loss Prevention combination. Do not deploy WIP in 2026.

macOS FileVault 2#

Apple Platform Security documents the cipher and the key location succinctly: "FileVault uses the AES-XTS data encryption algorithm to protect full volumes on internal and removable storage devices" and "All FileVault key handling occurs in the Secure Enclave; encryption keys are never directly exposed to the CPU" ^[23]. Architecturally, FileVault 2 is BitLocker's analogue: volume-level, hardware-rooted, automatic at boot. There is no per-file user-bound layer in macOS that maps cleanly to PDE or EFS. The cross-platform reader looking for a PDE analogue on macOS will not find one in the OS itself; the equivalent has to come from per-application sandboxing (the Data Vault APIs, the App Sandbox container) or from Purview labels applied via Office for Mac.

Linux LUKS and fscrypt#

LUKS is volume-level full-disk encryption, analogous to BitLocker. fscrypt is per-directory file encryption on ext4, F2FS, UBIFS, and CephFS; the kernel documentation states the supported filesystems explicitly: "currently ext4, F2FS, UBIFS, and CephFS" ^[24]. Architecturally, fscrypt is closer to PDE than to EFS: per-directory keying, key wrapping by a user-bound credential, designed so that different files can have different keys. The kernel docs also state the bound that matters most for our purposes: "Unlike dm-crypt, fscrypt operates at the filesystem level rather than at the block device level. This allows it to encrypt different files with different keys" ^[24]. The Linux stack has had a PDE-shaped tool for years; what it does not have is Hello-equivalent identity infrastructure baked in.

Third-party DRM#

Commercial information-rights-management products from various vendors occupy roughly the same architectural slot as Purview labels: per-content envelope encryption, policy enforced at the rendering application against an identity service. The trade-offs differ on tenant ownership, identity binding, and Office integration; the architectural shape is the same.

Those are the alternatives. None of them changes the fact that on Windows, the three above-BitLocker layers we have catalogued are the layers you actually pick from. So how far can those layers actually go? What is the theoretical ceiling?

8. Where Cryptography Ends and Trust Begins#

Three bounds. Each is structural. Each tells you something about where cryptography unavoidably terminates.

Bound 1 -- At-rest encryption cannot protect plaintext in use#

Every layer this article catalogues encrypts data at rest. None of them encrypts data while it is in use by the application that opened it. The plaintext must materialise in process address space for the application to read it; once it is there, the same operating system that handed the application the plaintext also exposes that address space to debuggers, to dump-on-crash, to memory-scrapers, to anything with PROCESS_VM_READ.

The Linux fscrypt kernel documentation states this property explicitly:

"After an encryption key has been added, fscrypt does not hide the plaintext file contents or filenames from other users on the same system. Instead, existing access control mechanisms such as file mode bits, POSIX ACLs, LSMs, or namespaces should be used for this purpose." ^[24]

The same property holds for BitLocker, EFS, PDE, and Purview labels. Once unlocked, the bytes are bytes. The protection against "another process running as the same user" is the operating system's access-control layer, not the encryption.

Bound 2 -- Authorised-reader exfiltration is unbounded#

A user who is authorised to view a file can do anything with the displayed pixels. They can screen-capture, photograph the screen with a phone, dictate the contents aloud, retype them into an unprotected document, paste them into Notepad. This is the "rendezvous problem", or in older folk vocabulary the "analog hole". ※ Both "rendezvous problem" and "analog hole" are folk-knowledge terms used descriptively in industry; they are not citations to a named published conjecture, and we do not assert that any particular paper coined either. No cipher can prevent it, because the cipher's correctness requires that the authorised viewer can read the plaintext.

Microsoft itself is candid about where this leaves the RMS family of technologies. The Wikipedia AD RMS article quotes Microsoft's policy-enforcement framing:

"the differentiation between different usage rights for authorized users is considered part of its policy enforcement capabilities, which Microsoft claims to be implemented as 'best effort', so it is not considered by Microsoft to be a security issue but a policy enforcement limitation." ^[9]

The "do not print" rights bit on an RMS document is not cryptographically enforced. It is enforced by Microsoft Word, by Outlook, by the rendering applications that the use license names. A user who controls the rendering application can ignore the bit. The cipher protects against unauthorised readers; it cannot constrain authorised readers.

Bound 3 -- The key-binding root limits the protection ceiling#

The third bound is the cleanest restatement of the article's thesis. No layer can be stronger than its root.

• EFS. The root is the user's logon secret, via classic DPAPI. The Wikipedia EFS article states the ceiling: "In Windows 2000, XP or later, the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name ... any compromise of the user's password automatically leads to access to that data" ^[6]. EFS cannot be stronger than the user's password hygiene.
• PDE. The root is Windows Hello for Business. PDE cannot be stronger than Hello's own ceiling: TPM-bound asymmetric keys plus user PIN or biometric, with all the assumptions about anti-hammering, TPM attestation, and ARSO-off that the PDE configure page enumerates ^[21].
• Purview labels. The root is the Azure Rights Management tenant key, plus Microsoft Entra ID for authorization. The ceiling is Azure Key Vault custodial security plus Entra authorization correctness. DKE raises the ceiling by adding a customer-held key in series with the Azure-held key ^[20], at the cost of blinding Microsoft 365 service-side processing of that content ^[20].

None of the three roots is unconditionally stronger than the others. Each makes a trade-off that is sensible for the threat model it addresses. EFS optimises for "this exact user account, this exact machine, after both have signed on." PDE optimises for "this Hello-authenticated user, this exact device, even across boot-and-lock." Purview labels optimise for "this Entra-authenticated user, across organisations, across protocols, across time." There is no fourth option that is simply "stronger." There is only the choice of which root the data is bound to, made deliberately.

Cryptography pushes the trust boundary up but cannot eliminate it. Every layer terminates at "the application has the plaintext and the application can do anything." What changes between layers is where that boundary sits, not whether it exists.

Those are the structural limits. The operational limits -- the things Microsoft has not yet shipped a fix for -- are different. Let's look at those next.

9. Open Problems Microsoft Has Not Yet Shipped#

Seven live operational problems. None of them is academic. Each is a question your CISO is asking, and none of them has a Microsoft-shipped answer as of May 2026.

1. PDE has no DRA-equivalent#

EFS has a Data Recovery Agent. BitLocker has recovery-key escrow to Active Directory, Entra ID, a Microsoft account, or a printout. Purview has tenant-key escrow and a super-user role. PDE has none of these. The PDE FAQ does not equivocate: "Personal Data Encryption doesn't have a requirement for a backup provider, including OneDrive in Microsoft 365. However, backups are recommended in case the keys used by Personal Data Encryption to protect files are lost" ^[8]. "Backups" here means a second copy of the plaintext, made before the keys were lost; it is not key recovery. A user whose Hello credential is irrecoverably reset, and who had no second copy at the time, has unreadable files.

2. EFS in an Entra-only world#

The DRA story works because Group Policy in a classic Active Directory deployment can push a recovery-agent certificate to every machine. In an Entra-joined-only environment, there is no equivalent shipped configuration. The EFS Win32 reference still documents EFS ^[5]; what it does not document is "how to maintain an organisational EFS DRA on a fleet of Entra-joined-only devices in 2026." The migration path -- whether the answer is "stop using EFS for new files and move to PDE" (which the PDE FAQ implies ^[8]) or "configure DRA via Intune" (which is not a documented Intune-shipped flow) -- is not in Microsoft Learn.

3. Cross-tenant sensitivity-label collaboration#

Cross-organisation sharing of Purview-encrypted content works for documents emailed or shared with a recipient whose tenant is configured to accept the policy ^[10]. Cross-organisation revocation is harder. A use license issued to an external recipient is bound to the issuing tenant's RMS service; revoking the recipient's access requires the issuing tenant to act, not the recipient's. Cross-tenant collaboration policies need explicit configuration, and revocation is per-tenant, not per-policy ^[16]. CISOs running federation-heavy programmes ask about this every week; the answer is "configure explicitly, audit explicitly, accept that the recipient tenant has its own controls."

4. PDE composition with Windows Recall#

Windows Recall (the AI-driven on-device timeline of screenshots and OCR text, shipping under Copilot+ PC programmes) introduces a new question for PDE: when Recall captures a screenshot of a PDE-protected document open on screen, does the resulting Recall snapshot inherit PDE protection, or is it merely VBS-enclave-protected? Microsoft's Recall documentation describes the VBS-enclave protection model and a separate set of opt-outs for "sensitive content"; what is not documented is whether a Recall snapshot of a PDE-protected file is itself a PDE-protected file. This is a live design question.

5. DPAPI-NG protector revocation at Hello rotation#

If a user enrols a new device into Entra ID, the Hello credential on that new device is a different credential -- a fresh asymmetric key in the new device's TPM, attested at a fresh enrolment event. PDE files encrypted under the old device's Hello protector cannot be unwrapped on the new device, unless a recovery mechanism re-issues the wrap. There is no shipped recovery mechanism (see problem 1 above), so the question is operational: what does the user do with PDE files synced via OneDrive -- which sees plaintext, per the PDE FAQ ^[8] -- when they move to a new device? The answer is "OneDrive re-encrypts them under the new device's Hello on first access, because OneDrive saw plaintext." That works, and it tells you something about how thin PDE's "encryption that travels" story is.

6. Per-process cryptographic gating#

None of the four layers gates at the application identity. EFS, PDE, Purview labels all release plaintext to any process running as the authorised user (or any process holding a valid use license, in Purview's case). The CISO question that has no answer in the file-encryption stack today is "can I keep ransomware running as Alice from encrypting Alice's labelled files?" Credential Guard and LSAIso show that per-process gating with attestation is technically feasible for credentials; nothing in the file-encryption layers extends that mechanism to user files. This is the single most asked open question in the working-architect audience.

7. Cipher-mode modernisation#

PDE's choice of AES-CBC is deliberate, but it is also old. AEAD modes -- GCM, OCB3, ChaCha20-Poly1305 -- bundle integrity and confidentiality together; CBC does not. PDE composed with BitLocker XTS-AES is acceptable in practice ^[2], but the PDE layer in isolation has no integrity guarantee. Whether Microsoft will modernise the PDE cipher in a future Windows release (and what the file-format compatibility story would look like if they did) is unanswered as of May 2026.

Those are the open problems. The article's last sections turn from research into action: how does a working architect actually use these layers?

10. Composing the Layers: A Practical Guide#

A decision tree. Then the common implementation pitfalls. Then an audit checklist for the layered architecture you should be aiming for.

The decision tree#

flowchart TD
H[NTFS on hardware]
BL[BitLocker XTS-AES, TPM+PIN protector]
PDE_KF[PDE known folders: Desktop, Documents, Pictures]
EFS_Legacy[EFS legacy files only, no new EFS]
Purview[Purview sensitivity labels with encryption]
Apps[Office, Outlook, OneDrive sync clients]
H --> BL
BL --> PDE_KF
BL --> EFS_Legacy
PDE_KF --> Apps
EFS_Legacy --> Apps
Purview --> Apps

The decision tree, walked once:

• Need to protect the volume at rest, against a powered-off-device thief? BitLocker. Configure TPM+PIN protector to close the post-boot pre-logon gap at the boot layer where you can.
• Need to protect per-user on a shared device, including the post-boot pre-logon window? PDE, on Windows 11 22H2 or later, with Entra-join, Hello, ARSO disabled. For Windows 11 24H2, prefer the known-folder mode (Desktop, Documents, Pictures auto-encrypted).
• Have legacy $EFS files inherited from a previous Windows generation? Leave EFS for those legacy files; do not encrypt new files with EFS on devices that can run PDE. Choose PDE or EFS per file, not both (mutual exclusion; §3).
• Need protection that travels with the file across machines, tenants, and protocols? Purview sensitivity labels with encryption settings. Use Microsoft-managed tenant keys by default; BYOK for tenants that need customer-controlled keys; DKE for the ~5% of crown-jewel content where Microsoft 365 service-side processing must be blinded ^[20].
• All of the above, on the same file, on a modern Entra-joined Windows 11 24H2 Enterprise device? Yes. BitLocker + PDE-known-folders + Purview label is the modern default. EFS is the legacy slot.

Common implementation pitfalls#

Seven pitfalls, in order from "easy to miss" to "easy to misdiagnose."

• Forgetting to disable ARSO before enabling PDE. Microsoft Learn states the constraint twice: "Automatic Restart Sign On (ARSO) must be disabled" ^[12] and "To use Personal Data Encryption, ARSO must be disabled" ^[21]. Enabling EnablePersonalDataEncryption=1 while ARSO is still on does not produce a clean error.
• Expecting EnablePersonalDataEncryption=1 to migrate existing files. It does not. The CSP value enables the API surface (and, on 24H2, the known-folder protection). Files that existed before PDE was enabled are not automatically wrapped. Plan a separate migration pass.
• Letting kernel-mode crash dumps or hibernation expose PDE keys. Microsoft's PDE configure page is explicit: "Kernel-mode crash dumps and live dumps can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" and "Hibernation files can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" ^[21]. Configure dump policy alongside PDE; do not deploy PDE on devices that produce kernel-mode dumps to untrusted destinations.
• Assuming OneDrive sync preserves PDE protection in the cloud. It does not. The PDE FAQ states it plainly: "Personal Data Encryption's encryption only applies to local data saved to the disk. Applications accessing the files, including OneDrive when it syncs data, get cleartext data" ^[8]. Cloud-side protection is the labelling layer's job, not PDE's.
• Deploying DKE everywhere. DKE breaks Microsoft 365 server-side service integration -- search, eDiscovery, transport rules, Copilot -- because Microsoft cannot decrypt content at rest. Microsoft Learn says it: "DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot" ^[20]. DKE is for the ~5% of content explicitly scoped that way; deploying it more broadly produces a tenant where every server-side feature degrades.
• Trying to use PDE over RDP. "No, it's not supported to access protected content over RDP" ^[8]. PDE binds to local Hello sign-in; a remote desktop session is not that.
• Treating EFS as a current-generation solution on new devices. The Microsoft replacement for new per-file scenarios is PDE ^[8]. Leaving EFS in place for legacy files is fine; encrypting new files with EFS on a device that could run PDE is not the recommended path.

Audit checklist#

Five commands and CSP queries that establish where each layer actually stands on a given device.

• BitLocker. Run manage-bde -status (PowerShell, elevated). Look at the protection status, encryption method (XTS-AES 128 or 256), and key protectors. A TPM+PIN protector closes the pre-logon gap at the volume layer.
• EFS. Run cipher.exe /C <file> to inspect the EFS attribute on a given file -- it prints the user SIDs and DRA SIDs that hold wrappers. Run cipher.exe /U /N to enumerate every encrypted file on the volume without changing anything. The output tells you whether legacy EFS state actually exists.
• PDE -- top-level enablement. Query the CSP node ./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption. A value of 1 means the PDE API surface is on; 0 (or absent) means it is off ^[18].
• PDE -- known folders. Query ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDesktop, ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDocuments, ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectPictures. Note the ProtectFolders parent node; the un-nested form will return nothing ^[18].
• Purview labels. From Exchange Online PowerShell (after Connect-IPPSSession), Get-Label enumerates the sensitivity labels published in the tenant, including their encryption settings.

The "what BitLocker on its own buys you" table closes the audit out:

// Illustrative composition check. Given the per-layer status flags this device
// reports, identify which protection gaps remain. Run mentally over your device.

function evaluateLayerCoverage(state) {
const gaps = [];

if (!state.bitlockerEnabled) {
  gaps.push('BitLocker is OFF: volume is plaintext at rest');
} else if (!state.bitlockerHasPIN) {
  gaps.push('BitLocker is on, but TPM-only: post-boot pre-logon window is open');
}

if (!state.pdeEnabled) {
  gaps.push('PDE is OFF: per-user pre-logon and post-lock window not closed');
} else if (!state.pdeKnownFoldersOn) {
  gaps.push('PDE enabled but no known-folder protection: user files not auto-encrypted');
}

if (state.pdeEnabled && state.efsLegacyFilesPresent) {
  gaps.push('Legacy EFS files coexist with PDE: mutually exclusive per file, migrate carefully');
}

if (!state.purviewLabelsPublished) {
  gaps.push('No Purview labels published: no travels-with-file protection');
}

if (state.dkeEverywhere) {
  gaps.push('DKE applied broadly: Microsoft 365 service-side processing will degrade');
}

return gaps.length === 0
  ? 'Composition complete: all four layers configured with no obvious conflicts.'
  : gaps;
}

// Example: a modern Entra-joined Windows 11 24H2 Enterprise device with proper config.
const exampleDevice = {
bitlockerEnabled: true,
bitlockerHasPIN: true,
pdeEnabled: true,
pdeKnownFoldersOn: true,
efsLegacyFilesPresent: false,
purviewLabelsPublished: true,
dkeEverywhere: false
};
console.log(evaluateLayerCoverage(exampleDevice));

manage-bde -status C:
cipher.exe /C "C:\Users\alice\Documents\sample.txt"
# CSP queries via the Settings > Accounts > Access work or school export, or via
# the Intune CSP report for the device, against the nodes listed above.

Connect-IPPSSession
Get-Label | Format-Table -AutoSize

Composed correctly, those layers give you the threat coverage no single layer can. But the practitioner still has questions.

11. Frequently Asked Questions#

Five questions. Each addresses a misconception or operational concern the audit checklist exposes.

The answer the article opened with was the journey, not the destination. The destination is one sentence: three above-BitLocker layers, three protection-key roots, three threat models, by design. EFS exists because some files have to be unreadable to a different person sitting at the keyboard. PDE exists because some files have to be unreadable to the running OS itself, between boot and Hello sign-in. Purview labels exist because some files have to stay encrypted no matter which machine or protocol carries them next.

When you next see a security document that asserts "the data is protected because BitLocker is on," you now know exactly which threats that covers, and which it does not. The four roots compose. They do not compete. The asymmetry -- the very thing that makes the architecture look untidy from a distance -- is what lets each layer do what no other layer can.