Parag Mali - tag: dpapi

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

noreply@paragmali.com (Parag Mali) — Tue, 26 May 2026 00:00:00 GMT

**"BitLocker is on" is a misleading shorthand.** BitLocker encrypts the volume, but the volume is decrypted to the running OS the moment the TPM unseals -- which happens before any human authenticates. Three above-BitLocker layers close different gaps: the Encrypting File System (legacy per-user per-file, sealed by classic DPAPI), Personal Data Encryption (Hello-bound per-file, released through DPAPI-NG), and Microsoft Purview sensitivity labels (envelope encryption via Azure Rights Management, travels with the file across tenants). Three layers, three protection-key roots, three threat models -- by design, not by accident.

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" [@ms-bitlocker-countermeasures]. 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 [@wikipedia-bitlocker]. 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.

Adding a pre-boot PIN closes part of this gap by requiring user input before the TPM releases the volume master key. That is genuinely useful. But TPM+PIN does not give per-user isolation on a shared device -- everyone with the PIN sees everyone else's files. It does not travel with the file when that file is emailed, copied to OneDrive, or saved on a USB stick. And it does not bind the on-disk key to any particular human identity. Pre-boot authentication and above-volume encryption solve different problems. The three layers in this article sit *on top* of TPM+PIN BitLocker, not in place of it.

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 [@wikipedia-windows2000]. The mechanism is documented in the 1999 Microsoft technical paper Encrypting File System for Windows 2000 [@efs-1999-paper].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" [@ms-efs-win32].

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" [@ms-efs-win32]. 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) [@wikipedia-efs]. 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.

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.

A per-file symmetric key, generated at the moment a file is first encrypted, used to encrypt the file body. Wikipedia summarises the design: *"EFS works by encrypting a file with a bulk symmetric key, also known as the File Encryption Key, or FEK"* [@wikipedia-efs]. The FEK never leaves the file system in plaintext; it is RSA-wrapped to every authorised principal before being stored in the file's `$EFS` attribute.

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" [@wikipedia-efs]. The same paragraph adds the second wrapper, the one without which enterprise EFS deployments would not work.

A second principal whose public key is RSA-wrapped around the FEK at encryption time, so that the recovery agent can decrypt the file even if the owning user is unavailable. Wikipedia notes that *"In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user"* [@wikipedia-efs]. Group Policy still ships DRA configuration in modern Windows.

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 [@wikipedia-efs]; 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.

*Classic DPAPI* is the original Windows Data Protection API. Microsoft Learn describes the original pair: *"Microsoft introduced the data protection application programming interface (DPAPI) in Windows. The API consists of two functions, CryptProtectData and CryptUnprotectData."* [@ms-dpapi-ng] It is per-user and per-machine: the master key is derived from the user's logon secret, so decrypting works only when the user is logged on locally. *DPAPI-NG* (Data Protection API "Next Generation") was added in Windows 8 to extend the same idea to cloud scenarios where content encrypted on one machine must be decrypted on another, or where the unwrap should require a specific authentication factor. Microsoft Learn states the motivation: *"Cloud computing, however, often requires that content encrypted on one computer be decrypted on another. Therefore, beginning with Windows 8, Microsoft extended the idea of using a relatively ... API to encompass cloud scenarios."* [@ms-dpapi-ng] EFS uses classic DPAPI. PDE, as we will see, uses DPAPI-NG.

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" [@wikipedia-efs]. 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" [@wikipedia-efs] -- 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" [@wikipedia-efs].

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" [@ms-pde-faq]. 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.

Key idea: 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\\ 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 [@wikipedia-windows2000], the Windows Server 2003 RMS debut and lineage [@wikipedia-adrms], the November 30, 2006 BitLocker release [@wikipedia-bitlocker], the Azure Rights Management general-availability lineage [@ms-azure-rms], the Microsoft Information Protection brand and its April 2022 consolidation into Microsoft Purview [@ms-purview-launch], the Windows 11 22H2 / 24H2 Personal Data Encryption rollout [@ms-pde-overview], and the Windows Information Protection sunset [@ms-wip-deprecation]. 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 [@wikipedia-bitlocker]; the consumer launch of Vista that included it followed on January 30, 2007 [@wikipedia-bitlocker]. 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 [@ferguson-2006].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 [@wikipedia-bitlocker].

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.

A key-encrypting key that wraps the Full Volume Encryption Key. If a user changes their password or a new recovery key is escrowed, only the VMK wrappings change -- the entire volume does not need re-encryption. The VMK itself is sealed in the TPM against the platform's boot-state PCRs and released at boot when the PCRs match [@wikipedia-bitlocker].

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.

A dedicated BitLocker article on this site covers volume-internal mechanics in depth -- VMK, FVEK, recovery key escrow, TPM+PIN configuration, cipher migration. This article assumes that BitLocker knowledge and concentrates on the *above-volume* layers. The reader who wants the volume internals should read that article alongside this one.

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" [@wikipedia-adrms].

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 per-content symmetric key generated when a document is protected with a Purview sensitivity label that applies encryption. The CEK is wrapped by the tenant root key (or by the customer-held DKE key, where Double Key Encryption is configured) and travels embedded in the document file alongside policy metadata. Microsoft Learn describes the topology: *"The Azure Rights Management tenant key is your organization's root key for the main encryption service for Microsoft Purview Information Protection. Other keys can be derived from this root key, including user keys, computer keys, or document encryption keys"* [@ms-byok]. A short-lived authorization artifact issued by the Azure Rights Management service to a specific authenticated user, granting them the rights expressed by the document's policy (view, edit, print, copy, forward). 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"* [@ms-azure-rms]. A user without a valid use license cannot decrypt the CEK, even if they possess the file.

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" [@ms-azure-rms].

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" [@ms-purview-launch]. 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" [@ms-purview-labels].

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 [@ms-pde-announcement]. 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 [@ms-pde-overview]. The cipher is AES-CBC with a 256-bit key [@ms-pde-overview]. 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)" [@ms-pde-faq]. 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 [@ms-pde-announcement]. 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" [@ms-pde-overview]. 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 [@ms-pde-csp]. 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 [@ms-pde-csp].

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" [@ms-wip-deprecation].

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" [@ms-wip-deprecation]. WIP was sunset in mid-2022 and the recommended replacement was the Microsoft Purview Information Protection plus Microsoft Purview Data Loss Prevention combination [@ms-wip-deprecation].

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:

Layer	Protection-key root	Sealed by	Unlocked at	Granularity	Travels with file
BitLocker	TPM-sealed VMK	TPM, against PCRs	Boot, when PCRs match	Volume	No
EFS	User EFS RSA private key	classic DPAPI from logon secret	First file access in logon session	File, per-user	No
PDE	DEK bound to Hello credential	DPAPI-NG protection descriptor	Hello sign-in (PIN or biometric)	File, per-Hello-user	No
Purview labels	Per-content CEK wrapped by tenant key	Azure Key Vault (Microsoft, BYOK, or DKE)	Use-license issuance by Azure RMS against Entra ID	Per-content envelope	Yes

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 [@ms-efs-win32]. 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 [@wikipedia-efs].

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" [@ms-pde-overview]. 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)" [@ms-pde-faq].

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 [@ms-protection-descriptors]. Microsoft's own protection-descriptor reference adds: "The protection descriptor you specify automatically determines which key protection provider is used" [@ms-protection-descriptors].

The rule string passed to `NCryptCreateProtectionDescriptor` that names the principal or principals whose authentication will be required to unwrap a protected blob. The protection descriptor is the place in DPAPI-NG where "encrypted only for this Hello-bound principal" is expressed. Microsoft Learn documents the rule grammar (SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE) and the use of `AND` and `OR` connectors to combine principals [@ms-protection-descriptors].

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.

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" [@ms-pde-overview]. 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)" [@ms-pde-faq]. From the DPAPI-NG reference: the API surface includes NCryptCreateProtectionDescriptor, NCryptProtectSecret, and NCryptUnprotectSecret for exactly this purpose [@ms-dpapi-ng]. 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 [@ms-protection-descriptors].

Note: PDE uses AES-CBC, not an authenticated mode like AES-GCM. CBC is malleable: an attacker who can modify ciphertext on disk can flip predictable bits in plaintext. The argument that closes this gap is composition: PDE expects to run on top of BitLocker, whose modern default is XTS-AES [@wikipedia-bitlocker]. PDE's CBC mode by itself has no manipulation resistance; PDE composed with BitLocker inherits BitLocker's XTS-AES floor. This composition is intentional. Microsoft's own recommendation is to run PDE under BitLocker: "it's recommended to encrypt all volumes with BitLocker Drive Encryption for increased security" [@ms-pde-faq].

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" [@ms-purview-labels].

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 [@ms-azure-rms].

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)" [@ms-byok]. Above BYOK sits Double Key Encryption, which puts a customer-controlled key in series with the Azure-held key.

A two-key model on top of Purview's tenant root, in which decryption requires both an Azure-held key and an on-premises customer-held key. Microsoft Learn states the design: *"DKE lets you maintain control of your encryption keys. It uses two keys to protect data; one key in your control and a second key you store securely in Microsoft Azure. You maintain control of one of your keys using the Double Key Encryption service. Viewing data protected with Double Key Encryption requires access to both keys"* [@ms-dke]. The same page adds the operational consequence: *"DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot"* [@ms-dke].

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.

Key idea: 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 [@ms-efs-win32]. It is deprecated for new development -- the recommended replacement for new per-file scenarios on Entra-joined Hello-using devices is PDE [@ms-pde-faq] -- 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 [@wikipedia-efs], 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" [@wikipedia-efs]. Windows 10 1607 and Windows Server 2016 added EFS support on FAT and exFAT [@wikipedia-efs], 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 [@wikipedia-efs]; 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 [@ms-pde-overview]. As of Windows 11 24H2, the known-folder auto-encryption mode brings Desktop, Documents, and Pictures under PDE without requiring per-file API calls [@ms-pde-overview].

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" [@ms-pde-overview]. 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" [@ms-pde-configure].

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." [@ms-pde-announcement]

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 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDesktop -- introduced in 24H2, build 10.0.26100 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDocuments -- 24H2 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectPictures -- 24H2 [@ms-pde-csp].

An earlier draft of this article's research wrote these paths without the ProtectFolders parent node, and so do several blog posts on the public web. The Microsoft Learn CSP reference is authoritative: the folder-protection nodes nest under ProtectFolders. Practitioners running CSP queries against the un-nested path will see them return no value.

For per-file application use, the WinRT API is Windows.Security.DataProtection.UserDataProtectionManager.ProtectStorageItemAsync [@ms-userdataprotectionmgr]. 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 [@ms-userdataprotectionmgr].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" [@ms-pde-faq].
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" [@ms-pde-faq]. 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" [@ms-pde-configure].

Note: EFS has a Data Recovery Agent model. BitLocker has recovery-key escrow (to Microsoft account, to Active Directory, to Microsoft Entra ID, to a printout). Purview has tenant-key escrow plus a super-user role. PDE has none of these. The PDE FAQ is explicit: OneDrive is recommended as a "second copy", not as a key-recovery mechanism, and "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" [@ms-pde-faq]. Plan for this before deploying PDE at scale.

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 [@ms-purview-labels].

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 [@ms-byok].
DKE. Two keys, one held by Microsoft and one held on-premises by the customer, both required for decryption [@ms-dke]. 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 [@ms-dke]. The page makes the trade-off candid: "DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot" [@ms-dke]. 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" [@ms-azure-rms]. 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 [@wikipedia-bitlocker]. 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 [@ms-wip-deprecation]. 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" [@ms-wip-deprecation]. 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" [@apple-filevault]. 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" [@fscrypt-kernel]. 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" [@fscrypt-kernel]. 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." [@fscrypt-kernel]

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. [@wikipedia-adrms]

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" [@wikipedia-efs]. 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 [@ms-pde-configure].
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 [@ms-dke], at the cost of blinding Microsoft 365 service-side processing of that content [@ms-dke].

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.

Key idea: 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.

Capability	Theoretically impossible	Current best on Windows	Remaining gap
Per-process gating	No (with attestation, e.g., LSAIso)	Credential Guard / LSAIso for credentials; not extended to user files	No file-encryption layer gates at app identity
Authorised-reader exfiltration	Yes (analog hole)	RMS "best effort" policy enforcement [@wikipedia-adrms]	Cannot be closed by cipher; closed only by hardware DRM / endpoint controls
Pre-logon file protection	No	PDE L1 [@ms-pde-announcement]	Limited to known folders, Hello, Entra-join, 24H2+
Cross-tenant per-content protection	No	Purview labels via Azure RMS [@ms-purview-labels]	Cross-tenant policy and revocation are per-tenant

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" [@ms-pde-faq]. "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 [@ms-efs-win32]; 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 [@ms-pde-faq]) 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 [@ms-azure-rms]. 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 [@ms-purview-labels]. 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 [@ms-pde-faq] -- 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 [@wikipedia-bitlocker], 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 [@ms-dke].
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.

Note: For most Entra-joined Windows 11 24H2 deployments: BitLocker (TPM+PIN) under PDE (known-folder mode) under Purview sensitivity labels. EFS legacy only. The three above-BitLocker layers compose; the four roots stay distinct; the threat coverage adds up. Nothing in this composition needs DKE -- save DKE for the ~5% of content where Copilot blinding is desired.

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" [@ms-pde-overview] and "To use Personal Data Encryption, ARSO must be disabled" [@ms-pde-configure]. 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" [@ms-pde-configure]. 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" [@ms-pde-faq]. 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" [@ms-dke]. 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" [@ms-pde-faq]. 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 [@ms-pde-faq]. 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 [@ms-pde-csp].
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 [@ms-pde-csp].
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:

Scenario	BitLocker alone	EFS adds	PDE adds	Purview label adds
Powered-off device at rest	Protected	Same	Same	Same
Device on lock screen, post-boot pre-logon	Plaintext to OS	Plaintext (no logon)	Encrypted, Hello-bound	Encrypted, requires use license
Multi-user on the same device	Plaintext to OS	Per-user wrapping	Per-Hello-user wrapping	Per-policy wrapping
File emailed outside the tenant	Plaintext	Decrypted on SMB / cross-FS copy	Plaintext on cross-protocol egress	Encrypted, travels with file

The four layers map (loosely; this is not a regulatory opinion) to different regulatory expectations. BitLocker is the typical anchor for "data at rest" baselines in HIPAA, PCI DSS, and GDPR Article 32 (security of processing). Purview labels are where cross-organisation handling and Article 30 records-of-processing find a tractable enforcement story, because the policy travels with the data. PDE is the modern interpretation of "user-bound access" for shared devices and pre-logon scenarios. None of these regulatory frameworks names any specific layer; the practitioner's job is to map controls to expectations, not to ship a checklist of vendor features.

{` // 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)); `}

PowerShell (elevated) on the target device:

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.

From an Exchange Online PowerShell session:

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.

No. The two recovery models do not compose. BitLocker's recovery key unwraps the Volume Master Key against the TPM's seal; once the volume is unlocked, every plain NTFS file is readable again. PDE files sit *above* the volume layer, sealed by a DPAPI-NG protector bound to Windows Hello, not to the VMK. The PDE FAQ is explicit that PDE has no key-recovery model analogous to BitLocker's: *"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"* [@ms-pde-faq]. If the user's Hello credential is irrecoverably reset and there is no second-copy backup of the plaintext, BitLocker recovery does not help. No -- not directly. EFS files are encrypted with a per-file symmetric File Encryption Key (FEK), which is RSA-wrapped to the user's EFS public key (and to one or more Data Recovery Agent public keys). The user's EFS RSA *private* key is stored in `%APPDATA%\Microsoft\Crypto\RSA\\` and is sealed by classic DPAPI from the user's logon secret [@wikipedia-efs]. So the password protects the *private key that unwraps the FEK*, not the file body. The Wikipedia EFS article puts the resulting ceiling sharply: any compromise of the user's password automatically leads to access to that data [@wikipedia-efs]. Partially. On Entra-joined Windows 11 22H2 or later devices with Windows Hello for Business, PDE is the recommended replacement for new per-file encryption scenarios, and Microsoft Learn states the mutual exclusion: PDE and EFS are mutually exclusive on the same file [@ms-pde-faq]. EFS continues to ship -- legacy `$EFS` files still decrypt, the Win32 API surface still works, Group Policy DRA configuration still functions [@ms-efs-win32]. PDE is the forward direction; EFS is the legacy slot. Plan for both during transition. Labels are metadata. A *label that applies encryption* is metadata that triggers the Azure Rights Management service to encrypt the file with a per-content key and embed the wrapped key and policy reference in the file's wire format [@ms-purview-labels]. A label that applies only marking, watermarking, or DLP triggers is policy without encryption. The label itself is a classification; the encryption (if any) is a property attached to the label's settings. Yes, with one caveat. The default modern composition for an Entra-joined Windows 11 24H2 Enterprise device is BitLocker (TPM+PIN) plus PDE (known-folder mode) plus a Purview sensitivity label that applies encryption [@ms-pde-faq] [@ms-purview-labels]. The caveat is the PDE / EFS mutual exclusion -- a given file is either PDE-wrapped or EFS-wrapped, not both [@ms-pde-faq]. So the rule is: BitLocker + (PDE OR EFS, mutually exclusive) + Purview label. That is the maximum legal composition.

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.

DPAPI and DPAPI-NG: The Credential Vault Under Everything

noreply@paragmali.com (Parag Mali) — Mon, 11 May 2026 00:00:00 GMT

**Classic DPAPI (Windows 2000, February 17, 2000 [@wikipedia-windows2000]) wraps every per-user Windows secret -- browser cookies, WiFi keys, EFS file keys, Outlook passwords, Credential Manager entries -- in a four-stage chain rooted at the user's password.** DPAPI-NG (Windows 8 / Server 2012) [@wikipedia-winserver2012] replaces the (user, machine) decryption boundary with a protection descriptor [@ms-protection-descriptors] and rides the Microsoft Key Distribution Service [@ms-gmsa-overview] to give every domain controller in the forest the same per-(group, period) key without inter-DC sync. Group Managed Service Accounts, delegated Managed Service Accounts [@ms-dmsa-overview], Windows Hello for Business on TPM-less devices, and Credential Guard's isolated-secret persistence all sit on top. The 2022-2025 Golden gMSA [@semperis-golden-gmsa], Golden dMSA [@semperis-golden-dmsa], and Chromium app-bound encryption [@thn-app-bound] disclosures all admit the same thing: DPAPI's structural ceilings (user-context binding, single-password derivation, KDS-root-key irrotability, hibernation, domain-backup-key concentration) are the design, not bugs.

1. A Thumb Drive, a Profile Directory, and Three Mimikatz Commands

A DFIR analyst slides a stolen laptop's drive into a write-blocker. The volume mounts because BitLocker's recovery key was already in the corporate KMS. Six files in C:\Users\alice\AppData\Roaming\Microsoft\Protect\S-1-5-21-... -- five GUIDs and a Preferred pointer -- are the only thing standing between the analyst and a decade of Alice's saved Windows secrets.

Three Mimikatz [@mimikatz-dpapi-wiki] commands later (dpapi::masterkey /in:<GUID> /sid:S-1-5-21-... /password:<known>, then dpapi::cred /in:<credfile> /masterkey:<unwrapped>, then dpapi::chrome /in:"Login Data") the analyst has Alice's saved RDP password to the production jump host, her Microsoft 365 session cookie, the home WiFi PSK, the KeePass "Windows User Account" master password, and the EFS keys for her protected documents (each item is itemised with primary citations in §5's eleven-row credential-vault inventory). No kernel exploit. No live login. Just one (account-password, SID) pair recovered offline from last week's NTDS.dit backup.

The trick that makes that scene possible is older than most working engineers. It shipped in Windows 2000 GA on February 17, 2000 [@wikipedia-windows2000], it has been the same shape for 25 years, and its single-secret design assumption has been public and tractable since February 3, 2010 [@bursztein-talk-page]. The trick has a name: the Data Protection API, or DPAPI.

This article walks the API end-to-end at the level of detail an academic survey would, but with the working-engineer's framing the topic deserves. We open the four-stage classic-DPAPI chain at the SHA-1-of-NT-hash-into-PBKDF2-with-the-SID-as-UTF-16LE-salt level. We open the 2012 DPAPI-NG redesign [@ms-cng-dpapi] and the Microsoft Key Distribution Service's L0/L1/L2 derivation chain [@ms-gkdi-landing] at the same level of precision.

We name the four production consumers that ride the new chain in 2026: gMSAs, dMSAs, Windows Hello for Business [@ms-whfb-howitworks] software-KSP credentials, and Credential Guard [@paragmali-com-the-en]'s isolated-secret persistence. We name the five structural ceilings the 2022 Golden gMSA [@semperis-golden-gmsa], 2024 Chromium app-bound encryption [@google-security-blog-app-bound], and 2025 Golden dMSA [@semperis-golden-dmsa] disclosures all admit out loud. And we close with what a 2026 practitioner -- developer, defender, red-teamer, platform engineer -- actually does with all of it.

A note on adjacent topics: the companion Credential Guard article in this series covers the LSAISO trustlet's isolation boundary; the companion VBS Trustlets [@paragmali-com-secure-kernel] article covers the trustlet model itself; the TPM in Windows [@paragmali-com-the-c] article covers TPM-bound key storage providers; the BitLocker on Windows [@paragmali-com-limits-of] article covers full-volume encryption; the NTLMless [@paragmali-com-in-windows] article covers Kerberoasting and Golden Ticket disambiguation. Where we touch those topics, we touch them briefly and refer out -- the goal here is to make DPAPI's chain legible from CryptProtectData all the way to the four-phase GoldenDMSA pipeline.

If you can read those six files in Alice's Protect directory and you have her password's SHA-1 hash, you have everything Windows ever encrypted for her. The next eleven sections explain why -- and why the 2012 redesign that was supposed to fix it produced a new ceiling that, by 2022, turned out to be even harder to live with.

2. Why Windows 2000 Needed a Credential Vault: Generation 0 and Generation 1

Three years before DPAPI shipped, an attacker with a logged-in user's session could read every Internet Explorer auto-complete password, every Outlook Express account password, every saved-FTP credential, and every dial-up RAS phonebook entry on the machine -- without breaking any cryptography. The late-1990s reversing tradition (the original pwdump, L0phtCrack, Cain & Abel's "Protected Storage PassView," the ad-hoc Outlook Express and IE 4 form-fill stealers documented across Bugtraq and ntbugtraq mailing lists at the time) defeated all of it uniformly. The "encryption" applications used was honoured by the OS, faithfully, for the attacker's process as for the legitimate one -- because there was no system primitive that distinguished one from the other. Each application baked its own key into the binary; every reverser who pulled the binary apart pulled the key out with it.

The system-provided per-user and per-machine secret-storage primitive that ships in every Windows release from Windows 2000 onward [@wikipedia-dpapi]. The classic API surface is two flat-C functions -- `CryptProtectData` [@ms-cryptprotectdata] and `CryptUnprotectData` -- that take a plaintext, an optional caller entropy parameter, and return a self-contained opaque BLOB. The cryptographic chain inside those two functions is rooted at the user's login password and is what every "encrypted" Windows secret of the next 25 years sits on top of.

If the attacker is the user's session, what does "encrypt this for the user" even mean? That is the question every Generation 0 design dodged and every modern credential-vault design has to answer head-on. The 1990s answer (XOR-with-a-baked-in-key) and Microsoft's first attempt at a real system primitive (Protected Storage / PStore) both missed the same point in different ways.

Generation 1: Protected Storage

Protected Storage shipped with Internet Explorer 4 and stayed in the OS until Microsoft formally deprecated it. The pstore.dll [@ms-pstore] item taxonomy is a four-tuple (Key, Type, Subtype, Name) -- a folder hierarchy of named secret entries. The API was the first system-level secret store on Windows that any application could use without writing its own key derivation; the conceptual contribution survived even after the implementation was abandoned.

PStore had two ideas the post-Vista world kept and one it dropped. The two it kept: secrets live in a system primitive, not in each application; secrets are addressed by name, not by raw key handle. The one it dropped: an Authenticode access-rule clause that would have bound a stored item to the signing identity of the application that created it. No application ever used the access-rule clause in production. Microsoft's developer notes are blunt about how the story ended: "Pstore uses an older implementation of data protection. Developers are strongly encouraged to take advantage of the stronger data protection provided by the CryptProtectData [@ms-cryptprotectdata] and CryptUnprotectData functions"; PStore is "only available for read-only operations in Windows Server 2008 and Windows Vista, but may be unavailable in subsequent versions."

The PStore code-identity-pinning idea (Authenticode access rules) was abandoned in 2000 and re-invented twenty-six years later by Chromium 2024 app-bound encryption, which we will reach in §10.3.

What survived into DPAPI

The Generation 2 design that shipped with Windows 2000 in February 2000 made four moves at once. It kept the two PStore ideas worth keeping ("system-level, not per-application" and "secret addressed by structured name"). It dropped the unused Authenticode access-rule clause. It pushed the cryptographic chain down to a key derived directly from the user's login password. And it added a domain-recovery sidecar (the BackupKey Remote Protocol [@ms-bkrp-landing], which we open in §5) so managed enterprises would adopt it.

The canonical first public design document [@learn-microsoft-com-versions-ms995355vmsdn10]) -- NAI Labs / Network Associates' "Windows Data Protection" whitepaper, MSDN ms995355, October 2001 -- is unambiguous about the layering: "DPAPI initially generates a strong key called a MasterKey, which is protected by the user's password. DPAPI uses a standard cryptographic process called Password-Based Key Derivation, described in PKCS #5, to generate a key from the password." And: "DPAPI is a password-based data protection service. It requires a password to provide protection."Some secondary sources attribute a "Microsoft Windows Data Protection API" whitepaper to Niels Ferguson at niels.ferguson.com/research/dpapi.html. That URL has been TCP-unreachable for years, has zero Wayback captures across four candidate variants, and the Wikipedia Niels Ferguson article [@wikipedia-niels-ferguson] lists no DPAPI publication for him -- his named Microsoft paper is the 2006 BitLocker / Elephant-diffuser paper, not anything DPAPI-related. The verifiable Microsoft-blessed first design document is the NAI Labs ms995355 whitepaper [@learn-microsoft-com-versions-ms995355vmsdn10]).

The two-function flat-C API Microsoft shipped with Windows 2000 in February 2000 is what every Windows secret of the next 25 years has been encrypted with. The four-stage chain it hides behind those two function names is what we open up next.

3. The Four-Stage Chain: How `CryptProtectData` Actually Encrypts

A CryptProtectData [@ms-cryptprotectdata] call goes in with a plaintext buffer and an optional entropy parameter; out comes a self-contained opaque BLOB whose header adds roughly 100-150 bytes to the plaintext (the exact size depends on the algorithm choice and the master-key GUID encoding; the field-by-field BLOB layout is documented in the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] and parsed by the Mimikatz dpapi::blob [@mimikatz-dpapi-wiki] module). There is no pszProvider argument, no hKey, no algorithm choice exposed to the caller. Behind those two parameters is a four-stage cryptographic chain that has been the same shape for a quarter-century. Each stage takes the previous stage's output and one new input; the only secret in the entire chain that an offline attacker has to guess is the user's password.

flowchart TD Password["User password"] --> NTHash["NT hash
(MD4 of UTF-16LE password)"] NTHash --> Sha1NT["SHA-1(NT hash)"] SID["User SID
(UTF-16LE)"] --> PBKDF2 Sha1NT --> PBKDF2["Stage 1: PBKDF2
(HMAC-SHA1 / HMAC-SHA512)"] PBKDF2 --> PreKey["Pre-key"] MK["Stage 2: Master key
(64 random bytes)"] -->|encrypted under| AESCBC["version-cipher wrap (AES-CBC on Win7+)"] PreKey --> AESCBC AESCBC --> MKFile["%APPDATA%/Microsoft/Protect/<SID>/<GUID>"] MK --> SessionKey["Stage 3: Session key
HMAC(MK, salt || entropy)"] SessionKey --> Wrap["Stage 4: BLOB wrap
(3DES or AES-256, salt, HMAC)"] Plaintext["Plaintext"] --> Wrap Wrap --> Blob["DPAPI BLOB"]

Stage 1: Pre-key derivation

The pre-key is a function of three values. The user-account password (or its NT-hash equivalent, supplied by LSASS to the local DPAPI provider) is hashed with SHA-1; the SHA-1 result is fed into PBKDF2 as the input keying material; the user's security identifier (SID) [@learn-microsoft-com-versions-ms995355vmsdn10]) UTF-16LE-encoded is the salt; and a Windows-version-dependent iteration count completes the call. The output is a fixed-width pre-key that Stage 2 will use to wrap the master key.

The chain has changed parameters across Windows versions but has kept the four-stage shape since 2000. The Passcape master-key analysis table [@passcape-master-key-analysis] records the migration verbatim:

Windows version	Symmetric cipher	HMAC	PBKDF2 iterations
Windows 2000	RC4	SHA-1	1
Windows XP	3DES	SHA-1	4 000
Windows Vista	3DES	SHA-1	24 000
Windows 7	AES-256	SHA-512	5 600
Windows 10 / 11	AES-256	SHA-512	8 000

The shift from PBKDF2-HMAC-SHA1 / 3DES (Windows 2000 -- Vista) to PBKDF2-HMAC-SHA512 / AES-256 (Windows 7 onward) happened at Windows 7, not Windows 10; Bursztein and Picod's 2010 USENIX WOOT paper [@usenix-woot10] documented the SHA-1/3DES era through Windows 7 (the Black Hat DC 2010 talk and WOOT paper covered XP's 4,000-iteration regime and Vista's 24,000-iteration regime; Windows 7's PBKDF2-SHA512/AES-256 shift had only recently shipped when the research was finalised).

Note: 8 000 iterations of HMAC-SHA-512 is not strong against a modern wordlist attack on a leaked NT hash. Cumulative updates can raise the iteration count further; the actual count is recorded in the master-key file's header and is not implicit. When you read someone's master key, read the iteration count from the file -- do not assume.

Stage 2: The master key

The master key is a 64-byte cryptographically random secret; one is generated per user, on first use of DPAPI, and a fresh one is generated every 90 days by default. Master keys live as files inside %APPDATA%\Microsoft\Protect\<SID>\<GUID>, where the GUID is the master-key identifier embedded in every BLOB that uses it. The file begins with a service header (containing the iteration count and algorithm IDs) followed by four distinct slots: (1) the user-master-key blob (encrypted under the Stage 1 pre-key with the version-dependent cipher -- RC4 on Windows 2000, 3DES on XP through Vista, AES-256-CBC on Windows 7 and later); (2) the local-encryption-key slot; (3) the local-backup-key (Windows 2000) or CREDHIST GUID (Windows XP and later); and (4) the domain-backup-key blob [@ms-bkrp-landing] (encrypted to the DC's backup public key, see §5).

A 64-byte random secret per user, persisted as a file under `%APPDATA%\Microsoft\Protect\<SID>\<GUID>`, encrypted under a pre-key derived from the user's password and SID. Every DPAPI BLOB the user ever creates is wrapped under a session key derived from one of these master keys. Master keys rotate every 90 days by default per the NAI Labs design document [@learn-microsoft-com-versions-ms995355vmsdn10]) and the Passcape master-key analysis [@passcape-master-key-analysis], but old master keys remain on disk so old BLOBs can still be decrypted.

Stage 3: The per-call session key

For every call to CryptProtectData, DPAPI generates a fresh per-blob salt, computes an HMAC of the master key with the salt and the optional caller entropy, and uses that HMAC as the session key for the actual symmetric encryption. The session key is never stored; it is derivable from (master key, salt, entropy) at unwrap time per the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] §3.3 and the Mimikatz dpapi::blob parser [@mimikatz-dpapi-wiki]. The salt is in the BLOB header; the entropy, if any, must be supplied by the caller at unwrap time.

Stage 4: The BLOB wrap

The output BLOB is a self-describing structure with a fixed header. The provider GUID {df9d8cd0-1501-11d1-8c7a-00c04fc297eb} identifies it as a classic-DPAPI blob; the master-key GUID names the master key under which it was wrapped; an algCrypt algorithm identifier records which symmetric cipher was used (0x6603 for CALG_3DES on legacy builds, 0x6610 for CALG_AES_256 on later builds); the salt, ciphertext, and HMAC fill the rest. The Mimikatz dpapi module wiki [@mimikatz-dpapi-wiki] documents the verbatim field layout that every offline DPAPI tool parses to this day.

The `algCrypt` field in the DPAPI BLOB header is a CryptoAPI algorithm identifier from `wincrypt.h`: `0x6603` is `CALG_3DES` (the historical default, encoded as `ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_3DES`); `0x6610` is `CALG_AES_256` (used on Windows 7 and later, encoded as `ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_AES_256`). The provider GUID `{df9d8cd0-1501-11d1-8c7a-00c04fc297eb}` is the magic constant that marks every classic-DPAPI BLOB and is the same value the Mimikatz `dpapi::blob` module [@mimikatz-dpapi-wiki] and the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] §3.3.1 print when they parse one.

Parse --> Cert&#123;"CERTIFICATE="&#125;
Parse --> Local&#123;"LOCAL="&#125;
Parse --> Web&#123;"WEBCREDENTIALS="&#125;
Sid --> KSP["Microsoft Key Protection Provider<br/>+ kdssvc.dll [MS-GKDI]"]
Cert --> CertKSP["Cert's KSP<br/>(TPM-backed possible)"]
Local --> LocalProv["Microsoft Key Protection Provider<br/>(LOCAL=user / LOCAL=machine)"]
Web --> Broker["Microsoft Client Key Protection Provider<br/>(credential broker)"]
KSP --> Wrap
CertKSP --> Wrap
LocalProv --> Wrap
Broker --> Wrap
Wrap["Derive wrapping key,<br/>encrypt content"] --> Blob["Self-describing blob<br/>(descriptor + provider info<br/>+ key id + ciphertext + HMAC)"]

The output blob is self-describing per the protected-data-format reference [@ms-protected-data-format]: descriptor, provider info, key identifier, ciphertext, HMAC. Any device with a CNG implementation that can satisfy the descriptor decrypts. There is no out-of-band key shipping. There is no "encrypt the blob and ship the key separately." The descriptor is the key-distribution policy.

Key idea: DPAPI-NG separates who can decrypt (the descriptor) from where the key material lives (the provider). The descriptor is the contract; the provider is the implementation. This is the structural innovation that lets a blob protected on one machine be decrypted on another without any application-layer key-management code.

The CNG DPAPI overview page lists only two principal classes -- AD group and web credentials -- whereas the protection-descriptors page enumerates three (adding the certificate-store class). Both are correct: the certificate descriptor maps to a different provider, hence the two-principal framing on the higher-level overview page and the three-keyword framing on the descriptors-grammar page.

The LOCAL=user and CERTIFICATE= cases are interesting but mostly variations on themes that classic DPAPI or the Windows certificate store could already do. The case that required Microsoft to ship a new DC-side daemon -- the case that turned DPAPI-NG into the substrate for gMSAs [@ms-gmsa-overview], dMSAs [@ms-dmsa-overview], Hello for Business, and Credential Guard's persistence layer -- is the SID= AD-group descriptor. The next section opens its substrate: the Microsoft Key Distribution Service and the [MS-GKDI] protocol.

7. The Microsoft Key Distribution Service: How `[MS-GKDI]` Computes the Same Group Key on Every DC Without Talking to Any of Them

Imagine a forest with seven writable domain controllers. A laptop in Singapore protects a DPAPI-NG blob with SID=S-1-5-21-...XYZ (some AD group). Three months later, a phone in Seoul -- a member of the same group, on a different DC -- needs to decrypt it. Neither DC has ever heard of the blob. Both DCs derive exactly the same group key and hand it to the requesting member. No inter-DC synchronisation. No key-distribution code in either application. The mechanism is one forest-wide root key plus a deterministic key-derivation function.

The DC-side daemon that ships in every writable domain controller from Windows Server 2012 onward [@wikipedia-winserver2012]. Implements the [`[MS-GKDI]` Group Key Distribution Protocol](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a) (current revision class 10.0, April 2024) and is the substrate for every DPAPI-NG `SID=` blob, every gMSA password, every dMSA password, and the TPM-less software-KSP path of Windows Hello for Business. The service has one job: given a (group, time-period) request from a member computer, derive and return the per-(group, period) key from a single forest-wide root key.

Provisioning the root key

Every forest needs exactly one KDS root key before any DPAPI-NG SID= consumer can use it. The PowerShell cmdlet Add-KdsRootKey [@ms-add-kdsrootkey] is the provisioning entry point. The Microsoft Learn page is verbatim about the constraints: "The Add-KdsRootKey cmdlet generates a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory... It is required to run this only once per forest." The default EffectiveTime is "10 days after the current date" to allow Active Directory replication to converge across all writable DCs before any consumer tries to derive against the new key.The Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) override is for single-DC test forests only. Production forests should let the 10-day default replicate; using the back-dated override means the first consumer to call into the KDS may target a DC that has not yet received the new root key from replication.

The root key lives at CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,<forest-DN> and carries four attributes that downstream offensive-research tools enumerate: msKds-RootKeyData (the actual key bytes), msKds-KDFAlgorithmID (the KDF identifier, currently SP800-108 HMAC-SHA512), msKds-KDFParam (the KDF parameter block), and msKds-PrivateKeyLength. These four attributes, together, are everything a deterministic-KDF derivation needs to recompute every group key the forest will ever produce.

The single forest-wide secret that anchors every per-(group, period) key the Microsoft Key Distribution Service will ever derive, for every DPAPI-NG `SID=` blob, every gMSA, every dMSA, every Hello-for-Business software-KSP container, and every Credential-Guard isolated-secret persistence wrap. Provisioned with `Add-KdsRootKey` [@ms-add-kdsrootkey], exactly once per forest. Stored as four attributes (`msKds-RootKeyData`, `msKds-KDFAlgorithmID`, `msKds-KDFParam`, `msKds-PrivateKeyLength`) under `CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,`. Currently, Microsoft documents no rotation procedure [@ms-cng-dpapi-backup-keys]; see §9.3.

The L0 / L1 / L2 derivation chain

The [MS-GKDI] specification (current revision class 10.0, April 23 2024) describes the protocol. Internally, the KDS computes a three-level derivation:

L0 seed key: derived from the root key and a label that includes the period-in-hours-thousands tier and the group-related input, via a NIST SP 800-108 KDF in counter mode using HMAC-SHA-512 (see NIST SP 800-108r1 [@nist-sp-800-108r1], August 2022).
L1 seed key: derived from L0 with a second-tier label.
L2 seed key: derived from L1 with the third-tier label. This is the actual symmetric key the DPAPI-NG blob's content key wraps under (or the seed for a per-period group ECDH key pair, in the public-key DPAPI-NG mode).

The first level of the [`[MS-GKDI]`](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a) three-tier derivation chain. Computed deterministically from the KDS root key and a label that combines the time-period tier (in units of `period-in-hours / 1000`) and a group-related input. The whole point of the chain is that any DC that holds the same root key, given the same label, derives the same L0 seed key without coordination with any other DC -- which is also the whole reason a single root-key compromise compromises every key the forest will ever derive. flowchart TD Root["KDS root key
(forest-wide secret)"] --> L0["L0 seed key
(period_hours / 1000 + group input)"] L0 --> L1["L1 seed key
(second-tier label)"] L1 --> L2["L2 seed key
(third-tier label)"] L2 --> Symmetric["Per-(group, period)
symmetric key OR
ECDH key-pair seed"] KDF["SP800-108 counter-mode
KDF, HMAC-SHA-512"] -.derives.-> L0 KDF -.derives.-> L1 KDF -.derives.-> L2

The `GetKey` round trip

A member computer's local KDS-NG provider calls the GetKey RPC (the primary opnum of [MS-GKDI]) against any reachable writable DC. The DC computes the L0/L1/L2 chain on demand and returns the per-(group, period) key material. No inter-DC synchronisation is needed because the KDF is deterministic.

sequenceDiagram participant Member as "Member computer (Microsoft Key Protection Provider)" participant DC as "Nearest writable DC (kdssvc.dll)" participant Root as Root key (AD-replicated) Member->>DC: GetKey(group_sid, period_id) DC->>Root: Read msKds-RootKeyData + KDF params Root-->>DC: Root-key material DC->>DC: Compute L0(period, group) -> L1 -> L2 DC-->>Member: Per-(group, period) key material Member->>Member: Wrap (or unwrap) DPAPI-NG blob Because the KDF is deterministic by design -- this is exactly the security property NIST SP 800-108r1 [@nist-sp-800-108r1] §5 establishes -- an attacker who reads the four root-key attributes once can derive every per-(group, period) key the KDS will ever produce, *for that root key*, without further DC interaction. The same property that lets a Singapore laptop and a Seoul phone derive the same key without talking to each other lets an attacker who reads the root key derive every gMSA password the forest will ever issue. This is the same property that makes Golden gMSA [@semperis-golden-gmsa] work in §10.

Every DC in the forest runs the same kdssvc.dll over the same root key with the same KDF; every authorised member of the named group can ask any DC for the per-(group, period) key and receive the same answer. The architecture is elegant. It is also, by structural necessity, the architecture that makes a one-shot read of the root key into a one-shot compromise of every key the forest will ever derive. Hold that thought; it is what §10 is built on. First we look at what actually rides on this substrate today.

8. The Four Things That Ride DPAPI-NG in 2026

One protocol, four production consumers. The same KDS root key that protects a SID= DPAPI-NG blob is also the root from which every gMSA password, every dMSA password, every TPM-less Windows Hello private key, and every Credential Guard isolated NT-hash is derived.

A Windows-Server-2012-introduced Active Directory account class whose password is computed automatically by the Microsoft Key Distribution Service [@ms-gmsa-overview] on the DC, rotated every 30 days, 256 bytes long, and shared across multiple service hosts via the `msDS-GroupMSAMembership` SDDL gate. From the Microsoft Learn overview verbatim: *"For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA."* `Install-ADServiceAccount` on each member computer caches the derivation locally so the service can boot under the account. flowchart TD Root["KDS root key"] --> Chain["[MS-GKDI] L0/L1/L2 chain"] Chain --> GMSA["gMSA password
(30-day rotation,
256 bytes)"] Chain --> DMSA["dMSA password
(machine-bound,
Server 2025)"] Chain --> WHfB["WHfB software-KSP
(TPM-less devices,
SID + device descriptor)"] Chain --> CG["Credential Guard
LsaIso-isolated secret
(trustlet identity descriptor)"]

8.1 Group Managed Service Accounts

gMSAs shipped in Windows Server 2012 (GA September 2012). The model: one AD account, multiple service hosts, no admin-managed password rotation, no per-service password file. The Microsoft Learn overview [@ms-gmsa-overview] is verbatim about the chain: "The Microsoft Key Distribution Service (kdssvc.dll) lets you securely obtain the latest key or a specific key with a key identifier for an Active Directory account... For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA."

The constructed attribute that surfaces the password to authorised member computers is msDS-ManagedPassword [@ms-ms-adts-managedpassword]; it is computed on demand by the DC from the KDS chain when an authorised member queries it. The authorisation gate is the msDS-GroupMSAMembership security descriptor on the gMSA object: only principals whose SIDs satisfy that SDDL get the password back. Rotation is every 30 days. The password length is 256 bytes -- "a randomly generated password of 256 bytes, making it infeasible to crack" per the Semperis Golden gMSA write-up [@semperis-golden-gmsa], which is true if and only if the KDS root key is intact. We come back to that if and only if in §10.

8.2 Delegated Managed Service Accounts

dMSAs shipped in Windows Server 2025 (GA November 1, 2024 [@wikipedia-winserver2025]). The same KDS chain; a different authorisation gate. Rather than binding to AD group membership, dMSA authentication binds to machine identity: the Microsoft Learn overview [@ms-dmsa-overview] describes dMSAs as "a machine account with managed and fully randomized keys, while disabling original service account passwords. Authentication for dMSA is linked to the device identity, which means that only specified machine identities mapped in Active Directory (AD) can access the account." The msDS-ManagedPasswordId attribute carries a machine-binding component. Microsoft's marketing framing positions dMSA as the "Kerberoast-immune" replacement for static service accounts.

The Server 2025 dMSA design has its own §10 footnote: the July 2025 Semperis Golden dMSA disclosure [@semperis-golden-dmsa] found that the msDS-ManagedPasswordId time-component has predictable structure with only ~1 024 plausible values, making offline brute-forcing tractable once the KDS root key is in hand.

8.3 Windows Hello for Business software-KSP credentials

The Hello for Business how it works page [@ms-whfb-howitworks] describes the credential as a per-user per-device asymmetric key pair. On TPM-equipped devices the private key lives in the TPM and DPAPI-NG is not in the wrap path. On TPM-less devices (the structural worst case) the WHfB private key sits in a CNG software Key Storage Provider container persisted as a DPAPI-NG-protected file [@ms-whfb-howitworks] whose protection descriptor binds it to the user SID + device. The TPM in Windows article in this series covers the TPM-bound case; here we record only that the software-KSP fallback rides on DPAPI-NG and inherits the KDS root-key dependency for the SID-bound branch.

A non-hardware-bound CNG key-storage provider that persists key material in DPAPI-NG-protected files in the user profile. Used by Windows Hello for Business on TPM-less devices [@ms-whfb-howitworks] and as the fallback when no hardware-bound KSP (TPM, smart card, Secure Enclave equivalent) is available. The structural worst case for the WHfB credential, because the private key lives in a file the OS can read in any user-context process, wrapped under a DPAPI-NG blob whose protection descriptor reduces back to the KDS root key for SID-anchored bindings.

8.4 Credential Guard isolated-secret persistence

The companion Credential Guard article in this series covers LsaIso.exe and the LSAISO trustlet's isolation boundary in depth; what matters here is that the trustlet's persistence layer is DPAPI-NG. LsaIso.exe, running in VTL1 IUM, stores the isolated NT one-way function outputs and Kerberos session keys in DPAPI-NG blobs whose protection descriptor binds them to the trustlet's own identity. The VSM master key (TPM-bound on TPM-2.0 systems per Microsoft Learn's Credential Guard [@ms-credential-guard] overview, which describes how Credential Guard "uses Virtualization-based security (VBS) [@ms-vbs] to isolate secrets") is what the trustlet seals its DPAPI-NG protection state under across reboots. The end result is that even though the Credential Guard model puts the credential outside lsass.exe, the persistence of that isolated secret rides on the same KDS-rooted DPAPI-NG chain every other consumer in this section uses.

Consumer	Rotation	Authorisation gate	On-disk artefact	Recovery story
gMSA	30 days	`msDS-GroupMSAMembership` SDDL	Cached on member via `Install-ADServiceAccount`	Recompute via KDS at any time
dMSA	Managed by KDS	Machine identity in AD	Cached on member; `msDS-ManagedPasswordId` carries machine binding	Recompute via KDS
WHfB software-KSP	Per-credential lifetime	User SID + device	DPAPI-NG-wrapped key container in user profile	New enrollment if lost
LsaIso DPAPI-NG persistence	Boot-cycle bound	Trustlet identity	Trustlet-managed VTL1 store, sealed under VSM master key	Re-derive on next logon

Every shipping Windows credential primitive that just works across multiple devices, multiple service hosts, or multiple cold-boot cycles -- without per-application key-management code -- is sitting on the same KDS root key. The architectural bet is that the root key never leaks. The next two sections are about what happens when it does.

9. The Five Structural Ceilings DPAPI Cannot Close

A reader who has followed the chain through §§3-8 has earned the right to a sharp question: where does this whole architecture fail? Not where does it have bugs (it has very few cryptographic ones); where does the design draw a line that no implementation patch can move? There are exactly five such lines.

9.1 The user-context ceiling

Any process running as the user can call CryptUnprotectData [@ms-cryptprotectdata] or NCryptUnprotectSecret [@ms-ncryptprotectsecret] against any blob the user could decrypt. The chain binds the secret to the user identity, not the consuming process identity. This is the structural reason every modern browser-cookie-stealer family (Lokibot, Vidar, RedLine, Lumma, StealC) works against DPAPI-protected Chrome state keys; it is also the reason Google introduced Chrome app-bound encryption [@thn-app-bound] in July 2024 outside DPAPI. Will Harris of the Chrome security team is verbatim about why the patch had to live outside DPAPI rather than inside it: "On Windows, Chrome uses the Data Protection API (...). However, the DPAPI does not protect against malicious applications able to execute code as the logged in user -- which info-stealers take advantage of."

On Windows, Chrome uses the Data Protection API (DPAPI). However, the DPAPI does not protect against malicious applications able to execute code as the logged in user -- which info-stealers take advantage of. -- Will Harris, Chrome security team, July 2024

9.2 The single-password-derivation ceiling

The classic-DPAPI master-key wrap is PBKDF2-HMAC-SHA512(SHA1(NT-hash), SID-as-UTF16LE, ~8000 iterations) in the modern (Windows 10/11) era per the Passcape table [@passcape-master-key-analysis]. 8 000 iterations of HMAC-SHA-512 is not strong against a modern wordlist attack on a leaked NT hash. The structural limit is the user's password, not the cryptographic primitive. The KDF parameter is tunable; the single secret in the chain is not -- a strong password makes the chain strong, a weak password makes the chain weak, and there is no architectural way to recover from a weak password short of re-deriving every user's master key under a stronger one.

9.3 The KDS-root-key irrotability ceiling

Once a KDS root key is in production use, rotating it would invalidate every gMSA msDS-ManagedPassword, every dMSA password, every SID= blob, every Hello-for-Business software-KSP container, and every Credential-Guard isolated-secret blob ever produced under it. Microsoft's documented mitigation is preventative (a system access control list on msKds-RootKeyData), not recoverable. This is the same structural ceiling that the Microsoft Learn DPAPI-backup-keys page [@ms-cng-dpapi-backup-keys] admits for the older [MS-BKRP] keys, in identical language: "There currently is no officially supported way of changing or rotating these DPAPI backup keys on the domain controllers." Burn-the-forest-and-rebuild for [MS-BKRP]; SACL-the-attribute-and-hope for KDS root keys.

9.4 The hibernation / S4 ceiling

CryptProtectMemory / CryptUnprotectMemory [@ms-cryptprotectmemory] provide an in-memory scrub primitive that scopes a secret across same-process / cross-process / cross-session lifetimes. They cannot scrub RAM written to hiberfil.sys on suspend-to-disk. On resume the master key is in plaintext in the page cache. The structural defence is BitLocker on the system volume (the BitLocker on Windows article in this series covers full-volume encryption end-to-end); within DPAPI itself the ceiling cannot move because the OS has to be able to resume.

9.5 The domain-backup-key concentration ceiling

The [MS-BKRP] backup key is the recoverability story for the password-reset case -- and it is also the structural reason any DA who can dump LSASS on a writable DC has every user's master key in the forest. mimikatz "lsadump::backupkeys /system:dc.contoso.local /export" is the canonical primitive, documented in the Mimikatz DPAPI wiki [@mimikatz-dpapi-wiki]. The architectural answer (HSM-backing the DC's RSA private key) is not in Microsoft's mainline guidance; the recommendation when these keys are compromised [@ms-cng-dpapi-backup-keys] is the burn-the-forest-and-rebuild line we just quoted.

Key idea: These five ceilings are not bugs. They are the design's price for the design's other guarantees. The user-context ceiling buys ubiquitous adoption. The single-password ceiling buys a usable recovery path. The KDS-root-key ceiling buys cross-DC determinism. The hibernation ceiling buys process performance and resumability. The domain-backup-key ceiling buys enterprise recovery. Every one of the next five years' DPAPI incidents will hit one of these five ceilings.

The 2022-2025 disclosures are not five surprises. They are five different attackers naming five different ceilings out loud. The next section walks the named incidents one ceiling at a time.

10. The 2022-2025 Residual Class: Golden gMSA, Golden dMSA, and Chromium App-Bound Encryption

In March 2022, Yuval Gordon (Microsoft Security Researcher, via Semperis blog) published Introducing the Golden GMSA Attack [@semperis-golden-gmsa] and the GoldenGMSA [@goldengmsa-repo] C# tool. In July 2024, Google announced Chrome's app-bound encryption [@google-security-blog-app-bound]. In July 2025, Adi Malyanker (also Semperis) published Golden dMSA: What Is dMSA Authentication Bypass? [@semperis-golden-dmsa] and the GoldenDMSA [@goldendmsa-repo] tool, mirrored on PR Newswire with a July 16, 2025 dateline [@prnewswire-semperis-dmsa]. Three disclosures in three years, three different ceilings -- but the same underlying pattern: each one is an admission that the structural ceiling cannot be patched inside DPAPI.

flowchart LR C1["§9.1 user-context"] --> Chromium["Chromium app-bound encryption
(July 2024, Will Harris)"] C2["§9.3 KDS-root-key irrotability"] --> GGMSA["Golden gMSA
(March 2022, Y. Gordon)"] C2 --> GDMSA["Golden dMSA
(July 2025, A. Malyanker)"] C3["§9.5 domain-backup-key"] --> MimikatzBKK["mimikatz lsadump::backupkeys"] C4["§9.4 hibernation / S4"] --> BL["BitLocker article cross-link"]

10.1 Golden gMSA (Yuval Gordon, Microsoft / Semperis blog, March 2022)

Targets the §9.3 KDS-root-key irrotability ceiling. Gordon is verbatim about the two-step nature of the attack: "An attacker with high privileges can obtain all the ingredients for generating the password of any gMSA in the domain at any time with two steps: Retrieve several attributes from the KDS root key in the domain... Use the GoldenGMSA tool to generate the password of any gMSA associated with the key, without a privileged account." Step 1 is a one-shot read of the KDS root key attributes. Step 2 is offline derivation. There is no further DC interaction, ever, because the [MS-GKDI] chain is deterministic by NIST SP 800-108r1 design.

The defensive answer is in the GoldenGMSA repository [@goldengmsa-repo]: "configure a SACL on the KDS root key objects for everyone reading the msKds-RootKeyData attribute. Once the system access control list (SACL) is configured, any attempt to dump the key data of a KDS root key will generate security event 4662 on the DC where the object type is msKds-ProvRootKey and the account name is not a DC." Plus the cross-trust SACL on msDS-ManagedPasswordId with property GUID {0e78295a-c6d3-0a40-b491-d62251ffa0a6}. This is a detective control, not a recovery control. Once the root key has been read, every gMSA password the forest has ever issued or will ever issue under that root key is offline-derivable.

An attacker with high privileges can obtain all the ingredients for generating the password of any gMSA in the domain at any time with two steps. -- Yuval Gordon, Microsoft / Semperis blog, March 2022

The Golden gMSA SACL detects same-trust reads only. Cross-trust reads of msDS-ManagedPasswordId from a forest the auditing forest does not control are the documented detection blind-spot. If your gMSA-using forest has a one-way trust from a forest you do not own, you cannot see its reads.

10.2 Golden dMSA (Adi Malyanker, Semperis, July 2025)

Targets the §9.3 ceiling, plus a fresh dMSA-specific surface. Malyanker is verbatim about the structural flaw: "a critical design flaw: a structure that's used for the password-generation computation contains predictable time-based components with only 1,024 possible combinations, making brute-force password generation computationally trivial." The four-phase pipeline is enumerated in the GoldenDMSA repository [@goldendmsa-repo]: "Phase 1: Key Material Extraction (pre requirement of the attack) -- Dump the KDS Root Key from the DC. Phase 2: Enumerate dMSA accounts ... Phase 3: ManagedPasswordID guessing ... Phase 4: Password Generation." The tool exposes commands wordlist, info, kds, bruteforce, compute, and convert -- the operational vocabulary the four-phase pipeline needs.

Semperis' own rating is MODERATE with the explicit caveat "to exploit it, attackers must possess a KDS root key available only to only the most privileged accounts: root Domain Admins, Enterprise Admins, and SYSTEM." That is exactly the §9.3 ceiling re-stated. The novelty in dMSA is the 1 024-combination time-component flaw -- a design weakness on top of the structural ceiling, not a substitute for it.

10.3 Chromium app-bound encryption (Will Harris, Google Chrome, July 30, 2024)

Targets the §9.1 user-context ceiling. The Google Security Blog announcement [@google-security-blog-app-bound] describes a COM-elevation service that wraps the Chrome state key with both DPAPI and a per-binary identity check the COM service enforces. The verbatim quote, mirrored via The Hacker News [@thn-app-bound]: "Because the app-bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing."

The architecturally important word is "app-bound." Chromium's response to the user-context ceiling lives outside DPAPI. DPAPI itself is unchanged. The 2024 patch is application-layer code-identity pinning -- exactly what Generation-1 Protected Storage's abandoned Authenticode-access-rule clause was supposed to be in 2000, exactly what Apple Keychain [@apple-platform-security-keychain] has shipped on macOS for over two decades, exactly what the §11 wishlist asks for.

10.4 The recurring pattern

Each disclosure does not break a cryptographic primitive. Each is a re-statement of "the design's ceiling is the design's ceiling." The defensive answers are detection (SACL audit; cross-trust read alerting; binary-identity check) and workaround at a higher layer (the COM-elevation service Chrome wraps DPAPI in), never cryptographic strengthening of DPAPI itself. The 2026 reader's job is to recognise which ceiling each new incident hits.

Year	Disclosure	Ceiling hit	Tool reference	Defensive answer
2022	Golden gMSA (Y. Gordon, Microsoft / Semperis blog)	§9.3 KDS irrotability	`GoldenGMSA` [@goldengmsa-repo]	SACL on `msKds-RootKeyData`; Event 4662
2024	Chromium app-bound encryption (W. Harris, Google)	§9.1 user-context	Chrome 127 release notes [@chromereleases-127-stable]	COM-elevation per-binary identity check, outside DPAPI
2025	Golden dMSA (A. Malyanker, Semperis)	§9.3 + dMSA `msDS-ManagedPasswordId` predictability	`GoldenDMSA` [@goldendmsa-repo]	SACL plus monitoring `msDS-ManagedPasswordId` brute-force

By 2026 the pattern is clear: DPAPI's structural ceilings produce a steady drip of disclosures, each defensively answerable but none cryptographically fixable inside DPAPI itself. The open question is what the successor would even look like -- and that is the next section.

11. Open Problems

A few sharp open problems remain at the design layer -- problems that a future Generation 4 of the credential-vault tradition would have to solve. None of them is in Microsoft's published roadmap as of 2026.

KDS root-key rotation

A hybrid wrap-then-re-wrap-on-first-decrypt-under-new-root scheme could in principle restore rotation without invalidating existing blobs: every consumer would carry a tag indicating which root-key generation last unwrapped it; on first unwrap under a generation-N+1 root the system would re-wrap the consumer-side cache. No standard or product implements this today; no public proposal revises [MS-GKDI] to add it.

Code-identity pinning

Apple Keychain [@apple-platform-security-keychain] enforces "keychain items can be shared only between apps from the same developer ... enforced through code signing, provisioning profiles, and the Apple Developer Program." DPAPI / DPAPI-NG have no equivalent. A CALLER_ATTRIBUTION=Publisher:<wdac-rule-hash> descriptor would, in principle, give Windows the same property -- the SHA-256 hash of the WDAC rule [@paragmali-com-app-ide] that authorises the calling binary, baked into the descriptor, checked at unwrap time. No one is shipping it. The 2024 Chromium app-bound encryption response [@thn-app-bound] is the application-layer workaround that proves the design gap is real.

Post-quantum migration

DPAPI-NG today uses RSA or ECDH key transport via CMS enveloped-content format (CERTIFICATE= with RSA private keys, SID= for group descriptors) per the protected-data-format [@ms-protected-data-format] reference. Both wrap algorithms are vulnerable to Shor's algorithm on a sufficiently large quantum computer, and the persistent on-disk blob format is the harvest-now-decrypt-later target -- a framing surfaced across NIST's broader post-quantum migration corpus, including the NIST PQC project page [@nist-pqc-project] and the linked NIST IR 8547 migration-timeline document. The migration story for the symmetric chain is comparatively easy (the SP800-108 KDF is parameterised; HMAC-SHA-512 has no quantum-cliff weakness for the relevant key sizes). The migration story for the public-key wrap is the hard part. NIST published FIPS 203 (ML-KEM) [@nist-fips-203] and FIPS 204 (ML-DSA) [@nist-fips-204] in August 2024; OpenSSH 9.9 [@openssh-9-9-release] (September 2024) and TLS deployments shipped hybrid post-quantum key exchange. Windows added experimental post-quantum TLS support in 2024 but has not yet announced ML-KEM CNG-DPAPI providers; see the companion Post-Quantum Cryptography on Windows [@paragmali-com-year-migrati] article in this series for the broader Windows migration story. The shape that fits DPAPI's ceiling-laden design is hybrid wrap-then-re-wrap-on-first-decrypt: a hybrid wrap (RSA-OAEP || ML-KEM or ECDH || ML-KEM) -- protect under (RSA+ML-KEM) or (ECDH+ML-KEM) today; let consumers re-wrap to the new combiner on first unwrap; phase out the classical half on a long horizon -- is the only forward-compatible answer; Microsoft's published DPAPI-NG protection-providers [@ms-protection-providers] have not yet announced one.

Credential roaming for Entra-joined-only / unmanaged-device estates

Classic DPAPI's cross-device story has always been "use roaming profiles" (deprecated) or "use the [MS-BKRP] backup key" (admin-recovery, not user-driven). DPAPI-NG's SID= solves it cleanly for AD-joined estates but the modern Entra-only estate has no native equivalent -- the LOCAL=user descriptor is per-machine. An ENTRAGROUP=<object-id> descriptor that resolved through Entra ID Token Service the way SID= resolves through KDS would close the gap. No public roadmap announces this.

Hibernation / S4

BitLocker [@wikipedia-bitlocker] on the system volume defends the disk; suspending fully to ROM (or refusing S4 entirely) defends the in-RAM master key. Hardware-bound key derivation (TPM-released-only-while-PCRs-stable) would close more of the gap; the TPM in Windows article in this series covers TPM-bound primitives that approximate this property.

Every one of these is a design gap -- a property the architecture would need a new primitive to satisfy. None is on Microsoft's announced roadmap. The architecture we have is the architecture we will have for at least the next five years; the practitioner's job is to know which ceilings their estate is exposed to and how to detect each of them.

12. Practical Guide and Closing

The four-audience guide for the 2026 practitioner.

12.1 For a developer

Use CryptProtectData / CryptUnprotectData [@ms-cryptprotectdata] for per-user-on-this-device secrets. Pass pOptionalEntropy to bind the blob to a per-application secret -- but understand it is security-by-obscurity, not a code-identity check; any reader of the SharpDPAPI source [@sharpdpapi-readme] who knows your constant entropy can reproduce the unprotect call as the user.

Use NCryptProtectSecret [@ms-ncryptprotectsecret] with the appropriate descriptor for cross-device or multi-principal cases. LOCAL=user mirrors classic DPAPI on a single machine. SID=<group-sid> reaches AD groups via KDS. CERTIFICATE=HashID:<sha1> reaches a named certificate (TPM-backed for the high-security case). Use the WebAuthn / FIDO2 path for authentication secrets; do not store passwords in DPAPI when WHfB / passkey paths are available.

{` // Returns the appropriate DPAPI-NG protection-descriptor string for a use case. // Reference: learn.microsoft.com windows win32 seccng protection-descriptors function descriptorFor(useCase, ctx) { switch (useCase) { case "single-device-single-user": return "LOCAL=user";

case "ad-group":
  // Multiple machines, AD-authorized group members can decrypt.
  return "SID=" + ctx.groupSid;

case "tpm-backed-cert":
  // Decrypter must hold the named certificate's private key (TPM-bound KSP).
  return "CERTIFICATE=HashID:" + ctx.certThumbprintSha1;

case "web-credential":
  // Resolves through the Windows credential broker.
  return "WEBCREDENTIALS=" + ctx.credName;

default:
  throw new Error("Unknown use case: " + useCase);

} }

console.log(descriptorFor("single-device-single-user")); console.log(descriptorFor("ad-group", { groupSid: "S-1-5-21-...-5101" })); `}

Note: The pOptionalEntropy parameter to CryptProtectData lets you tag a blob with an extra secret the unwrap call must supply. It does not bind the blob to a process or a publisher. If your "entropy" is a constant compiled into your binary, every reverse-engineer who reads the binary can reproduce your unprotect call as the user. For real per-application separation today, use the Chromium 2024 pattern [@thn-app-bound]: wrap your DPAPI / DPAPI-NG blob in a SYSTEM-elevated COM service that enforces a per-binary identity check.

12.2 For a defender or DFIR analyst

Triage the credential-vault inventory in §5 first. The high-value paths are %APPDATA%\Microsoft\Protect\<SID>\, %APPDATA%\Microsoft\Protect\CREDHIST, %APPDATA%\Microsoft\Credentials\, %LOCALAPPDATA%\Microsoft\Vault\, the Chromium / Edge profile databases, and the AD CN=Master Root Keys,... container.

The SACL guidance from the GoldenGMSA repository [@goldengmsa-repo] is the only detective control today: "configure a SACL on the KDS root key objects for everyone reading the msKds-RootKeyData attribute. Once the system access control list (SACL) is configured, any attempt to dump the key data of a KDS root key will generate security event 4662 on the DC where the object type is msKds-ProvRootKey and the account name is not a DC." Plus the cross-trust SACL on msDS-ManagedPasswordId with property GUID {0e78295a-c6d3-0a40-b491-d62251ffa0a6}.

Tooling: Mimikatz [@mimikatz-dpapi-wiki] dpapi::* modules, SharpDPAPI [@sharpdpapi-readme], DPAPIck [@bursztein-talk-page] (Bursztein-Picod 2010), GoldenGMSA [@goldengmsa-repo], GoldenDMSA [@goldendmsa-repo], and the Volatility [@volatility3-repo] lsadump / cachedump / hashdump plugins for live-memory extraction of DPAPI_SYSTEM and the other LSA secrets that seed SYSTEM-context master-key derivation.

Walk a synthetic profile-directory layout and emit a DPAPI-relevant triage report.

import os from collections import defaultdict

Synthetic profile layout for demonstration only.

synthetic = { "Users/alice/AppData/Roaming/Microsoft/Protect/S-1-5-21-1234-1001/Preferred": "8KB", "Users/alice/AppData/Roaming/Microsoft/Protect/S-1-5-21-1234-1001/0d4a...": "740B", "Users/alice/AppData/Roaming/Microsoft/Protect/CREDHIST": "176B", "Users/alice/AppData/Roaming/Microsoft/Credentials/abcdef...": "300B", "Users/alice/AppData/Local/Microsoft/Vault/4BF4C442-9B8A-41A0-B380-DD4A704DDB28/Policy.vpol": "180B", "Users/alice/AppData/Local/Google/Chrome/User Data/Default/Cookies": "4MB", "Users/alice/AppData/Local/Google/Chrome/User Data/Local State": "12KB", }

categories = { "Master keys": "/Microsoft/Protect/S-1-", "CREDHIST chain": "/Protect/CREDHIST", "Credential Manager": "/Microsoft/Credentials/", "Windows Vault": "/Microsoft/Vault/", "Chrome state key": "/Google/Chrome/User Data/Local State", "Chrome cookies": "/Google/Chrome/User Data/Default/Cookies", }

report = defaultdict(list) for path, size in synthetic.items(): for label, marker in categories.items(): if marker in path: report[label].append((path, size))

for label, items in report.items(): print("==", label) for path, size in items: print(" ", path, "(" + size + ")") `}

12.3 For a red-team operator

The chain of primitives most-commonly used (verbatim from the harmj0y operational guide [@harmj0y-operational-guide] and the Mimikatz wiki [@mimikatz-dpapi-wiki]):

The operational vocabulary, in order of dependency:

mimikatz "sekurlsa::dpapi" -- enumerate cached master keys from a live lsass.exe.
mimikatz "dpapi::masterkey /in:<MK> /sid:<SID> /password:<known>" -- unwrap a master-key file.
mimikatz "dpapi::cred /in:<credfile>" -- decrypt a Credential Manager entry.
mimikatz "lsadump::backupkeys /system:dc.contoso.local /export" -- export the [MS-BKRP] RSA private key from a writable DC.
SharpDPAPI triage /pvk:key.pvk -- offline triage with the domain backup key.
SharpChrome cookies /pvk:key.pvk -- decrypt Chrome / Edge cookies offline.
GoldenGMSA gmsainfo then GoldenGMSA compute -k <root-key-guid> -s <gmsa-sid> -m <managed-password-id> -- offline gMSA password derivation per the March 2022 disclosure [@semperis-golden-gmsa].
GoldenDMSA wordlist / bruteforce / compute -- the four-phase Server 2025 dMSA pipeline per the July 2025 disclosure [@semperis-golden-dmsa].

The post-Credential-Guard scope reality: LSASS-isolated NT-hashes are gone (the Credential Guard article in this series covers what LsaIso.exe actually computes); on-disk DPAPI master keys, Chrome cookies, and Vault credentials are still there. The credential-vault inventory in §5 is the operator's map; the §10 disclosure list is the operator's playbook.

12.4 For a platform or identity engineer

Provision the KDS root key carefully. Use the Add-KdsRootKey [@ms-add-kdsrootkey] default 10-day EffectiveTime for production forests so AD replication converges before any consumer derives against the new key; the -EffectiveTime ((Get-Date).AddHours(-10)) override is for single-DC test forests only, never production.

Note: The Golden gMSA defensive answer is detective, not preventive. Configure the msKds-RootKeyData SACL before any production gMSA exists, so every read of the root-key attributes generates Security Event 4662 and you have a baseline of "DC accounts only, no humans, ever." Add the msDS-ManagedPasswordId cross-trust audit on day 1 too. After-the-fact SACL provisioning leaves a window during which the key may have been read silently.

For Server 2025 dMSA, monitor the msDS-ManagedPasswordId [@ms-ms-adts-managedpassword] brute-force surface until Microsoft addresses the time-component predictability the Golden dMSA disclosure [@semperis-golden-dmsa] named.

For Hello for Business, prefer the TPM-bound KSP (MS_PLATFORM_CRYPTO_PROVIDER); the software-KSP DPAPI-NG fallback [@ms-whfb-howitworks] is the structural worst case (per §8.3) and inherits the KDS root-key dependency on every TPM-less device.

Cross-platform context: Apple Keychain [@apple-platform-security-keychain] reaches a stronger upper bound (Secure-Enclave-bound + code-identity-pinned via the Apple Developer Program); GNOME libsecret [@libsecret-reference] covers the analogous Linux primitive over the Secret Service D-Bus interface. Neither is a drop-in replacement; both have shapes worth borrowing if Microsoft ever publishes the Generation-4 design.

12.5 The closing reflection

The credential vault under everything has a single-sentence summary in 2026: classic DPAPI is as strong as the user's password; DPAPI-NG is as strong as the KDS root key's life-cycle SOP is; both architectures admit ceilings the cryptography cannot move. The literacy a practitioner needs is the ability to recognise which ceiling any new incident hits. Twelve sections later, you have it.

Frequently Asked Questions

No. Credential Guard [@ms-credential-guard] protects LSA-isolated secrets only. Chrome cookies live in the user's profile under DPAPI / DPAPI-NG and are decryptable by any process running as the user, exactly as before. The Chromium 2024 app-bound encryption [@thn-app-bound] is a per-process workaround for the §9.1 user-context ceiling, not a fix inside DPAPI itself. A web reset of a *consumer* Microsoft Account password does not append to CREDHIST and does not benefit from [`[MS-BKRP]`](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-bkrp/) backup -- there is no domain in the consumer scenario. Master keys encrypted under the previous password become irrecoverable for consumer Microsoft Accounts, full stop. Domain-joined enterprise users escape this because the domain backup key still works. True if the KDS root key [@ms-add-kdsrootkey] is intact -- the Semperis write-up [@semperis-golden-gmsa] records the *"randomly generated password of 256 bytes, making it infeasible to crack"* claim. False under the Golden gMSA / Golden dMSA [@semperis-golden-dmsa] assumption that any DA / SYSTEM on a DC can read `msKds-RootKeyData`. A 256-byte random password is irrelevant if the attacker can derive it offline. No. DPAPI-NG [@ms-cng-dpapi] is a redesign whose protection model is *descriptor-based* (multi-principal, multi-device) rather than *user-and-machine-bound*. The two APIs coexist; classic DPAPI is still the default for `CryptProtectData` [@ms-cryptprotectdata] callers, and DPAPI-NG is the path for `NCryptProtectSecret` [@ms-ncryptprotectsecret] callers. No. On TPM-less devices the WHfB private key sits in a CNG software-KSP container persisted as a DPAPI-NG blob whose protection descriptor binds it to user SID + device, per the Hello for Business architecture [@ms-whfb-howitworks]. The TPM-bound case is the preferred deployment; the software-KSP fallback is the structural worst case and inherits the §9.3 KDS root-key dependency. No. `CryptProtectMemory` [@ms-cryptprotectmemory] scrubs in-memory secrets between same-process / cross-process / cross-session lifetimes but cannot prevent the OS from writing the page-protected RAM into `hiberfil.sys` on suspend-to-disk. BitLocker on the system volume is the structural defence (the *BitLocker on Windows* article in this series covers full-volume encryption end-to-end). No. It broke the *secrecy of DPAPI's design*. The 2010 disclosure [@usenix-woot10] made the master-key chain public and tractable for offline forensics; it did not weaken the cryptography. The "break" was always structural -- DPAPI is as strong as the user's password is. The two-author byline is Bursztein and Picod (Black Hat DC 2010, USENIX WOOT 10), not "Bursztein, Picod and Aussel."

<StudyGuide slug="dpapi-and-dpapi-ng-the-credential-vault-under-everything" keyTerms={[ { term: "DPAPI", definition: "The Data Protection API; the per-user / per-machine secret-storage primitive in every Windows release from Windows 2000 onward." }, { term: "Master key", definition: "A 64-byte random secret per user, stored under %APPDATA%/Microsoft/Protect/<SID>/<GUID>, encrypted under a pre-key derived from the user's password and SID." }, { term: "[MS-BKRP] BackupKey Remote Protocol", definition: "The LSASS-hosted RPC interface that lets a member computer dual-wrap its master key under both the user password pre-key and a DC RSA backup public key; the canonical universal-decryption primitive available to Domain Admins." }, { term: "CREDHIST", definition: "The previous-password hash chain stored in %APPDATA%/Microsoft/Protect/CREDHIST; one entry per self-initiated password change; broken by administrative reset and consumer-Microsoft-Account web reset." }, { term: "Protection descriptor (DPAPI-NG)", definition: "The DPAPI-NG self-describing string (SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE) that names the set of principals permitted to remove protection from a blob." }, { term: "Microsoft Key Distribution Service (kdssvc.dll)", definition: "The DC-side daemon that implements the [MS-GKDI] protocol and computes per-(group, period) keys deterministically from a single forest-wide root key." }, { term: "KDS root key", definition: "The single forest-wide secret that anchors every per-(group, period) key the KDS will ever derive; provisioned exactly once per forest with Add-KdsRootKey; documented as having no rotation procedure." }, { term: "Group Managed Service Account (gMSA)", definition: "A Server-2012-introduced AD account whose 256-byte password is derived from the KDS chain and rotated every 30 days, gated by the msDS-GroupMSAMembership SDDL." }, { term: "Software KSP", definition: "The non-hardware-bound CNG Key Storage Provider that persists key material as DPAPI-NG-protected files; used as the WHfB fallback on TPM-less devices." }, { term: "Golden gMSA / Golden dMSA", definition: "The 2022 / 2025 Semperis offline-derivation attacks that compute any gMSA / dMSA password the forest will ever issue, given a one-shot read of the four KDS root-key attributes." } ]} />

Edge's Two Password Cryptographies: A Beautiful PSI on the Wire, and Plaintext RAM by Design

noreply@paragmali.com (Parag Mali) — Mon, 11 May 2026 00:00:00 GMT

Microsoft Edge ships two cryptographic designs for "passwords" inside the same `msedge.exe` binary, owned by the same product team, with radically different threat models. The first -- Password Monitor -- is a deployed Private Set Intersection protocol built on Microsoft SEAL, the first production consumer homomorphic-encryption deployment in a browser, and is state-of-the-art cryptography for defending against a compromised breach-corpus server. The second -- Edge's local credential storage -- decrypts every saved password into process memory at browser launch and keeps it there for the lifetime of the session, a design Tom Joran Sonstebyseter Ronning's `EdgeSavedPasswordsDumper` (May 4, 2026) made legible and that Microsoft classified as "by design." These are not incompatible designs. They are precise statements about which threat models the Edge product team is and is not defending against, and treating them as one unified "password security" story masks where the actual compromise happens in 2026.

1. Two cryptographies, one product, one week

On January 21, 2021, Microsoft Research's Cryptography and Privacy group announced Edge's Password Monitor ships a homomorphic-encryption-based Private Set Intersection protocol built on Microsoft SEAL. The post is explicit that this is "possible due to pioneering cryptography research and technology incubation done here at Microsoft Research," that it is the result of a collaboration "between [the] Cryptography and Privacy Research Group, and Edge product team," and that the protocol descends from two specific papers: "Fast Private Set Intersection from Homomorphic Encryption" and "Labeled PSI from Fully Homomorphic Encryption with Malicious Security" [@msr-password-monitor-2021]. It is, by a comfortable margin, the first production consumer deployment of homomorphic encryption in a browser.

On May 4, 2026, at 14:29:51 UTC, a researcher in Oslo named Tom Joran Sonstebyseter Ronning posted to X: "Microsoft Edge loads all your saved passwords into memory in cleartext -- even when you're not using them" [@ronning-x]. He linked a GitHub repository called EdgeSavedPasswordsDumper: roughly 230 lines of C# that opens a handle to the parent msedge.exe process and reads every saved credential as plaintext, with no kernel exploit, no admin (against same-user processes), and no DPAPI bypass [@ronning-github]. The README confirms the behaviour is present in "any Edge versions that's Chromium based (from version 79 and newer, including 147.0.3912.98 and any future version)" [@ronning-github]. Two days later, on May 6, 2026, Microsoft told Forbes that the in-memory behaviour is "an expected feature of the application" and "by design" [@forbes-winder].

Both designs ship in the same binary. Both are owned by the same product team. Both can be defended on technical grounds. And both stories get told about the same word: "passwords."

This article argues they are about two different threat models, and the apparent contradiction in the headline disappears once you separate them.

A two-party cryptographic protocol in which Alice holds a set $S_A$, Bob holds a set $S_B$, and they jointly compute $S_A \cap S_B$ such that each party learns the intersection (or, in some variants, only one party does) and nothing else about the other party's set beyond what the intersection implies.

The PSI story is genuinely beautiful. It begins in 1986 with a paper hardly anyone reads, climbs through a 35-year cryptographic engineering effort to make oblivious transfer cheap enough to be free, lands in 2017 on a homomorphic-encryption breakthrough whose cost curve fits the breach-checking problem exactly, and ships on consumers' desktops by 2021 [@msr-password-monitor-2021]. The endpoint-storage story is genuinely awkward. Edge unwraps every DPAPI-encrypted saved credential into process memory when the password feature first activates, keeps the plaintext resident for the lifetime of the session, and accepts that any same-user process can read it back out [@ronning-github]. Microsoft's official position is that local code execution on the user's machine is "outside the threat model" of the browser password store -- a position that is internally consistent with a decade of MSRC policy and also true [@forbes-winder].

The thesis: "password security" is at least two threat models, and Microsoft has chosen to deploy genuinely state-of-the-art cryptography against one of them while explicitly conceding the other. Treating both as one unified story is how product narratives obscure where the actual compromise happens in 2026.

timeline title PSI and browser credential storage, 1986 to 2026 1986 : Meadows PSI : NRL matchmaking 1999 : Huberman-Franklin-Hogg : DH meet-in-the-middle 2003 : IKNP03 OT extension 2004 : FNP04 polynomial PSI 2015 : KOS15 active security 2016 : KKRT16 OPRF-PSI 2017 : CLR17 HE-PSI : Signal SGX contact discovery 2018 : CHLR18 Labeled PSI : HIBP v2 k-anonymity 2019 : Google Password Checkup : Silent OT 2021 : Edge Password Monitor ships : Cong et al. CCS 2021 2024 : Chrome App-Bound Encryption 2026 : Ronning EdgeSavedPasswordsDumper : Microsoft "by design"

To see why the two designs are not a contradiction, we need to understand how PSI got to be deployable at all -- a story that begins thirty-five years before Edge Password Monitor existed.

2. Why Private Set Intersection exists at all

Imagine two parties, neither of whom trusts the other. Alice has a set of identifiers; Bob has a set of identifiers. They want to learn which identifiers they share -- and only that. Each party wants to learn nothing about elements not in the intersection.

This is not an obvious problem to need a protocol for. If Alice and Bob trusted a third party, they would hand over their sets. If they trusted each other, they would compare directly. The problem only becomes interesting when neither assumption holds. The 2026 canonical version looks like this: Microsoft holds a curated set of roughly five billion breached credentials, and the user holds a few hundred passwords saved in their browser. The user wants to know which of their passwords appear in Microsoft's breach corpus -- and they want Microsoft to learn nothing about the passwords that do not. (Throughout this article the "five billion" figure is the author's 2026 forward projection of Microsoft's compromised-credential corpus; the contemporaneous Microsoft Research figure used in the 2021 Password Monitor announcement is four billion [@msr-password-monitor-2021], and the §3 sidenote spells out the inference.)

That framing did not exist in 1986. The original motivation was much weirder.

The 1986 paper

Catherine Meadows, then at the U.S. Naval Research Laboratory, published "A More Efficient Cryptographic Matchmaking Protocol for Use in the Absence of a Continuously Available Third Party" at the 1986 IEEE Symposium on Security and Privacy [@meadows-1986][@ieee-6234864]. The titular "matchmaking" problem was prosaic. Two parties want to learn whether they share an interest in some sensitive list -- classified-mailing-list membership, intelligence-source overlap, the everyday work of compartmented information systems -- without revealing anything else.

Meadows's protocol uses commutative encryption. Alice and Bob both raise the elements of their sets to private exponents over a Diffie-Hellman group. After two rounds, both parties hold the doubly-blinded versions of both sets. Equal underlying elements produce equal doubly-blinded values, because exponentiation in an Abelian group commutes. Unequal elements look like uniform-random group elements to both sides. The intersection comes out; the rest does not.

Meadows wrote this ten years before Diffie-Hellman key exchange shipped in SSL 3.0 (November 1996), the protocol family TLS would standardise in 1999 [@wikipedia-tls], and thirty-five years before her protocol's intellectual descendants would ship in a consumer browser.

The 1999 revival

The same protocol shape was rediscovered and given its modern formulation by Bernardo Huberman, Matthew Franklin, and Tad Hogg at Xerox PARC in 1999. Their paper "Enhancing Privacy and Trust in Electronic Communities" was published at the First ACM Conference on Electronic Commerce [@hfh-1999]. The motivations were online-community problems that look quaint today: which of your friends are on this matchmaking site, do we share interests on a sensitive bulletin board, can two early-internet communities establish trust without leaking their member lists. The protocol they wrote down -- usually called "DH meet-in-the-middle" or just "the Huberman-Franklin-Hogg protocol" -- is the canonical PSI shape every security engineer still reaches for first.The dblp BibTeX record gives the canonical DOI as 10.1145/336992.337012, which the ACM Digital Library 403s to most non-browser User-Agents. The dblp HTML mirror returns 200 and confirms the citation [@dblp-hfh].

What had to exist before

PSI predates breach checking by twenty years. The cryptographers who built PSI did not know they were building Edge Password Monitor. They were building a protocol primitive that happened, much later, to map cleanly onto a problem the world did not yet have.

The first such mapping landed in 2018 with HIBP's k-anonymity API and the cluster of academic and industry PSI deployments that followed [@hunt-pwned-v2-2018]. The primitive predated the killer application by two and a half decades. This is the normal shape of cryptographic engineering: the primitive sits on the shelf until the world needs it.

The DH meet-in-the-middle protocol is elegant. It is also catastrophically wrong for the breach-checking use case. To see why, we have to count exponentiations.

3. Early approaches: DH meet-in-the-middle and FNP04

Let us walk the DH meet-in-the-middle protocol step by step. Alice holds a set $S_A$. Bob holds a set $S_B$. Both parties agree on a Diffie-Hellman group $G$ of prime order $q$ with generator $g$, and on a cryptographic hash function $H: {0,1}^* \to G$ that maps set elements into the group. Alice picks a private exponent $a \in \mathbb{Z}_q$; Bob picks $b$.

The protocol proceeds in two rounds:

Alice computes ${H(x)^a : x \in S_A}$, shuffles, and sends to Bob.
Bob computes ${H(y)^b : y \in S_B}$, shuffles, and sends to Alice.
Alice exponentiates every value Bob sent her by $a$, producing ${H(y)^{ab} : y \in S_B}$. She sends this set back to Bob in the order Bob originally sent his ${H(y)^b}$, so Bob can index by his own set.
Bob exponentiates Alice's first-round values by $b$, producing ${H(x)^{ab} : x \in S_A}$. (In the symmetric variant Bob also sends his doubly-blinded set back to Alice; either side can then perform the match.)
Both parties now hold the same doubly-blinded set for both sides. Equal underlying elements collide; unequal ones do not. They intersect locally.

sequenceDiagram participant A as Alice (set S_A) participant B as Bob (set S_B) Note over A,B: shared group G, hash H, private exponents a (Alice), b (Bob) A->>B: shuffled set of H(x)^a for x in S_A B->>A: shuffled set of H(y)^b for y in S_B A->>A: compute H(y)^(ba) for each item from Bob B->>B: compute H(x)^(ab) for each item from Alice Note over A,B: equal underlying elements yield equal doubly-blinded values A->>B: ordered set of H(y)^(ab) for matching Note over A,B: intersection computed locally

Why this is right. Under the Decisional Diffie-Hellman (DDH) assumption in $G$, the doubly-blinded values $H(x)^{ab}$ for $x \notin S_A \cap S_B$ look uniformly random to the other side. Equal underlying elements collide; unequal underlying elements do not. The reader can verify this for themselves in the demonstration below, which is the canonical pedagogical version of the protocol.

{// Toy PSI -- pedagogical only, NOT secure (small modulus, weak hash). const p = 2n ** 61n - 1n; // Mersenne prime, small for demo const g = 37n; // generator over Z_p* (toy) const H = s => { // toy hash: deterministic map string -> [1, p-1] let h = 1469598103934665603n; for (const c of s) h = ((h ^ BigInt(c.charCodeAt(0))) * 1099511628211n) % p; return h === 0n ? 1n : h; }; const expMod = (base, exp, mod) => { let r = 1n, b = base % mod, e = exp; while (e > 0n) { if (e & 1n) r = (r * b) % mod; b = (b * b) % mod; e >>= 1n; } return r; }; const S_A = ["alice-at-example.com", "bob-at-example.com", "carol-at-example.com"]; const S_B = ["dave-at-example.com", "bob-at-example.com", "carol-at-example.com"]; const a = 0xC0FFEEn, b = 0xBADCAFEn; const A1 = S_A.map(x => expMod(H(x), a, p)); // Alice -> Bob const B1 = S_B.map(y => expMod(H(y), b, p)); // Bob -> Alice const A2 = A1.map(v => expMod(v, b, p)); // Bob blinds Alice's set const B2 = B1.map(v => expMod(v, a, p)); // Alice blinds Bob's set // Reveal intersection by matching doubly-blinded values const setA2 = new Set(A2.map(String)); const intersection = S_B.filter((_, i) => setA2.has(String(B2[i]))); console.log("Intersection:", intersection);}

The protocol does work. It gives semi-honest security under DDH and costs $O(|S_A| + |S_B|)$ group exponentiations per side, plus the same again to blind the received set. In a balanced setting -- two sets of similar size, perhaps a few thousand elements each -- it is genuinely deployable.

The three things that go wrong at scale

For breach checking, the protocol breaks in three documented ways.

Set-cardinality leakage. The shuffled lists Alice and Bob send each other have lengths $|S_A|$ and $|S_B|$. Bob learns precisely how many passwords Alice has saved; Alice learns precisely how big Bob's breach corpus is. The first leak is small but real; the second is fine when the server publishes its corpus size anyway (HIBP does), but the protocol does not hide it.

Online-cost asymmetry. The server pays $O(|S_B|)$ exponentiations per client query. At the five-billion-element scale of Microsoft's compromised-credential corpus, no realistic group exponentiation cost makes this feasible per query: even at 100 microseconds per exponentiation (optimistic for $|q| = 256$), five billion exponentiations is more than five days of single-core CPU. Sharding helps. Caching helps. Pre-computation helps. None makes the asymptotic curve workable as the corpus grows.

No labeled variant. The protocol returns set membership, not associated metadata. Edge Password Monitor wants to tell you "this credential appeared in breach X" -- so the protocol has to support associating a server-side label with each set element and returning the label for matched elements. DH meet-in-the-middle does not, without unpleasant extensions.

FNP04: the right idea, wrong substrate

The algebraic alternative arrived in 2004 with Freedman, Nissim, and Pinkas's "Efficient Private Matching and Set Intersection" at EUROCRYPT [@fnp-2004]. The idea is gorgeous. Alice encodes her set $S_A = {x_1, \dots, x_n}$ as the polynomial whose roots are her set:

$$p(z) = \prod_{i=1}^{n} (z - x_i)$$

Alice encrypts each coefficient of $p$ under an additively-homomorphic encryption scheme (Paillier, in the paper). She sends the encrypted coefficients to Bob. Bob homomorphically evaluates $p(y)$ for every element $y$ of his set $S_B$ and returns the encrypted results. If $y \in S_A$, then $p(y) = 0$, and after decryption Alice sees a zero in the corresponding position. If $y \notin S_A$, then $p(y)$ is a non-trivial polynomial evaluation that, randomized correctly, decrypts to a uniform value Alice cannot interpret.

This is the first asymmetric PSI -- the first protocol where one party can do most of the work while the other sends only a small encrypted query. It is also, in deployment terms, structurally infeasible at scale. Paillier ciphertexts live in $\mathbb{Z}^*_{n^2}$ and are $2 \cdot |n|$ bits each [@paillier-1999] (2048 bits for FNP04's $|n| = 1024$ default; 4096 bits for the $|n| \geq 2048$ that modern security demands). Paillier homomorphic evaluation needs full-size modular exponentiation per coefficient, and the server compute scales as $O(|S_A| \cdot |S_B|)$. At Edge Password Monitor's target scale -- a client set of a few hundred passwords against a five-billion-element server corpus -- a single query would take minutes to hours of server compute and tens of megabytes of round-trip data per query.The 5-billion-element estimate is INFERRED, not measured (see §2 for the article-wide projection disclosure). No published source benchmarks FNP04 at that scale; the inference combines the $O(|S_A| \cdot |S_B|)$ asymptotic with measured Paillier throughput on commodity hardware. The order-of-magnitude conclusion is sound; treat the precise number as a back-of-envelope.The polynomial-roots idea is not dead. Thirteen years later, Chen, Laine, and Rindal will revive exactly this construction inside CLR17 [@clr-2017], with Paillier replaced by BFV-style somewhat-homomorphic encryption and a partition-and-evaluate trick that fixes the $O(|S_A| \cdot |S_B|)$ blow-up. The structure survives; the substrate gets swapped.

Protocol	Era	Server cost	Communication	Verdict at 5B-element scale
DH meet-in-the-middle [@hfh-1999]	1999	$O(	S_B	)$ DH exponentiations
FNP04 [@fnp-2004]	2004	$O(	S_A	\cdot
(preview) HE-PSI on BFV [@clr-2017]	2017	$O(	S_B	\log

Note: The naive approach -- "just hash and compare" -- leaks set cardinality at a minimum, and plain hashing is brute-forceable against any password the server can guess. Doing PSI properly under encryption requires either $O(|S_A| \cdot |S_B|)$ server work and 2048-bit Paillier ciphertexts (FNP04, dead at billions), or a new primitive: oblivious transfer at scale. It takes a decade of engineering to make that primitive free.

FNP04's polynomial idea will turn out to be the right idea -- but only after we replace Paillier with somewhat-homomorphic encryption thirteen years later. Before we can get there, we need a different breakthrough: making the underlying oblivious-transfer primitive cheap enough that every PSI in the literature can ride on it.

4. The evolution: oblivious transfer extension

Here is the central fact that drove a decade of cryptographic engineering: every PSI protocol that scales eventually reduces to "many oblivious transfers." OT is the universal building block. Once you can do millions of OTs per second, you can do nearly any two-party secure computation, including PSI. The question is how cheap "many OTs" can become.

A two-party primitive. In 1-out-of-2 OT, the sender holds two messages $(m_0, m_1)$, the receiver chooses a bit $b$, and after the protocol runs the receiver learns $m_b$ while the sender learns nothing about $b$. OT is universal -- it suffices for secure two-party computation of any function -- and it is also expensive: implemented directly from public-key primitives, each OT costs at least one Diffie-Hellman exponentiation, on the order of a millisecond per OT on commodity hardware. A two-phase protocol that performs $m$ OTs at the cost of $\kappa$ "base" OTs (typically $\kappa = 128$, implemented with public-key crypto) plus $O(m)$ symmetric primitive calls. Because $\kappa$ is small and constant, the per-OT cost drops from public-key cost (~1 ms) to symmetric-crypto cost (~100 ns) -- roughly three orders of magnitude, and the asymptotic gap widens with $m$.

Generation 1: IKNP03

In 2003, Yuval Ishai, Joe Kilian, Kobbi Nissim, and Erez Petrank published "Extending Oblivious Transfers Efficiently" at CRYPTO 2003 [@iknp-2003].

Ishai and Petrank are at Technion; Kilian and Nissim were at NEC Labs America at the time. The construction is short enough to summarize in one paragraph and important enough to be called the OT extension: start with $\kappa$ "base" OTs done the expensive way (one public-key operation each), then use them to seed pseudorandom generators and a clever transposition trick that, with $O(m)$ hash-function calls, produces $m$ effective OTs. The base cost stays fixed at $\kappa$ public-key operations; the per-OT marginal cost collapses to a few hash invocations.

The numerical impact: before IKNP, secure-computation researchers cited oblivious-transfer cost in milliseconds; after IKNP, in hundreds of nanoseconds. Three orders of magnitude is the difference between "research artifact" and "this protocol can ship."No IACR ePrint preprint existed at publication time; a post-conference upload appeared in 2008 as ePrint 2008/508. ePrint 2003/052 is a different paper (Klima, Pokorny, Rosa). The Springer LNCS chapter [@iknp-2003] is the canonical reference.

Generation 2: KOS15

IKNP03 is secure against a semi-honest adversary -- one who follows the protocol but tries to learn extra information from the transcript. Real-world deployments often need active security: protection against an adversary who deviates to extract information or bias the output.

In 2015, Marcel Keller, Emmanuela Orsini, and Peter Scholl published "Actively Secure OT Extension with Optimal Overhead" [@kos-2015]. The construction adds a correlation-check phase on top of IKNP03 that catches active deviations with overwhelming probability. The paper's own abstract: "no more than 5% more time than the passively secure IKNP extension, in both LAN and WAN environments, and thus is essentially optimal with respect to the passive protocol." Modern implementations (libOTe, EMP-toolkit, MP-SPDZ) report on the order of 10-20% wall-clock overhead and 5-10% communication overhead over semi-honest IKNP03 in production -- the "optimal overhead" in the title is the claim that this margin vanishes as the OT count grows.

After KOS15, "active security is free" became the industry default. Every modern OT-extension library -- libOTe, EMP-toolkit, MP-SPDZ -- ships KOS15 (or a close variant) as the production-grade default. The earlier semi-honest-only choice is a research artifact.

Generation 3: Silent OT

In 2019, a six-author collaboration -- Elette Boyle, Geoffroy Couteau, Niv Gilboa, Yuval Ishai, Lisa Kohl, and Peter Scholl -- published "Efficient Pseudorandom Correlation Generators: Silent OT Extension and More" at CRYPTO 2019 [@silent-ot-2019]. The construction replaces the communication-heavy IKNP/KOS phase with a Pseudorandom Correlation Generator (PCG): the two parties exchange a few-kilobyte seed and locally expand it into millions of correlated OTs.

A protocol primitive that, given a short shared seed, lets two parties locally expand the seed into long correlated random strings -- in the OT case, the random correlations needed to "consume" each OT call. Once the seed is exchanged, no further communication is needed to produce more OTs; the parties simply expand more locally. PCGs reduce the per-OT wire cost to zero in the post-seed phase.

The numerical impact this time is bandwidth. Pre-Silent-OT, OT-extension protocols sent on the order of $\kappa$ bits per OT. Silent OT sends a polylogarithmic amount of data total for the entire extension. The precursor construction "Compressing Vector OLE" by Boyle, Couteau, Gilboa, Ishai, Kohl, and Rindal [@boyle-vector-ole-2019] laid the algebraic foundation.

For Edge Password Monitor's deployment shape (small client set, large server set), Silent OT does not land in the production protocol -- HE-PSI provides the asymmetric communication scaling -- but its existence in 2019 is part of why the industry treats OT extension as essentially solved engineering and feels free to ride a higher-layer protocol on top.

The OPRF-PSI plateau: KKRT16

Pure OT-extension is one substrate; the other is the Oblivious Pseudorandom Function.

A two-party protocol in which the sender holds a key $k$, the receiver holds an input $x$, and after the protocol the receiver learns $F_k(x)$ while the sender learns nothing about $x$. The receiver gets the PRF output without giving up the input; the sender keeps the key without giving up the output. OPRFs are the building block under most modern PSI: each party evaluates the OPRF on their set, then plaintext-compares the outputs.

In 2016, Vladimir Kolesnikov, Ranjit Kumaresan, Mike Rosulek, and Ni Trieu published "Efficient Batched Oblivious PRF with Applications to Private Set Intersection" at CCS 2016 [@kkrt-2016]. The paper builds a batched OPRF directly on top of KOS-style OT extension. The reported benchmark: intersecting two $2^{20}$-element sets on a LAN took about 3.8 seconds total. For several years, KKRT16 was the deployment-grade symmetric-PSI protocol.

KKRT16 is great if your two sets are roughly the same size. The Edge Password Monitor problem is fundamentally asymmetric -- the client holds a few hundred saved passwords, the server holds billions of breached credentials. For asymmetric PSI, the OT-extension lineage hits a wall the next generation has to climb.

flowchart LR A["Kappa base OTs
(public-key)"] --> B["IKNP03 extension
(symmetric)"] B --> C["KOS15 active security"] C --> D["Silent OT
(PCG-based)"] B --> E["KKRT16 OPRF-PSI"] C --> F["CHLR18 HE-PSI
+ OPRF wrapping"] D --> G["Modern OT-extension libraries:
libOTe, EMP-toolkit"] E --> H["Symmetric balanced PSI"] F --> I["Edge Password Monitor"]

5. The breakthrough: HE-based PSI

Asymmetric PSI requires that the server's heavy compute stays on the server, and that the client send only a tiny encrypted query whose size is independent of $|S_B|$. That is exactly what fully homomorphic encryption -- or, more precisely, somewhat-homomorphic encryption -- can offer.

An encryption scheme is *homomorphic* if operations on ciphertexts decrypt to the corresponding operations on plaintexts. *Somewhat-homomorphic encryption* (SWHE) supports a bounded depth of operations (typically additions and multiplications) before noise growth requires re-encryption. *Fully homomorphic encryption* (FHE) supports arbitrary-depth circuits via bootstrapping. The BFV scheme (Brakerski-Fan-Vercauteren), implemented in Microsoft SEAL [@ms-seal], is the SWHE variant Edge Password Monitor uses; FHE is the popular term but the actual deployed circuit depth fits comfortably within SWHE.

CLR17: the cost curve flips

In 2017, Hao Chen, Kim Laine, and Peter Rindal published "Fast Private Set Intersection from Homomorphic Encryption" at CCS 2017 [@clr-2017]. The construction is a clean revival of FNP04's polynomial-roots idea, with three engineering moves that fix every reason FNP04 was infeasible.Move 1: SWHE instead of Paillier. BFV ciphertexts pack many plaintext slots and support SIMD-style homomorphic operations. A single ciphertext can encrypt and evaluate over thousands of plaintext values in parallel; the slot count is set at scheme-parameter time.

Move 2: Cuckoo hash partitioning. The receiver Cuckoo-hashes its set $S_R$ into bins. The sender hashes each element of $S_S$ to the same set of bins. Instead of one giant polynomial whose roots are all of $S_S$, the sender builds one small polynomial per bin -- typically a few thousand bins, each holding a few hundred elements.

A hashing scheme that uses $k$ hash functions and inserts each element into one of $k$ candidate bins, displacing existing occupants if necessary (the displaced element finds another of its candidate bins). Cuckoo hashing achieves $O(1)$ worst-case lookup; the achievable load factor depends on the number of hash functions and the bucket size -- roughly 49% with $k=2$ (the original Pagh-Rodler 2001 construction [@pagh-rodler-2001]), roughly 91% with $k=3$, and higher with a stash of evicted elements or $k \geq 4$. CLR17 and CHLR18 use parameter choices in the high-load regime. In CLR17, Cuckoo hashing pairs the receiver's set with the sender's set so that two equal elements end up in the same bin with overwhelming probability.

Move 3: Partition-and-evaluate. The receiver encrypts its bins under BFV and sends them. The sender homomorphically evaluates its per-bin polynomial at the encrypted receiver's bin. Because of SIMD slot packing, each bin's polynomial is evaluated in parallel across all slots, and the sender's total work is $O(|S_S| \log |S_R|)$ FHE operations instead of FNP04's $O(|S_R| \cdot |S_S|)$.

The headline benchmark from the paper, on the MSR publication page: "36 seconds of online-computation and 12.5 MB of round trip communication to intersect five thousand 32-bit strings with 16 million 32-bit strings" [@msr-clr17-pub]. Communication scales linearly in the small set and logarithmically in the large set. The cost curve is finally right.

sequenceDiagram participant C as Client (Edge) participant S as Server (Microsoft) Note over C,S: stage 1 -- OPRF preprocessing (binds queries to server's secret key) C->>S: blinded credential beta * H(cred) S->>C: alpha * (blinded H(cred)) using server key alpha C->>C: unblind, obtain F_alpha(cred) Note over C,S: stage 2 -- HE-PSI on sharded corpus C->>S: BFV ciphertext encrypting F_alpha(cred), sharded by 2-byte prefix S->>S: Cuckoo-hash shard, evaluate per-bin polynomial homomorphically S->>C: encrypted match result + label ciphertext C->>C: decrypt result, then if match surface breach metadata

CHLR18: labeled, malicious, deployable

The next year, the same authors plus Zhicong Huang published "Labeled PSI from Fully Homomorphic Encryption with Malicious Security" at CCS 2018 [@chlr-2018]. The paper adds three production-grade properties.

Labels. Each element in the server's set can carry an associated label (which breach, when, severity). When the receiver finds a match, they also recover the label.

Malicious security. The protocol is secure against an actively malicious sender, layered on top of the underlying semi-honest construction via an OPRF preprocessing step. The OPRF is the same primitive we met in §4; here it does double duty: it prevents the client from brute-forcing the server's corpus offline (the client cannot evaluate $F_k(\cdot)$ without server interaction) and provides the malicious-security guarantee.

Arbitrary-length items. The protocol handles long inputs (full URLs plus usernames, in the breach-checking case), not just short fixed-width keys.

The headline benchmark: "for an intersection of $2^{20}$ and 512 size sets of arbitrary length items our protocol has a total online running time of just 1 second (single thread), and a total communication cost of 4 MB" [@msr-chlr18-pub]. A larger benchmark of $2^{28}$ and 1024 takes 12 seconds multithreaded with less than 18 MB of communication.

Cong et al. 2021: the production-grade successor

The protocol that ships in Edge Password Monitor today is the descendant published by Kelong Cong, Radames Cruz Moreno, Mariana Botelho da Gama, Wei Dai, Ilia Iliashenko, Kim Laine, and Michael Rosenberg at CCS 2021: "Labeled PSI from Homomorphic Encryption with Reduced Computation and Communication" [@cong-2021]. The paper is the basis for Microsoft's open-source APSI library [@ms-apsi], whose README states verbatim that it "provides a PSI functionality for asymmetric set sizes based on the protocol described in eprint.iacr.org/2021/1116" and that it "uses the BFV encryption scheme implemented in the Microsoft SEAL library."The Cong et al. 2021 byline is seven authors: Kelong Cong, Radames Cruz Moreno, Mariana Botelho da Gama, Wei Dai, Ilia Iliashenko, Kim Laine, Michael Rosenberg. Some upstream reporting conflates a different author list onto the same URL; the citation_author meta-tags returned by ePrint 2021/1116 confirm this seven-author septuple [@cong-2021].

The OPRF wrapping and corpus sharding

Two practical layers on top of the bare HE-PSI protocol turn the academic construction into a production deployment, and the Microsoft Research Password Monitor blog is explicit about both [@msr-password-monitor-2021].

First, the OPRF preprocessing. Without it, a malicious client could send candidate passwords one at a time and observe match results, brute-forcing the server's corpus. With it, every client query passes through $F_k(\cdot)$ where $k$ is a server secret. The MSR blog states: "the client communicates with the server to obtain a hash $H$ of the credential, where $H$ denotes a hash function that only the server knows... using an OPRF... the client is prevented from performing an efficient dictionary attack on the server" [@msr-password-monitor-2021].

Second, corpus sharding. The MSR blog notes that the corpus is sharded by the first two bytes of a username-hash. The blog's verbatim example: "Suppose the database $D$ consists of 4 billion credentials, then after sharding each subset, it will contain about 60,000 credentials on average." At the article's 2026 5-billion projection the math is the same -- corpus divided by $2^{16}$ -- and per-shard work is closer to 76,000 credentials. Either way, the per-query homomorphic evaluation runs against tens of thousands of credentials instead of the full corpus. This is the same engineering trade as Apple's 15-bit bucketing -- a small information leak (the client reveals which shard their query lives in) in exchange for tractable per-query compute.

A Windows facility, introduced in Windows 2000, that encrypts arbitrary blobs under a user-derived key chain (ultimately rooted in the user's password, with hardware-bound variants under DPAPI-NG) and exposes a simple `CryptProtectData` / `CryptUnprotectData` API [@ms-learn-dpapi-ng]. Browsers including Chromium store the symmetric key that wraps their saved-password database under DPAPI at rest. This protects the on-disk database when the user is not logged in, but it does not protect process memory after the same user has unwrapped the data into a running browser. This unique security feature is possible due to pioneering cryptography research and technology incubation done here at Microsoft Research. -- Microsoft Research, January 21, 2021 [@msr-password-monitor-2021]

The administrator-visible group policy that controls this feature is PasswordMonitorAllowed, documented on Microsoft Learn [@ms-learn-edge-pm].

Key idea: Asymmetric PSI on somewhat-homomorphic encryption flips the cost curve so that communication scales with the small client set, not the enormous server set. That is why a homomorphic-encryption protocol can ship on a consumer browser in 2021 without melting the user's CPU. The cryptographic case for Edge Password Monitor is auditable down to the published papers and unequivocally well-engineered.

Microsoft has shipped the first production consumer homomorphic-encryption deployment in a browser, against the threat "server-side breach corpus leakage," on the same browser that, in §7, will turn out to hold every saved credential in plaintext RAM the entire time you have it open. To make sense of that contrast, we need to see what the rest of the industry did with the same problem.

6. State of the art: four deployed compromised-credential services

PSI on paper is one thing. PSI in production is another. The "pure PSI" ideal -- both parties learn the intersection and nothing else, no information leaks on either side -- is impractical at planetary scale. Every deployed compromised-credential service in 2026 makes a concession somewhere.

Note: The concessions reveal which threats each provider takes most seriously. Read the next table by column 3 ("what is revealed on the wire") and column 6 ("dictionary-attack hardening") side by side: that pair tells you the threat model each provider chose.

The four services compared here are HIBP Pwned Passwords v3, Google Password Checkup, Apple Password Monitoring (iCloud Keychain), and Microsoft Edge Password Monitor. A fifth, Signal contact discovery, is technically a contact-discovery service rather than a breach checker, but it sits on the same protocol map and is the canonical "we used a TEE instead of pure crypto" data point.

Service	Protocol family	What's revealed on the wire	Server trust	Bandwidth at scale	Dictionary-attack hardening
HIBP Pwned Passwords v3 [@hibp-api-v3]	Pure SHA-1 5-hex-char k-anonymity	A 20-bit hash prefix per query	None (zero-trust API)	Trivial (a few KB per query)	None on the wire; SHA-1 hash makes corpus searchable
Google Password Checkup [@thomas-usenix-2019]	k-anonymity + blinded-hash OPRF	A small hash prefix per query	Honest-but-curious	Tens of KB per query	OPRF prevents corpus enumeration by the client
Apple Password Monitoring [@apple-password-monitoring]	EC-based PSM on NIST P-256 + 15-bit bucket	A 15-bit prefix + double-blinded EC point	Honest-but-curious	A few hundred KB per query (padded)	OPRF + double-blinding + padding-to-fixed-count
Signal contact discovery (2017) [@signal-private-contact-2017]	SGX enclave + ORAM (no pure crypto)	Nothing visible to Signal staff	TEE attestation	Negligible (single SGX RPC)	Enclave isolation rather than crypto hardening
Microsoft Edge Password Monitor [@msr-password-monitor-2021]	HE-PSI on Microsoft SEAL + OPRF + 2-byte shard	2-byte username-hash prefix + BFV ciphertext	Honest-but-curious	Single MB-range round trip	OPRF binds queries to server key; HE prevents transcript leaks

HIBP Pwned Passwords v3: the k-anonymity baseline

Troy Hunt launched Pwned Passwords v2 in 2018 with the help of Junade Ali at Cloudflare, adding a k-anonymity API; the design is published in two posts, Hunt's "I've Just Launched Pwned Passwords Version 2" and Ali's "Validating Leaked Passwords with k-Anonymity" [@hunt-pwned-v2-2018][@ali-cloudflare-2018]. The protocol is delightfully simple: the client hashes the candidate password under SHA-1, sends the first 5 hex characters (20 bits) of the hash to the API, and the API returns every suffix in that bucket. The client compares locally.

A privacy property: each query produces output that is consistent with at least $k$ other potential queries the client could have made. In the HIBP context, $k$ is the number of distinct password hashes that share the same 20-bit SHA-1 prefix -- typically a few hundred. The server learns the bucket but not which specific password the client cares about, and (because hashes are sparse over the prefix space) cannot easily distinguish "the user has password X" from "the user has password Y" if X and Y share the prefix.

The HIBP corpus serves "18B+ Monthly Requests" against roughly a billion hashes [@hibp-passwords]. Operationally, this is a one-shot HTTP GET. There is no PSI on the wire beyond TLS. The whole protocol fits on the back of an envelope. The cost: each query leaks the 20-bit prefix, which is enough to identify the user's password if the attacker has independent information narrowing the candidate space.

{async function sha1Hex(s) { const buf = new TextEncoder().encode(s); const hash = await crypto.subtle.digest("SHA-1", buf); return [...new Uint8Array(hash)].map(b => b.toString(16).padStart(2, "0")).join("").toUpperCase(); } async function showBucket(password) { const h = await sha1Hex(password); const prefix = h.slice(0, 5); // 5 hex chars -- 20 bits sent to server const suffix = h.slice(5); console.log("Password:", password); console.log("SHA-1: ", h); console.log("Prefix (leaves your device):", prefix); console.log("Suffix (compared locally): ", suffix); console.log("Approx bucket size: ~", Math.round(847_223_402 / (1<<20)), "entries"); } showBucket("hunter2");}

The mental model the runnable above gives is the precise shape of the trade. Every HIBP query says "I am asking about a password whose SHA-1 starts with these 20 bits." There are roughly $2^{20} \approx 1{,}048{,}576$ possible prefixes, so each query narrows the server's posterior over your password by exactly that much.

Google Password Checkup: k-anonymity with an OPRF on top

In August 2019, Kurt Thomas and colleagues at Google published "Protecting Accounts from Credential Stuffing with Password Breach Alerting" at USENIX Security [@thomas-usenix-2019]. The accompanying blog post on the Google Security Blog announces the deployment [@google-blog-password-checkup-2019]. The numbers are familiar at this point: "a cloud service that mediates access to over 4 billion credentials found in breaches and a Chrome extension serving as an initial client. Based on anonymous telemetry from nearly 670,000 users and 21 million logins, we find that 1.5% of logins on the web involve breached credentials" [@thomas-usenix-2019].

The protocol upgrades HIBP's k-anonymity baseline with an OPRF preprocessing round: instead of hashing under SHA-1 locally and sending the prefix, the client first obtains $F_k(\text{password})$ via an OPRF interaction, where $k$ is a Google-held key. The OPRF output is then bucketed and matched against Google's corpus. The OPRF prevents the client from enumerating Google's corpus offline; the bucketing limits per-query server work.

Apple Password Monitoring: PSM with double-blinding

Apple's protocol is the most cryptographically elaborate of the four. The Apple Platform Security guide is unusually explicit [@apple-password-monitoring][@apple-security-guide-pdf]. From the guide, verbatim: "a form of cryptographic private set intersection is deployed that compares the users' passwords against a large set of leaked passwords"; the corpus is "approximately 1.5 billion passwords... into $2^{15}$ different buckets"; and the protocol uses elliptic-curve PSM on NIST P-256 with a double-blinded structure.

The math, slightly compressed. Let $H_{\text{SWU}}$ be the Shallue-van de Woestijne-Ulas hash-to-curve.

Google publishes an open-source PSM construction at google/private-membership [@google-private-membership-github]; Apple's protocol shares the EC double-blinding skeleton. Apple computes a per-corpus-element representation:

$$P_{pw} = \alpha \cdot H_{\text{SWU}}(pw)$$

where $\alpha$ is a secret random key known only to Apple. The client computes its query:

$$P_c = \beta \cdot H_{\text{SWU}}(pw)$$

with $\beta$ chosen randomly per-query. The interaction lets the client recover $\alpha \cdot H_{\text{SWU}}(pw)$ and check it against a 15-bit bucket of $P_{pw}$ values. (Apple's public documentation hashes only the password; whether the production implementation includes additional salting is not disclosed.) The double-blinding is the point: $\alpha$ stays Apple's secret (so the client cannot enumerate); $\beta$ stays per-query random (so Apple cannot link two queries from the same client).Apple's PSM defends also against the server learning how many unique passwords a user has, by padding-to-fixed-count with random queries: "if a user has fewer than this number, random passwords are generated and added to the queries to make up the difference" [@apple-password-monitoring]. None of the other four services deploys this defence. The padding cost is the price.

Signal contact discovery: the TEE outlier

In September 2017, Moxie Marlinspike published "Technology Preview: Private Contact Discovery" on Signal's blog [@signal-private-contact-2017]. The post is candid about the cost calculation that drove Signal toward Intel SGX rather than pure cryptographic PSI:

Signal clients will be able to efficiently and scalably determine whether the contacts in their address book are Signal users *without revealing the contacts in their address book to the Signal service*. -- Moxie Marlinspike, September 2017 [@signal-private-contact-2017]

Marlinspike is explicit about the cost calculation: "Doing better is difficult. There are a range of options that don't work... like using bloom filters, encrypted bloom filters, sharded bloom filters." Signal examines pure cryptographic PSI and decides, given its scale and latency requirements, that an SGX enclave running a constant-time ORAM-protected lookup is the better engineering trade [@signal-cds-github].

The SGX choice came with side-channel debt that subsequent literature made expensive. Foreshadow (2018) [@foreshadow-2018], SgxPectre (2018) [@sgxpectre-2018], SGAxe (2020) [@sgaxe-2020], and AEPIC Leak (2022) [@aepic-leak-2022] all targeted SGX directly. Each disclosure prompted Signal to publish a re-evaluation. Signal eventually migrated to the second-generation Contact Discovery Service (CDSI), which continues to rely on TEEs but with a hardened threat model. The point for our story is not that SGX is bad. It is that "pure crypto vs. TEE" is not a settled question; every provider revisits it under their own latency, corpus, and threat-model constraints, and each makes a different decision.

Microsoft Edge Password Monitor

The Microsoft deployment is the only one shipping a full HE-PSI protocol on the wire against the full corpus. As established in §5, the protocol stack is:

Two-byte username-hash shard selection (corpus partitioned, sender does work only against tens of thousands of elements per query -- the MSR blog's 2021 example uses 4 billion / $2^{16} \approx$ 60,000; the article's 2026 5-billion projection yields $\approx$ 76,000).
OPRF preprocessing (binds queries to a server secret; prevents client-side enumeration).
BFV-encrypted query, evaluated against the Cuckoo-hashed per-bin polynomials, returned as a single ciphertext per shard.
Client decrypts; if matched, decrypts the associated label (the breach metadata).

All four moving parts are described in the MSR blog, the Cong et al. 2021 paper, and the open-source APSI library [@msr-password-monitor-2021][@cong-2021][@ms-apsi]. Communication scales with the small client set; sender compute scales with the (sharded) server set. The Microsoft Edge enterprise documentation says the feature "helps Microsoft Edge users protect their online accounts by informing them if any of their passwords are found in an online leak" [@ms-learn-edge-pm].

Four products, four concessions

Service	Primary concession	What it defends against	What it does not
HIBP	20-bit prefix leak per query	Server learning the password	A linkage attack on repeated queries
Google PCU	OPRF transcript + prefix	Client-side corpus enumeration	Server-side query inference if the prefix is rare
Apple PSM	15-bit bucket + double-blinding overhead	Both client and server enumeration; query linkage	Side-channels on the EC implementation
Signal CDS	TEE attestation trust	Server-side mass-data exfiltration	SGX side-channel attacks
Edge PM	2-byte shard leak + OPRF transcript	Anything short of breach corpus leakage from inside Microsoft	Endpoint compromise -- see §7

Four products. Four different concessions. Each is internally coherent. None of them solves a problem that Tom Joran Sonstebyseter Ronning's PoC will turn out to make trivial.

7. The other half: plaintext RAM "by design"

Now we turn the article inside out.

Everything we have built so far -- IKNP, KOS, KKRT, CLR17, CHLR18, Cong et al., Apple's PSM, Google's k-anonymity wrapping, the entire CCS-grade cryptographic stack inside Edge -- assumes the endpoint is trustworthy. The question Ronning asked on May 4, 2026 is what happens when it is not.

The disclosure

The X post arrived at 14:29:51 UTC on May 4, 2026 [@ronning-x]: "Microsoft Edge loads all your saved passwords into memory in cleartext -- even when you're not using them." Five hours later the GitHub repository went public, with a complete C# proof-of-concept and a long README [@ronning-github]. PCWorld picked up the story two days later under the byline of Laura Pippig, summarising Microsoft's response in English [@pcworld-pippig-2026]. The Norwegian origin, ITavisen, carried the verbatim "by design" rendering and named Ronning's affiliation with the transmission-system operator Statnett [@itavisen-2026]. Davey Winder at Forbes reached Microsoft and obtained the official spokesperson statement on May 6, 2026 [@forbes-winder].Ronning works at Statnett and presented this finding at BigBiteOfTech (Palo Alto Networks Norway) on April 29, 2026 -- five days before the public X-post disclosure [@itavisen-2026]. The X bio describes "#PenetrationTesting using only tools that are already on the system."

What the PoC does

The C# program is short. OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, ...) against the parent msedge.exe. A walk over committed memory regions via VirtualQueryEx. ReadProcessMemory reads of every region. Pattern matching for stored credential structures. Output: every saved Edge password as plaintext.

The README is explicit on the constraints. "Can be run without Adminstrator rights, but will only be able to access Edge processes ran by the same user. If run with Administrator privileges, the program can access and read memory from other users' Edge processes on the same machine" [@ronning-github]. No kernel exploit. No DPAPI bypass. The DPAPI unwrap happened earlier, when Edge launched (or when the password feature first activated); the cleartext has been sitting in msedge.exe's heap ever since.

The tested target is Edge 147.0.3912.98, but the README explicitly generalises: "Any Edge versions that's Chromium based (from version 79 and newer, including 147.0.3912.98 and any future version, as Microsoft won't change this feature)" [@ronning-github].

What the architectural choice is

The behaviour Ronning identifies is not a memory-safety bug. It is a design choice: Edge unwraps every DPAPI-protected saved credential into process memory when the password manager activates, and keeps the plaintext resident for the lifetime of the session.

flowchart TD A["Saved password file
(SQLite blob)"] -->|"DPAPI-wrapped at rest"| B["Disk: encrypted with
per-user DPAPI key"] B -->|"msedge.exe launches"| C["DPAPI CryptUnprotectData()
unwraps key"] C -->|"password manager activates"| D["Plaintext credentials
resident in msedge.exe heap"] D -->|"OpenProcess + ReadProcessMemory
(same-user, no admin)"| E["EdgeSavedPasswordsDumper
reads cleartext"] D -->|"autofill flow"| F["Plaintext copied into
renderer / web form"] classDef warn fill:#7a3030,stroke:#a04848,color:#fce8e8 class D warn,stroke:#c33 classDef accent fill:#5d3a5d,stroke:#8a5a8a,color:#fde0fd class E accent,stroke:#939

Chrome and Brave do not do this. Both browsers decrypt credentials only at the autofill RPC -- the password manager fetches the DPAPI-wrapped blob, decrypts in a narrow window, hands the plaintext to the relevant renderer, and zeroes the buffer [@chromium-os-crypt]. PCWorld corroborates: "Other password managers, including those that are built into browsers, don't operate in this way -- Ronning says Edge is the only Chromium-based browser he's tested with this behavior" [@pcworld-pippig-2026].

In July 2024, Google announced Chrome App-Bound Encryption -- a further hardening of exactly this same-user-LCE threat model. ABE binds the on-disk key unwrap to a verified Chrome process identity, so a malicious program impersonating Chrome cannot ask DPAPI to unwrap Chrome's data even if it runs as the same user [@google-chrome-abe-2024]. Microsoft has the same DPAPI substrate; Edge has not adopted the equivalent control.

The .NET runtime tie-in to AMSI

The PoC's original implementation language is a noteworthy detail. Ronning's README states: ".NET Framework 4.8.1 (changed from 3.5 originally)" [@ronning-github]. The original .NET 3.5 choice was deliberate. The Antimalware Scan Interface (AMSI) [@ms-amsi-portal] scans .NET 4.8+ assemblies before execution; .NET 3.5 predates AMSI's Amsi* API surface entirely [@ms-amsi-dotnet48].The current GitHub README has changed the framework version to .NET 4.8.1 (likely to ensure the PoC runs out-of-the-box on modern Windows), but the original framing -- and the original threat-model point -- was the AMSI evasion that .NET 3.5 enables. The sibling AMSI post in this series explains why the 3.5 framing matters.

Microsoft's response, verbatim

Safety and security are foundational to Microsoft Edge. Access to browser data as described in the reported scenario would require the device to already be compromised. Design choices in this area involve balancing performance, usability, and security, and we continue to review it against evolving threats. Browsers access password data in memory to help users sign in quickly and securely -- this is an expected feature of the application. We recommend users install the latest security updates and antivirus software to help protect against security threats. -- Microsoft spokesperson, via Forbes, May 6, 2026 [@forbes-winder] The statement is technically defensible. The threat model is exactly what the spokesperson says: an attacker who can already execute code as the user on the user's machine. In MSRC's published servicing criteria [@msrc-servicing-criteria], "exploitation requires local code execution" is a recurring boundary line -- the same line MSRC applied to Mimikatz against LSASS in the pre-Credential-Guard era, and that Microsoft eventually crossed by shipping [Credential Guard](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/). The "by design" framing is consistent with a decade of precedent. Microsoft's response is internally consistent with a decade of MSRC policy. The "exploitation requires local code execution" framing was applied to Mimikatz against LSASS for years before Credential Guard arrived. It is applied to "give me a debugger and I can read anything" type attacks generally. The position is not improvised, and it is not a special accommodation for Edge. The question this article asks is not "is the position internally consistent" -- it is -- but "what threat model does the position concede." The answer is the same-user local-code-execution threat model. Whether the concession is acceptable depends on whether the user's environment makes same-user LCE rare (a single-user Surface) or routine (a Citrix farm, an AVD pool, a shared family computer).

Note: If you operate a multi-user Windows host -- RDS, AVD, Citrix, a shared lab, a family PC with multiple sign-in accounts -- every Edge session's saved credentials are recoverable by any same-user process during that session, and by an administrator across sessions. The "the device is already compromised" framing is asymmetric: a same-user LCE event on a multi-user host is structurally more common than on a single-user laptop, because there are more identities sharing the same physical machine.

Key idea: Edge does not have a credential-storage vulnerability. Edge has a credential-storage architectural choice. The choice is to spend the entire browser session's worth of plaintext-in-RAM budget on autofill UX latency. The choice is defensible. It is also a precise statement of which threats the Edge product team is and is not defending against.

Microsoft's response is technically defensible. It is also a precise statement of which threat model the Edge product team is and is not defending against. To see why both halves of this article describe the same product, we need to look at the architectural alternatives.

8. Competing approaches: where should the secret store live?

Three architectural positions present themselves, as siblings rather than as a generational ladder:

Browser-as-secret-store, decrypt-on-launch (Edge today). Plaintext-in-RAM window: the entire session. Autofill latency: a memcpy.
Browser-as-secret-store, decrypt-on-autofill (Chrome, Brave). Plaintext-in-RAM window: the autofill RPC. Autofill latency: one DPAPI unwrap per fill (microseconds).
OS-as-secret-broker (the design the Windows Credential Manager and DPAPI-NG already implement for native apps). Plaintext never crosses into the browser's process; a higher-privileged broker holds the plaintext at autofill time and the browser receives a handle, not the secret.

flowchart LR subgraph "Decrypt-on-launch (Edge)" A1[Disk: DPAPI blob] --> A2[Browser process
plaintext, full session] A2 --> A3[Renderer: autofill memcpy] end subgraph "Decrypt-on-autofill (Chrome / Brave)" B1[Disk: DPAPI blob] --> B2[Browser process
plaintext, narrow RPC] B2 --> B3[Renderer: autofill] end subgraph "OS-as-secret-broker" C1[Disk: DPAPI-NG blob] --> C2[OS broker process
plaintext only here] C2 -.handle.-> C3[Browser receives handle] C3 -.autofill via broker.-> C4[Renderer] end

Six-axis comparison

Axis	Decrypt-on-launch (Edge)	Decrypt-on-autofill (Chrome, Brave)	OS-as-broker
Plaintext-in-RAM window	Full session	Autofill RPC (~ms)	Never, in the browser process
Autofill latency	Memcpy (nanoseconds)	DPAPI unwrap (~10s of microseconds)	IPC + broker policy check (~ms)
Same-user-LCE attack surface	High (ReadProcessMemory exposes all)	Low (must catch the RPC window)	Negligible (no plaintext in the browser)
Memory-scraping forensics	Trivial (any same-user dump works)	Hard (must dump during fill)	Impossible (no plaintext to dump)
Sync UX with cloud account	Standard	Standard	Standard (broker handles sync)
Engineering cost to ship	Already shipped	Already shipped (Chromium baseline)	High (broker IPC, signed code path, extension renegotiation)

The OS-broker position is not hypothetical. The Windows Credential Manager already provides this property for Windows-app credentials. WebAuthn and passkeys provide it for sites that have adopted the standard. The DPAPI-NG protection descriptors include a WEBCREDENTIALS= variant [@ms-learn-dpapi-ng][@ms-learn-dpapi-ng-descriptors]. Pluton-anchored vTPM key unwrap provides a hardware-rooted broker substrate [@ms-learn-pluton]. Credential Guard's LSAISO trustlet is architecturally an isolated secret-broker for LSASS-derived secrets [@ms-learn-credential-guard].

None of these primitives are wired into Edge's saved-passwords path. The engineering cost is non-trivial: the broker needs an IPC contract, the browser needs a signed-and-attested code path that talks to the broker, and the renderer extension API surface needs renegotiation. But the cost is finite, and the alternative is what Google has been shipping in Chrome since 2024 -- Chrome's App-Bound Encryption (see §7) is exactly a step toward the broker model, and Microsoft has the same DPAPI substrate but no equivalent control for Edge [@google-chrome-abe-2024].

What "by design" means structurally

Microsoft can take the "by design" position because they are not wrong about cryptography. They are right about the bound. No protocol can autofill plaintext into a child renderer without some process in the chain holding plaintext at the moment of fill. The architectural question is which process and for how long.

Edge's answer: "the parent browser process, for the entire session." Chrome and Brave's answer: "the parent browser process, for the autofill RPC." The broker design's answer: "a separate, higher-privileged process, for the autofill RPC, and never the browser at all."

All three are valid points in the design space. The question is not "which is right" -- the answer depends on the user's environment -- but "what should the default be for a 2026 consumer browser." The PSI half of the article shows Microsoft can choose the most demanding default when they want to. The endpoint half shows what default they chose here.

To see why this is a structural property of the problem, not a Microsoft-specific gap, we need to look at the theoretical limits on both sides.

9. Theoretical limits

Two lower bounds, in parallel: one cryptographic (the PSI side), one architectural (the endpoint side).

PSI side: communication and computation lower bounds

The communication lower bound for PSI is folklore, used as the comparison baseline in Pinkas-Schneider-Zohner at USENIX Security 2014 [@psz-2014]. Informally: any PSI protocol must transmit at least $\Omega(\min(n_A, n_B) \cdot \kappa)$ bits, where $\kappa$ is the security parameter. The argument is information-theoretic: the receiver has to learn the intersection, which can have size up to $\min(n_A, n_B)$, and each element identifier needs $\Omega(\kappa)$ bits of representation to avoid collisions.

Silent OT [@silent-ot-2019] meets this lower bound up to polylogarithmic factors in the symmetric balanced setting. HE-PSI in the asymmetric setting gets to $O(n_R \cdot \log n_S)$ ciphertexts via CLR17's partition-and-evaluate construction [@clr-2017], which is sublinear in $n_S$ -- the breakthrough that makes Edge Password Monitor practical.

The computation lower bound on the sender side is $\Omega(n_S)$. The sender must, in the limit, touch each element of its set at least once per query. There is no way around this without trading correctness or privacy. Apple "cheats" by reducing the effective $n_S$: their 15-bit bucket cuts the per-query work to roughly $1.5\text{B} / 2^{15} \approx 46{,}000$ elements. Microsoft's two-byte shard cuts to roughly $5\text{B} / 2^{16} \approx 76{,}000$ elements. The lower bound applies per shard, not per total corpus.

The OT-extension lower bound is $\Omega(\kappa)$ base OTs per protocol session, with the bulk of the OT count amortised away by symmetric crypto. KOS15 meets this; Silent OT improves the wire constants further. By 2026, OT extension is essentially solved engineering.

Endpoint side: the "no plaintext in process" lower bound

The cryptographic side is comfortably tight. The endpoint side is much weirder.For a process $P$ to autofill a credential into a child form, some component in the trust chain must hold the plaintext at the moment of fill. There are exactly three possible holders:

$P$ itself. The Edge design. Plaintext lives in the parent browser process throughout the session.
A child renderer $Q$. The Chrome / Brave design. Plaintext crosses the parent-renderer boundary for the duration of the autofill RPC and gets zeroed.
A separate higher-privileged broker $B$. The OS-broker design. Plaintext lives in a sibling process that is harder to dump than the browser (in the limit, a PPL or a Credential-Guard-style trustlet).

No general cryptographic primitive lets a process use a plaintext credential without ever holding it. The plaintext is a value; the operations on it (paste-into-form, compute-HMAC-with-it, transmit-over-TLS-as-a-bearer-token) all require it in cleartext at some point. This is not a deficiency of any particular cryptosystem. It is the definition of "use."

The plaintext-RAM design Edge ships is not a cryptographic failure. It is a deliberate choice to spend the plaintext-in-RAM budget on UX latency. The escape hatch is architectural: a hardware-isolated broker process. Pluton-anchored vTPM key unwrap [@ms-learn-pluton], Credential Guard's LSAISO pattern [@ms-learn-credential-guard], DPAPI-NG with the right protection descriptor [@ms-learn-dpapi-ng-descriptors] -- the OS primitives all exist.

Key idea: There is no cryptographic primitive that lets a process autofill plaintext without holding it. The only escape hatch is an architectural one: a higher-privileged broker. Microsoft already ships the broker primitives -- DPAPI-NG, Credential Guard, Pluton. They are not wired into Chromium.

The aha moment the rest of the article was built to deliver: the Ronning PoC is not a "bug" in any meaningful sense. The structural question is whether Microsoft should ship the architectural primitive -- which they already have, in DPAPI-NG and Credential Guard -- but have not wired into Chromium's password store. The "by design" response is technically true and politically convenient simultaneously. Both are correct readings.

Both lower bounds are tight or near-tight today. The PSI side is essentially solved engineering; the endpoint side is essentially solved policy and unsolved deployment. The open questions are about which side we invest in next.

10. Open problems

Four open problems, framed as research directions Microsoft, Apple, and Google have not jointly committed to.

Open problem 1: post-quantum PSI and OT extension

Every deployed breach-checking protocol today rests on assumptions Shor's algorithm breaks. The OPRFs in Apple PSM and Google Password Checkup rely on discrete log over elliptic curves; the HE-PSI in Edge Password Monitor relies on BFV-on-classical-parameters; Paillier (historic, FNP04) relies on integer factorisation. Harvest-now-decrypt-later exposure on durable transcripts is the near-term migration question: an adversary capturing PSI transcripts today and storing them until a cryptographically relevant quantum computer arrives could, in principle, reconstruct the queries.

Lattice-based OT extension exists at currently-secure parameters, at roughly $10\times$ the communication of IKNP per OT in early prototypes. Whether the breach-checking deployments at Microsoft, Apple, and Google migrate on the same timeline as the rest of TLS (the IETF post-quantum-handshake transition) is an open coordination problem.

Open problem 2: multi-party breach corpora

No production deployment of a $>2$-party breach-checking service exists. HIBP, Google, Apple, and Microsoft each hold corpora that overlap but contain unique breaches. Consolidating them privately -- so a query gets the union of all four corpora's match metadata without any one provider learning more than their own corpus contributed -- would meaningfully improve detection.

The academic literature on multi-party PSI is substantial and growing, but the engineering and the governance work has not been done. Each provider has a different commercial relationship with the breach dataset, a different legal posture, and a different operational interest in their corpus being canonical. The cryptographic primitive is the easy part.

Open problem 3: sub-linear sender-side amortisation

The $\Omega(n_S)$ sender-side computation lower bound is per query. For a service serving billions of queries against a static $S_S$, can per-query cost be amortised across queries via a preprocessing step the sender pays once?

Cong et al. 2021 [@cong-2021] reduces constants substantially and pushes the practical envelope. Sub-linear asymptotic sender-side cost is open. The information-theoretic barrier is real -- the sender must touch any element that could be in the receiver's query -- but the expected cost over many queries against a static corpus admits a more aggressive analysis under the right access patterns.

Open problem 4: hardware-broker browser secret stores

The endpoint architectural problem. Migrate Edge, Chrome, and Brave from "process-RAM plaintext" to "OS-broker (plaintext never crosses into the browser)" using DPAPI-NG with a broker-PPL protection descriptor or a Credential Guard-style trustlet.

WebAuthn and passkeys offer this property already -- the platform authenticator holds the private key, and the browser receives signed assertions without ever seeing the secret. But passkeys require per-site enrollment that traditional username-password sites have not adopted at scale; the long tail of legacy login forms will remain on saved-passwords-as-strings for years.

The Windows Credential Manager offers the broker property for Windows-app credentials -- but it is not wired into Chromium for browser credentials. The engineering work is real; the cryptographic work is essentially trivial. Whether and when Microsoft, Google, or Brave commit to it is the question.

Open problem	What's been tried	Current best	Why it matters
Post-quantum PSI	Lattice-based OT, ring-LWE OPRFs	Prototype-grade; 10x classical at ~secure parameters	Harvest-now-decrypt-later on PSI transcripts
Multi-party breach corpora	Multi-party PSI literature (e.g., Kolesnikov et al. CCS 2017)	Academic constructions; no production deploy	Each provider's corpus has unique recall
Sub-linear sender cost	Cong et al. 2021 constants reduction	Linear $\Omega(n_S)$ per query	$5 \times 10^9$ corpus, billions of queries
Hardware-broker secret stores	WebAuthn / passkeys; DPAPI-NG, Credential Guard	Standards exist; wiring into browsers is missing	The Ronning PoC threat model

Open Chromium's process tree on Windows (Task Manager: Details, group by Path) and look for the `Google Chrome.exe` (or `msedge.exe`) process running with the `--type=` argument absent -- that's the parent. App-Bound Encryption binds the DPAPI unwrap to that exact parent process's signature, so a same-user attacker masquerading as Chrome cannot ask DPAPI to unwrap Chrome's data even with the right user identity. The architectural primitive is sitting in Chrome's source tree as of July 2024 [@google-chrome-abe-2024]; the equivalent control for Edge's password store has not shipped.

These four open problems share a structure: each would require coordination across multiple vendors and across the cryptography / platform / browser boundary. None is research-blocked. All are governance-blocked.

11. Practical guide

What should you do this week?

Users

If your Edge browser is your password manager and you are on a single-user laptop you control end-to-end, the Ronning PoC's threat model is "an attacker who can run code as you on your own machine." If that happens, the attacker is already in a strong position regardless of how Edge holds passwords -- they can keylog the next login, screenshot anything you autofill, or install a malicious browser extension. The marginal risk of the plaintext-RAM design on a single-user laptop is real but bounded.

If you share a Windows host -- a family PC with multiple accounts, a small-business workstation several employees sign into, a domain-joined laptop on which IT has administrative access -- the calculus changes. Any same-user process can read your Edge plaintext during your session. Any administrator can read it across sessions (the PoC's "Administrator can access other users' Edge processes" mode). The case for moving saved credentials out of Edge into a dedicated password manager (1Password, Bitwarden, KeePass) is structurally stronger here.

A dedicated password manager usually still keeps plaintext in its own process RAM during autofill -- this is the §9 lower bound asserting itself. The difference is the size of the plaintext-in-RAM window: dedicated password managers tend to require an explicit unlock and re-lock after a configurable idle period. Edge's window is the entire browser session.

Note: On a multi-user Windows machine -- RDS, AVD, Citrix, a family computer with separate accounts -- disable Edge's password manager via the PasswordManagerEnabled group policy and route users to an out-of-process credential broker (1Password's CLI integration, Bitwarden's desktop helper, or the platform Credential Manager).

Windows admins

The two relevant Edge enterprise policies are documented on Microsoft Learn:

PasswordManagerEnabled [@ms-learn-passwordmanagerenabled] -- turns Edge's saved-passwords feature on or off entirely. On a multi-user host with sensitive data, the right value is 0.
PasswordMonitorAllowed [@ms-learn-edge-pm] -- controls whether Password Monitor's breach-checking PSI runs at all. The default is "user-controlled"; in a managed enterprise, you may want to mandatorily enable it (independent of whether the password manager itself is enabled, because Password Monitor can check passwords you type into login forms, not just ones you have saved).

For RDS, AVD, and Citrix environments specifically, the threat model is structurally worse than a single-user laptop. Multiple users share a single Windows host. Their Edge profiles are isolated by Windows ACLs but their processes are not isolated against an administrator. The PoC's "Administrator privileges can access other users' Edge processes" mode is exactly the privilege available to a session-host administrator who has been compromised, or to a malicious tenant who escalates locally.

On a shared-tenant Windows host, the question is not whether same-user LCE will occur -- it is structurally more common than on a single-user laptop -- but how containable it is when it does. Saved browser credentials are an outsized lever for an attacker who pivots laterally: a single compromised user account on a session-host can yield every saved corporate credential for that user, and an administrator escalation can yield every saved credential for every user on the host. The hardening recommendation is to disable browser-based password management entirely (`PasswordManagerEnabled=0`) on session-host images, document an approved credential broker for your environment (Windows Credential Manager for native apps; an enterprise password manager with broker integration for browsers), and audit Edge profile directories on session-host images for stale `Login Data` SQLite files left over from earlier deployments.

Developers

If you ship a component that handles credentials, the design lesson from §9 is not "never hold plaintext" -- you cannot avoid it without an OS-level broker -- but "minimise the plaintext-in-RAM window."

The Chrome App-Bound Encryption pattern from July 2024 [@google-chrome-abe-2024] is a template: bind your at-rest key unwrap to a verified process identity so an attacker who exfiltrates your wrapped data cannot trivially unwrap it from a different process. If you must hold plaintext in the parent process for the lifetime of the session (the Edge design), make the trade explicit in the threat model documentation and ensure operations consuming the plaintext are auditable.

If you can architecturally afford a broker, do it. The IPC cost is real (low-microsecond per call) but small compared to the operational reduction in incident severity. WebAuthn / passkeys are the long-term destination for credentials; the broker pattern is the short-term destination for everything else.

12. Frequently asked questions

Yes, at rest on disk. DPAPI wraps the symmetric key that encrypts Edge's `Login Data` SQLite file under a key chain rooted in the user's password. When the user is logged out (or the machine is powered off), the on-disk blob is opaque to anyone who does not have the user's DPAPI credentials. The protection ends the moment Edge unwraps the DPAPI blob into process memory, which happens during browser launch or the first password-feature activation. Once unwrapped, the credentials sit in `msedge.exe`'s heap until the process exits, and `ReadProcessMemory` from any same-user process reads them as plaintext. DPAPI is an at-rest control, not an in-memory one. Partially. If Edge ran as a protected process at an appropriate signature level, only an antimalware-PPL-elevated process could open it for `ReadProcessMemory`, which would substantially raise the bar against a same-user attacker. Browser-process PPL has implications for every loaded DLL (each must be signed at or above the host's PPL level) and every extension API the renderer expects to call. Chrome and Brave have not adopted PPL for the browser process either. Microsoft has the option; they have not used it. PPL would address the same-user-LCE concern but not the administrator-across-sessions concern. No. Credential Guard isolates LSASS-derived secrets (NTLM hashes, Kerberos tickets, cached credentials) into the LSAISO trustlet running under Virtualization-Based Security, which is unreachable from the normal-world kernel let alone normal-world user-mode processes. It does not cover browser-owned secrets. Saved Edge credentials live in `msedge.exe`'s heap, not in LSASS, and Credential Guard does not extend protection to arbitrary user-mode application secret stores. No, in the strict cryptographic sense. K-anonymity leaks the bucket index by design -- the server learns a 20-bit (HIBP), 15-bit (Apple), or 16-bit (Edge shard) prefix of the hash being queried, which carries non-trivial information about which password the client is asking about. A proper PSI protocol leaks nothing beyond the intersection itself. The argument for k-anonymity is that the bucket is large enough -- on the order of hundreds to thousands of possible hashes per bucket -- that the residual information is not actionable for the threats most users face. It is a precise statement of "a small leak in exchange for vast practical efficiency"; the cost is documented and bounded, and that is why every deployed service uses some variant of it. But it is not zero-leak. Threat-model differences and SGX's well-documented side-channel literature (see the §6 Aside for the four-attack chronology). For a breach-checking service whose threat model is "the corpus must not leak from inside Microsoft," HE-PSI offers a clean cryptographic argument that does not depend on any TEE's silicon-level security claims. The MSR Cryptography and Privacy group had been publishing the relevant HE-PSI papers since 2017 and shipping the SEAL library publicly since 2018, so the substrate was in-house. The cost is real (orders of magnitude more compute than an SGX enclave) but tractable at the sharded scale Edge Password Monitor operates at. The trade is reasonable, and it is documented in the MSR blog [@msr-password-monitor-2021]. AMSI evasion. The Antimalware Scan Interface scans .NET 4.8+ assemblies before execution; .NET 3.5 predates AMSI's API surface entirely. A C# program targeting .NET 3.5 will run on any modern Windows with the legacy framework installed (which is most of them, because .NET 3.5 is shipped as a Windows feature) and will not be subject to the same managed-runtime scanning that 4.8+ assemblies are. The current GitHub README says ".NET Framework 4.8.1 (changed from 3.5 originally)" [@ronning-github] -- likely to ease running on a clean modern Windows -- but the original .NET 3.5 framing was the deliberate AMSI-evasion choice. The sibling AMSI post in this series explains the scanning architecture in detail. Per the researcher's claim and the PCWorld relay, no -- see §7 for the decrypt-on-autofill contrast and Chrome's App-Bound Encryption hardening [@pcworld-pippig-2026][@google-chrome-abe-2024]. The observable difference is direct: a `ReadProcessMemory`-based scrape of an idle Chrome process returns markedly less than the same scrape of an idle Edge process. Yes (with caveats). See §7's MSRC-servicing-criteria Aside for the full framing [@msrc-servicing-criteria]: the short answer is that the position is internally consistent with a decade of MSRC policy and with the §9 architectural lower bound, but it concedes the same-user LCE threat model and shifts defence onto endpoint controls (antivirus, application-control policies, PPL on antimalware processes only) that may not exist on the user's machine. The architectural primitive that would close the gap (an OS broker) exists on Windows but is not wired into Chromium.

The PSI on the wire is real. The plaintext-RAM concession is also real. Both are statements about which threat model the Edge product team is defending against, and the apparent contradiction in the title disappears once you read them as such.