Parag Mali - tag: bitlocker

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.

BitUnlocker: When Microsoft's Recovery Environment Becomes the Master Key

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

**In July 2025, Microsoft's own internal red team disclosed a four-CVE chain called BitUnlocker that bypasses TPM-only BitLocker in under five minutes from a USB stick, regardless of whether the device uses a discrete TPM, fTPM, or Pluton.** The attack works because the Windows Recovery Environment is given the BitLocker auto-unlock state legitimately during repair operations, and STORM found four parsers inside that trust boundary whose flaws let an attacker *be* the recovery environment. Patches shipped in KB5062553, but until the Secure Boot revocation infrastructure removes the pre-patch boot manager from the trust set, the chain remains exploitable on most fielded Windows 11 devices. The only mitigation that changes the threat model independently of patch state is the same recommendation Microsoft has been making since Vista: enable a pre-boot PIN.

1. Hold Shift, click Restart, lose your disk

Hold Shift. Click Restart. Plug in a USB stick carrying a pre-patch boot manager [@ms-winre-ref] [@garatc-poc]. Under five minutes later, on any device whose Secure Boot trust set still includes the 2011 root, the encrypted drive that protected your laptop is mounted in plaintext. No PIN ever entered. The TPM none the wiser. The researchers who showed how to do this work at Microsoft.

This is not a hypothetical. The proof of concept is on GitHub [@garatc-poc]. The end-to-end attack takes less than five minutes against a fully patched Windows 11 device that has not yet deployed the Secure Boot revocation infrastructure -- which is to say, most of them.

The attack is called BitUnlocker. It is a four-CVE chain disclosed and patched by Microsoft on July 8, 2025 in cumulative update KB5062553 [@kb5062553], then presented to the public a month later at Black Hat USA 2025 and DEF CON 33 with a Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. The four vulnerabilities are CVE-2025-48804 (System Deployment Image parsing) [@nvd-cve-2025-48804], CVE-2025-48800 (tttracer.exe offline scanning) [@nvd-cve-2025-48800], CVE-2025-48003 (SetupPlatform.exe and a Shift+F10 hotkey) [@nvd-cve-2025-48003], and CVE-2025-48818 (Boot Configuration Data target-OS impersonation) [@nvd-cve-2025-48818].

The researchers are Netanel Ben Simon and Alon Leviev of STORM, Microsoft's internal red team [@itnews-bitunlocker]. Leviev is the same researcher who disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate], so the line of work has provenance: a Microsoft engineer who understands the Windows update pipeline well enough to undo it, now turned on the recovery pipeline that runs when the update pipeline fails.

A five-minute physical bypass against BitLocker is not a research curiosity in 2026. ShrinkLocker, the BitLocker-as-ransomware-payload family disclosed by Kaspersky in May 2024, was used to extort organisations in Mexico, Indonesia, and Jordan [@kaspersky-shrinklocker]. APT41 paired ProxyLogon access with BitLocker as the workstation-encryption layer of a 2021 ransomware operation [@cymulate-apt41]. Romania's national water authority lost about 1,000 systems to a BitLocker-based ransomware incident over a December 2025 weekend [@therecord-romania-water]. BitLocker's installed base is where the defensive stakes live. BitUnlocker is what the offensive stakes look like.

STORM stands for Security Testing and Offensive Research at Microsoft [@itnews-bitunlocker]. It is the internal red team that publishes coordinated disclosures against Microsoft's own products.

The default BitLocker configuration on Windows 11 consumer and most enterprise installs. The Trusted Platform Module releases the Volume Master Key automatically at boot when the Platform Configuration Registers match an expected profile, with no human interaction. There is no pre-boot PIN, no startup key, no challenge -- the only authentication is the boot chain's measurement.

The pre-boot PIN configuration -- TPM+PIN, in Microsoft's terminology -- defeats every attack in this article, including BitUnlocker. Microsoft has been recommending TPM+PIN in some form since BitLocker shipped with Windows Vista on its January 30, 2007 consumer general-availability date [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Eighteen years later, that recommendation has not changed.

What has changed is the consequence of ignoring it.

Key idea: TPM-only BitLocker assumes the boot chain is trustworthy. The boot chain has been the dominant BitLocker attack surface for three years and counting. The Windows Recovery Environment is part of the boot chain.

Note: The July 8, 2025 patches close the four code paths inside WinRE. They do not, by themselves, revoke the pre-patch boot manager that BitUnlocker downgrades to. Until the Secure Boot revocation under KB5025885 (the "REVISE" rollout) is deployed on a device, the BitUnlocker entry vector remains usable [@neodyme-bitpixie-no-fix] [@kb5025885].

To understand why a four-CVE chain inside the recovery environment is enough to mount the entire encrypted volume in plaintext, we have to go back to a design decision Microsoft made in 2006. That decision is still shipping in every copy of Windows.

2. Why the recovery environment has the keys

BitLocker shipped with Windows Vista on its consumer general-availability date, January 30, 2007 [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Niels Ferguson's August 2006 cipher specification described the cryptographic core -- AES in CBC mode plus a custom diffuser called Elephant, designed to resist exactly the kind of disk-sector chosen-plaintext games that an attacker with full-disk read/write access could otherwise play [@ms-ferguson-cipher] [@archive-ferguson]. Four protector modes shipped with Vista: TPM-only, TPM+PIN, TPM plus a USB startup key, and TPM plus startup key plus PIN [@ms-bitlocker-countermeasures]. Each successive mode added a pre-boot human-presence check that the TPM-only default deliberately omitted.

The cipher specification is the public part of the design. The part that mattered for the rest of the story is the part that is barely documented at all: how recovery works.

The key-encrypting key that wraps the Full Volume Encryption Key. When a user changes their password or recovery configuration, only the VMK wrapping changes -- the entire volume does not need re-encryption. The TPM seals the VMK to a profile of boot-time measurements. The symmetric key that encrypts each sector of the BitLocker-protected volume. The FVEK is never directly handled by the user; it sits behind the VMK and is rewrapped only during operations like algorithm change or full re-encryption. A small bootable image, based on Windows PE, that the boot manager hands off to when normal Windows fails. WinRE provides Push Button Reset, Startup Repair, System Image Recovery, Reset This PC, and the offline scanning tools that the rest of this article will treat as a trust boundary [@ms-winre-ref].

The recovery problem Microsoft was solving in 2006 was unromantic but unavoidable. If full-disk encryption is to be default-on for an operating system that ships on a billion devices, the recovery environment has to read the OS volume during a repair pass without re-prompting the user for a recovery key every time a Windows update hiccups. The 24x7 help desk for a Fortune 500 cannot dispatch a forty-eight-character recovery key to every user whose system needs Startup Repair. So the Windows boot manager passes the unlock state along to WinRE, which inherits the ability to mount the encrypted volume during legitimate recovery operations [@ms-winre-ref].

The behavior is documented in every WinRE technical reference Microsoft has shipped since Vista. The rationale -- the original engineering memo about why auto-unlock is the right answer, given the help-desk requirement -- is not public. That gap matters because the rationale is the load-bearing wall of the threat model. The choice is consistent with every Microsoft document about WinRE; the engineering decision itself is folk knowledge.

The trade-off that runs through this entire article is simple to state. If the recovery environment can mount the volume without user input, the recovery environment is part of the encryption's trust boundary. If the recovery environment requires user authentication on every entry, you have effectively re-implemented the pre-boot PIN -- you have just moved its name. Microsoft picked the first option in 2006 because the second option breaks help-desk recoverability. Eighteen years later, that is still the choice. BitUnlocker is what the bill looks like.

Windows 8 removed the Elephant diffuser but kept AES-CBC alone. XTS-AES did not become BitLocker's default for new fixed drives until Windows 10 v1511 in November 2015 [@ms-bitlocker-configure]. The two-key VMK/FVEK hierarchy survived every cipher transition. So did WinRE's auto-unlock behavior.

Twenty months after Vista shipped, a Princeton research group would discover that "powered off" did not actually mean "key gone." The published attack literature against BitLocker was about to begin.

3. Eighteen years, six generations, one recommendation

The first attack specifically demonstrated against BitLocker as the named target appeared in 2008, the year after Vista's general availability -- though earlier generic memory primitives like FireWire DMA (Ruxcon 2006) became applicable to BitLocker as soon as Vista shipped. The most recent pre-2022 BitLocker bypass appeared in February 2024, when a four-dollar microcontroller pulled the keys off a Lenovo ThinkPad in 43 seconds [@hackaday-pico]. Between those two endpoints sit six attack generations. Each one moved one layer up the trust stack. Each one was answered by Microsoft with the same operational recommendation.

gantt title BitLocker bypass generations, 2006-2025 dateFormat YYYY-MM axisFormat %Y

section Hardware-adjacent
Cold boot (Halderman et al)        :2008-07, 60d
FireWire/PCI DMA (Boileau, Inception) :2006-10, 1825d
TPM bus sniff (marcan, Andzakovic)   :2019-01, 365d
Pi Pico TPM sniff (StackSmashing)    :2024-02, 30d
TPM+PIN bus bypass (SCRT, Compass)   :2024-02, 270d

section Software boot chain
Stoned, Vbootkit 2                   :2009-07, 90d
Self-Encrypting Deception (Meijer)   :2018-11, 180d
Bitpixie discovery (Rairii)          :2022-08, 30d
Bitpixie disclosure (CVE-2023-21563) :2023-02, 30d
BlackLotus (CVE-2022-21894)          :2023-03, 90d
BitUnlocker (KB5062553)              :2025-07, 60d

section Paradigms
Evil Maid framing (Rutkowska)        :2009-10, 30d

The structural reading of that timeline matters more than any individual entry, so here is the layer-by-layer walk:

Generation 1 -- Cold boot (2008). J. Alex Halderman and collaborators at Princeton and the EFF showed that DRAM retains its contents for seconds to minutes after power loss, longer if chilled with canned air. The AES key schedule has enough redundancy to be reconstructed from a partial dump, which means a powered-off BitLocker laptop with a still-warm DIMM is not actually at rest [@halderman-coldboot] [@halderman-coldboot-pdf]. Microsoft's structural answer was the Memory Overwrite Request (MOR) bit [@ms-bitlocker-countermeasures] and the eventual move to DDR generations that lose state faster. The user-facing answer was a pre-boot PIN [@ms-bitlocker-countermeasures].

Generation 2 -- FireWire and PCI DMA (2006 onward). Adam Boileau demonstrated at Ruxcon 2006 -- in a talk titled Hit By A Bus: Physical Access Attacks With Firewire -- that any host with an active FireWire port would let an unauthenticated peripheral read or write physical memory without involving the CPU [@boileau-ruxcon-2006]. Carsten Maartmann-Moe productionised the primitive as Inception, extending it to Thunderbolt, ExpressCard, and any other PCI-bus port that did not gate DMA behind the IOMMU [@inception-readme]. Microsoft's structural answer accumulated in stages: DMA-related Group Policy controls during the Windows 8.1 era, then a named Kernel DMA Protection feature shipped with Windows 10 1803 -- with the explicit exclusion that 1394 FireWire is not covered by KDP, so the legacy bus has to be disabled in firmware [@ms-kdp]. The user-facing answer was a pre-boot PIN.

Generation 3 -- Classical bootkits (2009). Peter Kleissner's Stoned and the Kumar brothers' Vbootkit 2, both presented at Black Hat USA 2009, showed that a Master Boot Record bootkit could load above the BitLocker pre-boot environment, hook the key-release path, and never trip the TPM's Platform Configuration Registers because nothing had measured the MBR yet [@wack0-taxonomy]. Microsoft's structural answer was UEFI Secure Boot plus Measured Boot's PCR 7, which moved the trust anchor from the MBR into the firmware. The user-facing answer was a pre-boot PIN.

Threat-model rename -- Evil Maid (2009). Joanna Rutkowska and Alex Tereshkin published a one-minute USB-stick infector against TrueCrypt that established a threat-model name rather than a primitive [@rutkowska-evilmaid]. Rutkowska's earlier January 2009 post had already named BitLocker as the disk encryption she missed after moving to macOS [@rutkowska-miss-bitlocker]; her October 2009 follow-up named the category of attacks that everybody now calls Evil Maid. The Microsoft Countermeasures page now uses the same threat-model tier she articulated.

Generation 4 -- Self-Encrypting Deception (2018-2019). Carlo Meijer and Bernard van Gastel showed at IEEE S&P 2019 that BitLocker had been silently delegating cryptography to the SSD firmware on self-encrypting drives -- and that the firmware was broken across several major vendor families, with Samsung 840/850 EVO and Samsung T3/T5 among the affected lines [@meijer-sed] [@researchr-meijer]. Microsoft's structural answer (KB4516071) was to stop delegating. This is the rare frontier Microsoft closed rather than mitigated incrementally: software encryption became the default again, and the "trust the drive" path was retired.

Generation 5 -- TPM bus sniffing (2019-2024). On a discrete TPM, the LPC or SPI bus between the CPU and the TPM chip carries the unsealed VMK in cleartext for a few microseconds. Hector Martin (marcan) first demonstrated extraction in January 2019 [@syss-tpm-sniffer]; Denis Andzakovic published the first written technical account later in 2019 [@andzakovic-tpmsniff] [@zdnet-bitlocker-attack] [@wack0-taxonomy]. StackSmashing's February 2024 Raspberry Pi Pico kit reproduced the same primitive against a Lenovo ThinkPad X1 Carbon for under ten dollars of hardware in 43 seconds of wall clock [@hackaday-pico] [@stacksmashing-pico]. Microsoft's structural answer was firmware TPM (AMD fTPM, Intel PTT) on modern CPUs and Pluton on Pluton-equipped chipsets [@ms-pluton]. The user-facing answer was a pre-boot PIN.

The Pi Pico reproduction reduced the hardware cost by an order of magnitude from Andzakovic's 2019 FPGA setup [@andzakovic-tpmsniff] [@hackaday-pico]. Same primitive; different price point.

Generation 5.5 -- TPM+PIN hardware bypass (2024). SCRT in Switzerland and Compass Security independently published that even with TPM+PIN configured, the Intermediate Key released after PIN validation still traverses the bus in clear on discrete-TPM hardware [@scrt-tpm-pin] [@compass-2024]. The structural defeat is Pluton, where the bus does not exist on-die [@ms-pluton]. The user-facing answer for everyone else stayed: a pre-boot PIN, plus discrete-TPM replacement or BIOS-level TPM bus protection.

By default, Microsoft BitLocker protected OS drives can be accessed by sniffing the LPC bus, retrieving the volume master key when it's returned by the TPM, and using the retrieved VMK to decrypt the protected drive. -- Denis Andzakovic, Pulse Security, 2019 [@andzakovic-tpmsniff]

Six generations. One recommendation. Pre-boot PIN. Microsoft has shipped real structural mitigations -- MOR, IOMMU, Secure Boot, Measured Boot, fTPM, Pluton, dbx revocation -- but the user-facing recommendation has not changed for eighteen years.

All six generations attack the layer below the boot manager. The boot manager itself, signed by Microsoft, has been treated as the trust anchor. In 2022, the first attack to make the boot manager itself the surface arrived. Its name was Bitpixie, and it is BitUnlocker's immediate ancestor.

4. The boot manager itself becomes the surface (2022-2025)

In August 2022, an independent researcher posting under the handle Rairii discovered that the Microsoft-signed Windows boot manager itself had a logic flaw: under a specific PXE soft-reboot sequence, the BitLocker Volume Master Key remained in physical memory and was never zeroed when control transferred [@rairii-mastodon] [@martanne-bitpixie]. The bug was assigned CVE-2023-21563. The patch shipped in the January 10, 2023 Patch Tuesday cumulative [@nvd-cve-2023-21563] [@msrc-cve-2023-21563]; Rairii made the discovery public on Mastodon the following month [@rairii-mastodon]. The old signed binary remained chain-loadable. It still is.

Thomas Lambertz of Neodyme published the canonical technical write-up of "Bitpixie" in late 2024, then presented the work at 38C3 in December 2024 [@neodyme-bitpixie] [@38c3-bitpixie]. His follow-up post asked an uncomfortable question -- why no fix? -- and answered it: the patch closed the code path, but the pre-patch boot manager was signed under Microsoft's Windows Production CA 2011, and that certificate was still in the Secure Boot allow-list (db) on most fielded Windows devices [@neodyme-bitpixie-no-fix]. A physically present attacker could supply an old, signed, vulnerable copy of bootmgfw.efi and the firmware would still load it.

This article uses "REVISE" as a convenience handle for Microsoft's verbosely-named "Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932" rollout. Microsoft does not market the work under the REVISE name -- the technical content here is what matters. The UEFI `db` is the allow-list of trusted signing certificates and signed binary hashes; the `dbx` is the corresponding deny-list. KB5025885's current (April 2024+) approach is certificate-based: it adds the Windows Production PCA 2011 signing certificate to `dbx`, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. (The original May 2023 mitigations used a hash-by-hash strategy against specific boot manager binaries that was superseded for being too narrow.) The rollout is opt-in across multiple phases (currently five) because pushing a `dbx` change at scale can brick devices [@kb5025885]. Microsoft Windows Production CA 2011. The intermediate certificate that signs the Windows boot manager and every other Microsoft-trusted EFI binary loaded under Secure Boot. The 2011 root is set to expire in waves starting June 2026, which is the structural reason REVISE / UEFI CA 2023 must complete before then [@kb5062553].

The REVISE rollout under KB5025885 ships across opt-in phases (currently five: Initial Deployment, Second Deployment, Evaluation, Deployment, Enforcement), each gated by a registry-bitmask AvailableUpdates opt-in.Within the currently-active Evaluation and Deployment phases, the mitigations roll out in three actions: (1) install the new UEFI CA 2023 cert into db and trust-roll to the 2023-signed boot manager; (2) push the Windows Production PCA 2011 signing certificate into dbx -- the moment that "patched" becomes "revoked" on that device; (3) write a Secure Version Number into the firmware so the boot manager can self-revoke older copies of itself [@kb5025885]. The named Phase 1 (Initial Deployment, May 9, 2023) used a now-superseded hash-by-hash revocation approach against specific boot manager binaries. Each phase is an irreversible state change once Secure Boot stays on, which is why Microsoft has gated the schedule on operator readiness rather than calendar pressure.

Compass Security's May 2025 follow-up reproduced the Bitpixie exploit in a WinPE-based variant signed entirely by Microsoft components -- replacing the third-party Linux shim that secured-core PCs disable by default -- end-to-end in roughly five minutes via PXE [@compass-bitpixie-winpe]. Five minutes is a useful benchmark because BitUnlocker's USB-deliverable PoC clocks at the same number against the same chain-load downgrade primitive, with a different post-exploitation strategy and a different delivery vector.

Two other 2022-2024 bootkits frame the era. ESET disclosed BlackLotus in March 2023, the first in-the-wild UEFI bootkit observed bypassing Secure Boot on a fully patched Windows 11 by abusing CVE-2022-21894 "Baton Drop" [@eset-blacklotus] [@msrc-cve-2022-21894]. ESET's November 2024 Bootkitty disclosure brought the first publicly analysed UEFI bootkit aimed at Linux, although ESET's follow-up note clarified the artefact was a Korean Best of Best student project rather than in-the-wild malware [@eset-bootkitty]. Both used the same observation that underwrites Bitpixie and BitUnlocker: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft adds it to dbx, which is a multi-year programme.

flowchart TD A["Microsoft-signed binary
with a logic flaw"] --> B["Stays trusted
until dbx revokes its cert
or its hash"] B --> C1["Bitpixie (CVE-2023-21563)
PXE soft-reboot leaks VMK
from physical memory"] B --> C2["BlackLotus (CVE-2022-21894)
Baton Drop drops a
UEFI bootkit"] B --> C3["BitUnlocker (4 CVEs)
Downgrade boot manager,
be the recovery environment"] C1 --> D["Patched is not revoked"] C2 --> D C3 --> D D --> E["REVISE / UEFI CA 2023
is the structural fix"]

Note: Each of Bitpixie, BlackLotus, and BitUnlocker depends on the same lemma. Microsoft can ship a patch that fixes a Microsoft-signed binary. Until that binary's signing certificate lands in dbx, the old signed copy keeps working on every Windows device whose Secure Boot policy still trusts PCA 2011 -- which, in mid-2026, is most of them. The dbx update is a separate, opt-in, multi-phase operation that has to complete before June 2026 because that is when PCA 2011 starts to expire on its own terms.

Same researcher, two pipelines: Leviev disclosed Windows Downdate at Black Hat USA 2024 and co-disclosed BitUnlocker at Black Hat USA 2025 [@safebreach-downdate]. Update pipeline one year, recovery pipeline the next.

Bitpixie scavenges the VMK from RAM after a buggy soft reboot. BlackLotus drops a UEFI bootkit. Both depend on the same observation: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft revokes it. In July 2025, four Microsoft engineers asked a sharper question. What if you do not have to find a logic flaw at all? What if the recovery environment is given the keys legitimately, and all you have to do is be the recovery environment?

5. Four parsers, one trust boundary

WinRE already has the keys. That is the design.

STORM's insight was not to attack the seal. It was to observe that every parser inside WinRE sits inside the BitLocker auto-unlock trust boundary, and to ask which of those parsers is buggy. Once you reframe the problem from "find a way to make the TPM release the key" to "the recovery environment is given the key by design, so make me the recovery environment," the question stops being cryptographic and becomes a code-audit question. STORM found four answers. There are almost certainly more.

The four CVEs map to four parsers. The first is the entry vector; the next two are escalations inside the boundary; the fourth is the unconditional decryption finisher that turns the chain from a privileged shell into a permanently disabled BitLocker volume. Each subsection below follows the same template: what gets parsed, where the integrity check goes wrong, what falls out of the parser, why that primitive ends the chain.

sequenceDiagram participant U as Attacker (USB) participant FW as UEFI firmware participant BM as Pre-patch bootmgfw.efi (PCA 2011) participant SDI as Boot.sdi parser participant WRE as Malicious WinRE participant V as BitLocker volume U->>FW: Boot USB stick FW->>BM: Loads Microsoft-signed boot manager (downgraded) BM->>SDI: Hash-and-execute SDI image SDI-->>SDI: Hash covers original bytes SDI-->>SDI: Execution targets appended WIM SDI->>WRE: Hands control to malicious WinRE WRE->>V: Inherits auto-unlock from boot context WRE->>U: Shell on the cleartext volume

5.1 CVE-2025-48804 -- SDI parsing as the entry vector

WinRE boots from a System Deployment Image (Boot.sdi) bundled with a Windows Imaging file (.wim). The boot manager hashes the SDI for integrity before transferring control. STORM noticed that the integrity check covered the on-disk original bytes of the SDI, but the runtime that consumed the image followed an internal offset pointer that the attacker could shift to point at appended bytes after the hashed region [@nvd-cve-2025-48804] [@itnews-bitunlocker]. Append a malicious WIM at the tail of a legitimate SDI, manipulate the offset, and the hash still passes -- but execution targets your bytes.

The garatc proof of concept assembles this into a USB-bootable payload that downgrades to a pre-patch bootmgfw.efi signed under PCA 2011 (still trusted on most fielded devices), then parses an SDI of its own construction. Total prerequisites listed in the PoC README: physical access, TPM-only protector, PCR 7 plus PCR 11 trusted, and Microsoft Windows PCA 2011 in the Secure Boot db [@garatc-poc]. The wall clock for end-to-end exploitation: under five minutes.

{` // Schematic of the CVE-2025-48804 integrity-vs-execution split. // The hash covers the on-disk SDI bytes; execution follows an // offset pointer that the attacker can move past the hashed region.

const sdi = readFromDisk("Boot.sdi"); const hash = sha256(sdi); // integrity check sees ORIGINAL bytes if (hash !== expectedHash) throw "abort";

const offset = readOffsetFromHeader(sdi); // attacker-controlled in malicious SDI const wim = sdi.slice(offset); // points PAST the hashed region executeWim(wim); // runs appended malicious WIM

// Lesson: the hashed range and the executed range are not the same range. // The fix in KB5062553 binds them so that execution can only target // bytes that the integrity hash actually covered. `}

Once the malicious WinRE is running, it inherits the BitLocker auto-unlock state from the boot context. The encrypted volume is now mountable. The remaining three CVEs are about what an attacker can do from within WinRE that the original threat model did not expect WinRE to enable.

5.2 CVE-2025-48800 -- tttracer.exe as a proxy executor

WinRE's Offline Scanning operation invokes antivirus tooling from within the recovery environment. The set of trusted binaries WinRE will execute during scan is enumerated in ReAgent.xml -- WinRE's app-registry equivalent -- and includes Microsoft-signed diagnostic utilities. Among them is tttracer.exe, Microsoft's Time Travel Tracing debugger, included because it is occasionally invoked during diagnostics [@nvd-cve-2025-48800].

tttracer.exe is a proxy executor: by design, it launches an arbitrary process under tracing instrumentation. The LOLBAS project documents the exact invocation as tttracer.exe {PATH_ABSOLUTE:.exe}, mapped to MITRE ATT&CK technique T1127, with the launched process running as a child of tttracer.exe [@lolbas-tttracer]. Inside the WinRE auto-unlock boundary, with the live OS volume mounted, "arbitrary process" is the same primitive as "shell on the cleartext volume." Combine an attacker-controlled ReAgent.xml with tttracer.exe's proxy-execution semantics and Offline Scanning becomes Offline Pwning.

Time Travel Tracing is a Microsoft debugger most readers will not have seen named. It records process execution as a deterministic replayable trace and is a standard tool inside Microsoft's reliability engineering. Being on the WinRE trusted-app registry is a reasonable choice when the threat model is "diagnose a broken boot," not "an attacker is in the recovery environment."

5.3 CVE-2025-48003 -- SetupPlatform.exe and Shift+F10

SetupPlatform.exe, the Windows Setup host, remains on the WinRE trusted-app registry after upgrades and registers a Shift+F10 hotkey that opens cmd.exe. The Shift+F10 chord has been a long-standing Windows Setup feature for OEM imaging and unattended diagnostics, where it is harmless because there is no encrypted volume mounted yet [@nvd-cve-2025-48003] [@hackacademy-bitunlocker].

Inside WinRE, after auto-unlock has happened, Shift+F10 opens cmd.exe on the cleartext OS volume. STORM observed that manipulating the WinRE Apps Scheduled Operation entries in ReAgent.xml creates an unbounded trigger window -- the hotkey stays armed long enough for an attacker to use it. The shell that opens has the privileges of SetupPlatform under WinRE, with the OS volume mounted underneath it.

5.4 CVE-2025-48818 -- BCD target-OS impersonation

The first three CVEs assume the attacker has gotten WinRE to boot. The fourth one closes the loop and turns the access from a privileged shell on the volume into an unconditional, persistent decryption -- without any further interaction.

WinRE enumerates disk volumes in a specific order when deciding which Boot Configuration Data (BCD) store to consume as the description of the "operating system to recover." STORM placed an attacker-controlled BCD store on the recovery partition that gets enumerated before the legitimate one [@nvd-cve-2025-48818] [@hackacademy-bitunlocker]. WinRE treats the attacker volume as the trusted OS to recover, then invokes Push Button Reset with the DecryptVolume directive -- a legitimate sub-operation of PBR that disables BitLocker entirely. After Push Button Reset completes, BitLocker is not bypassed; it is off.

A legitimate WinRE sub-operation invoked during recovery when the target volume must be fully decrypted before being re-imaged or returned to a clean state. The directive removes the BitLocker protectors and rewrites every sector of the volume in plaintext. When invoked by a legitimately-recovered OS, this is correct behavior. When invoked by an impersonated target-OS BCD entry, it is a permanent encryption removal.

5.5 The structural pattern

flowchart TD subgraph WB["WinRE auto-unlock trust boundary"] WP["Boot.sdi parser"] RP["ReAgent.xml parser"] BP["BCD store enumerator"] TP["Trusted-app registry"] end C1["CVE-2025-48804
SDI offset confusion"] --> WP C2["CVE-2025-48800
tttracer.exe proxy"] --> RP C2 --> TP C3["CVE-2025-48003
SetupPlatform Shift+F10"] --> RP C3 --> TP C4["CVE-2025-48818
BCD impersonation"] --> BP WB --> VMK["BitLocker VMK released
to whatever runs inside"]

Four parsers; one boundary. The structural pattern reads:

Key idea: Every CVE attacks a different parser. Every parser sits inside the same auto-unlock trust boundary. Patching individual parsers does not close the boundary; it shrinks it. The boundary is the bug class.

Note: TPM bus sniffing fails against fTPM and Pluton because there is no exposed bus to sniff -- the seal is computed and released on-die. BitUnlocker does not attack the seal. The seal works exactly as designed: PCR 7 plus PCR 11 match the expected boot-chain measurements, and the TPM releases the VMK to the boot manager. The boot manager passes the unlock state into WinRE. WinRE then runs an attacker's code because one of its parsers had a bug. Nothing about fTPM or Pluton intervenes, because the entire attack is upstream of the silicon that the seal would protect.

Microsoft shipped patches for all four CVEs in KB5062553 on July 8, 2025 [@kb5062553]. The patches fixed the four code paths. They did not change the trust boundary. They did not, by themselves, even revoke the pre-patch boot manager that the chain depends on. To see what the July patches actually changed, and what they did not, we have to look at REVISE.

6. What KB5062553 changed, and what REVISE will

On the same Patch Tuesday that fixed BitUnlocker, Microsoft also reminded administrators that the Secure Boot certificate underwriting the entire Windows boot chain begins to expire in June 2026 [@kb5062553]. The two facts are not independent.

KB5062553 closed the four BitUnlocker code paths inside the Windows 11 24H2 build 26100.4652 cumulative. The SDI parser was bound so that the integrity hash and the execution range now agree. The trusted-app registry semantics for tttracer.exe and SetupPlatform.exe were tightened so neither acts as a proxy executor inside WinRE. The BCD enumeration order was reworked so the recovery partition cannot present a target-OS impersonator before the legitimate one. Those are real fixes for real bugs.

What KB5062553 did not change is the trust set. The pre-July-2025 bootmgfw.efi is still signed under PCA 2011, and PCA 2011 is still in the Secure Boot db on most fielded Windows devices. A physically present attacker can supply that old, signed, vulnerable boot manager from a USB stick. The firmware will load it. The four code paths are fixed in the new boot manager, but the old boot manager is still on the trust list. This is the same downgrade pattern that keeps Bitpixie exploitable [@neodyme-bitpixie-no-fix].

The structural defence is REVISE, shipped under KB5025885 and the CVE-2023-24932 advisory [@kb5025885]. REVISE adds the Windows Production PCA 2011 signing certificate to the Secure Boot dbx, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. After REVISE deploys, the firmware refuses to load the pre-patch boot manager. The rollout is opt-in across multiple phases (currently five) because a dbx update at fleet scale carries real brick risk: any device that ends up trying to boot a binary whose signing certificate has just been moved to the deny-list will not boot. KB5025885 explicitly warns that once the mitigation is enabled on a device, it cannot be reverted while Secure Boot remains on.

This lemma appears in three places already in this article -- Bitpixie, BlackLotus, and BitUnlocker -- and it is worth stating once explicitly.

A Microsoft-signed binary stays in the trust set as long as its signing certificate is in db and neither its hash nor its signing certificate sits in dbx. Microsoft can ship a code-path patch that supersedes the old binary, but nothing in the trust set changes automatically. The dbx push is a separate operation, gated on a separate update, with its own opt-in semantics because pushing a wrong dbx value bricks devices.

The result is that "the bug is patched in the latest cumulative" and "an attacker with physical presence can no longer load the vulnerable signed binary" are not the same statement. The first is true after KB5062553. The second is true only after REVISE, only on devices where REVISE's dbx-revocation phase has run -- the phase that moves the PCA 2011 signing certificate into dbx so the deny-list overrides the allow-list. The June 2026 PCA 2011 expiration is the natural backstop -- after that date, the certificate no longer signs anything new, and the migration completes on its own timetable.

Until then, BitUnlocker's entry vector remains usable on every TPM-only device whose REVISE phase has not advanced.

flowchart LR A["Pre-July-2025 bootmgfw.efi
(PCA 2011 signed)"] --> B["KB5062553 patches
the four CVEs in the NEW
boot manager"] A --> C["REVISE adds PCA 2011
signing cert to dbx"] B --> D["New devices: closed code paths"] C --> E["Firmware refuses to load
the vulnerable signed binary"] D --> F["BitUnlocker fixed on patched device"] E --> G["BitUnlocker entry vector blocked
across the fleet"]

Note: PCA 2011 begins to expire in waves starting June 2026 [@kb5062553]. The UEFI CA 2023 migration must complete before then. Administrators of devices that have not yet reached REVISE's dbx-revocation phase should treat the June 2026 date as a hard deadline, not a goal: any device that misses the migration risks losing Secure Boot trust entirely on its next firmware update.

Patches close code paths. REVISE closes trust. Neither closes the WinRE auto-unlock surface itself. That is a different question, and the comparison Microsoft never likes to make is what other desktop operating systems chose to do about it.

7. How other platforms make the same trade-off

Windows is the only major desktop operating system that ships an auto-unlocking recovery environment on a TPM-sealed key. The other three -- macOS, ChromeOS, and Linux with LUKS -- make different choices at the same trade-off point. Looking at those choices shows what is actually possible.

Platform	Recovery primitive	Key availability during recovery	Auto-unlock from physical-presence path	Failure mode if compromised
Windows + BitLocker + WinRE	Push Button Reset, Startup Repair, Reset This PC	VMK released by TPM, inherited by WinRE	Yes -- Shift+Restart -> recovery menu	BitUnlocker class: parser bugs leak the cleartext volume to attacker code running inside WinRE
macOS + FileVault + macOS Recovery	macOS Recovery (boot to recovery partition)	Data Volume NOT mounted; user password or recovery key required	No	Recovery cannot read user data without authentication
ChromeOS + Verified Boot + Powerwash	Recovery USB / `chrome://recovery`	None -- recovery wipes user data	No	Recovery destroys the protected data set
Linux + LUKS / dm-crypt	initramfs / rescue shell	None -- every boot prompts for passphrase	No	Recovery cannot proceed without passphrase

Windows + BitLocker + WinRE is the only row in that table where the recovery environment can read user data without re-prompting the user. BitUnlocker is what the trade-off looks like once that property gets weaponised.

macOS chose a different recovery model. FileVault encrypts the Data Volume; the signed System Volume Snapshot does not. macOS Recovery boots into the signed system volume and presents a Disk Utility view of the Data Volume that requires a user password or recovery key to mount. The recovery environment is not given the keys. A macOS-side analogue of CVE-2025-48804 would still need to coerce Recovery into surfacing authentication UI -- the recovery primitive does not run with the user volume already mounted.

ChromeOS chose the most aggressive recovery model. Verified Boot enforces signature chains all the way to the kernel; recovery from a corrupted state means powerwash, which wipes the user partition. There is no equivalent of WinRE that needs to read the encrypted volume. The trade-off is enforced by sacrificing the data, which is acceptable because user data on ChromeOS is mostly remote.

LUKS / dm-crypt is the simplest model. Every boot, including recovery, prompts for the passphrase. There is no auto-unlock state to inherit. The trade-off is help-desk burden: a forgotten passphrase is a wiped drive. This is the model that the Microsoft Countermeasures page implicitly recommends for the "skilled attacker with lengthy physical access" threat tier when it suggests TPM+PIN [@ms-bitlocker-countermeasures].

Windows defines recovery as *transparent repair*. macOS defines it as *authenticated rebuild*. ChromeOS defines it as *wipe and restart*. LUKS defines it as *the same authentication you would do on a normal boot*. Each is internally consistent with the rest of its security model. None of them is wrong in isolation. They differ in what trade-off they make between fleet recoverability and recovery-environment exposure -- and BitUnlocker is what the most-usable-recovery choice costs.

Recovery-key escrow to Microsoft Entra ID, Active Directory, or a local user account is a separate confidentiality boundary from the BitUnlocker surface. Forbes reported in January 2026 on a Guam FBI warrant served to Microsoft for BitLocker recovery keys, illustrating the legal-process pathway [@forbes-guam-bitlocker]. Different threat surface; same product.

The trade-off Microsoft made in 2006 was the right one for a fleet that needs help-desk recoverability and the wrong one for a threat model with physical access. Eighteen years and seven attack generations later, the trade-off has not been revisited. The next section asks whether it can be.

8. Why patching cannot close the surface

In complexity theory, an impossibility result tells you what cannot be done no matter how hard you try. BitUnlocker is not that kind of result. It is the next thing over: a structural consequence of the threat model that no quantity of parser patches can close.

State the recovery-versus-confidentiality dilemma carefully. As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. This is not a theorem in the published literature. It is the structural reading of the Microsoft Countermeasures threat-model tiers [@ms-bitlocker-countermeasures], and it follows almost mechanically from how the WinRE auto-unlock state is inherited.

The dilemma admits exactly two engineering exits. The first is to deprecate WinRE auto-unlock and require a recovery key for every WinRE entry. Microsoft has not done this and will not do this, because the help-desk recoverability story collapses without it -- fleet administrators rely on WinRE entry being silent for routine repair. The second is to make TPM+PIN the default for non-Entra-enrolled devices, which forces a pre-boot human-presence check that WinRE structurally cannot satisfy. Microsoft has not done this either, presumably because of the help-desk cost of forgotten PINs at consumer scale.

Until one of those two changes, the next BitUnlocker is a question of when, not whether. The four CVEs are an existence proof for the bug class "Microsoft-signed binary on the WinRE trusted-app registry whose parsing of unsigned configuration data can be coerced." The cardinality of that bug class is not four. STORM found four. There are more.

Key idea: As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. The bug class is not the parsers. The bug class is the boundary that contains them.

Note: You cannot have unattended recovery and confidentiality at the same time against an attacker with physical presence. Every desktop operating system that has tried has either added authentication to recovery (macOS) or has been broken at recovery (BitUnlocker, multiple times). The choice is a product decision, not a software bug.

Microsoft is not unaware of this. Quick Machine Recovery -- the cloud-orchestrated recovery primitive that reached general availability in 2025 -- extends the WinRE-equivalent surface rather than retracting it [@ms-qmr]. The trade-off pricing is ongoing. So is the audit.

The next section is the question that follows from the boundary framing: what else is inside the boundary that STORM did not get to?

9. What STORM did not audit

STORM published four CVEs. The Windows Recovery Environment contains more than four parsers.

Four open questions follow directly from the boundary framing:

The remaining WinRE trusted-app surface. STORM exploited tttracer.exe and SetupPlatform.exe. The WinRE Apps Scheduled Operation in ReAgent.xml registers other Microsoft-signed binaries. None of those binaries was written under the assumption that an attacker would be the one calling them with the OS volume mounted. How many similar inheritances remain unaudited is unknown, and the population is the unstated denominator of every subsequent BitUnlocker-class CVE.

PCA 2011 trust on most fielded devices. Until REVISE deploys at fleet scale, the pre-July-2025 bootmgfw.efi remains chain-loadable on any device that still trusts PCA 2011. The June 2026 PCA 2011 expiration is the structural milestone [@kb5062553]. Between mid-2025 and mid-2026, the BitUnlocker entry vector is a deployment question, not a code question.

Quick Machine Recovery extending the WinRE-equivalent surface. Cloud-orchestrated recovery on encrypted volumes occupies the same trust boundary as WinRE -- by design, since the point of QMR is to do silent fleet repair on devices that cannot reach a desk [@ms-qmr]. No published security audit comparable to STORM's BitUnlocker work has appeared for QMR. The next BitUnlocker-shaped CVE may live there.

Pluton hardware bypass. No published practical hardware attack on Pluton exists in the open literature as of mid-2026. The SCRT/Compass-class TPM+PIN bypasses are limited to discrete-TPM hardware where the bus between CPU and TPM is exposed [@scrt-tpm-pin] [@compass-2024] [@ms-pluton]. Whether Pluton admits decapping, laser-fault-injection, or microarchitectural side-channel attacks is an open question that nobody outside Microsoft and a handful of three-letter agencies has the budget to answer at scale.

Quick Machine Recovery's 2025 general availability puts it inside the BitUnlocker disclosure timeline [@ms-qmr]. Microsoft is expanding the WinRE-equivalent attack surface in the same calendar year that STORM is publishing the four CVEs.

And one orthogonal question that every BitLocker survey is asked: who has the recovery key? A serious defender has to think about the recovery-key escrow surface too -- see below.

Note: Cloud escrow of the BitLocker recovery key is a confidentiality surface that BitUnlocker does not touch. BitUnlocker is a parser-level chain that gives a physically-present attacker the cleartext volume without ever needing the recovery key. The keyholder question is orthogonal. Both surfaces exist; both are worth thinking about; neither closes the other.

The open-problems list above is what is unaudited as of mid-2026. The actionable question -- what do I, as an administrator, do tomorrow? -- is the subject of the next section.

10. Six things defenders should do this week

If you administer a Windows fleet, six concrete actions change the threat model. They are listed here in priority order, not severity order. The first one is the structural mitigation; the others are patch hygiene around it.

1. Enable TPM+PIN. The PowerShell-equivalent invocation is manage-bde -protectors -add C: -tpmandpin [@ms-manage-bde]. This is the only mitigation that changes the threat model independently of patch state -- it forces a pre-boot human-presence check that WinRE structurally cannot satisfy. The honest trade-off: users forget PINs and help-desk burden goes up. The honest counterpoint: the recommendation has been in the Microsoft Countermeasures page in some form since Vista, and BitUnlocker is what eighteen years of ignoring it has produced [@ms-bitlocker-countermeasures].

Note: manage-bde -protectors -add C: -tpmandpin -- one PowerShell command, one PIN per user, one threat model permanently changed. This defeats Bitpixie, BitUnlocker, and any future BitUnlocker-class attack that lives upstream of the TPM seal. It does not defeat hardware TPM+PIN bus-sniff attacks on discrete TPMs [@scrt-tpm-pin] [@compass-2024], which are a separate class.

2. Apply KB5062553 or any later cumulative. The July 8, 2025 cumulative closes the four BitUnlocker code paths [@kb5062553]. By the time you read this, several later cumulatives have shipped; deploy the latest. This addresses the post-entry portion of the chain but not the entry vector.

3. Deploy REVISE / migrate Secure Boot to UEFI CA 2023. This is the dbx-side defence that revokes the pre-patch bootmgfw.efi [@kb5025885]. Until REVISE has run on a device, "patched" is not "revoked." The deployment is opt-in across multiple phases (currently five) because a bad dbx push at scale bricks devices; the June 2026 PCA 2011 expiration is the hard deadline.

4. Restrict WinRE access where the threat model permits. On kiosks, lab machines, lights-out servers, and other devices where there is no fleet-recovery requirement, reagentc /disable closes the WinRE entry surface entirely. This costs you Push Button Reset and Startup Repair on those devices, which is acceptable for devices that are re-imaged centrally [@hackacademy-bitunlocker].

5. Harden the firmware delivery surface. Enable Secure Boot, set a firmware password, disable USB and PXE boot in firmware on devices that are not expected to be re-imaged in the field [@hackacademy-bitunlocker]. This closes the delivery vector independently of the WinRE patch state. It does nothing against an attacker who can boot from internal disk, which is why this is one of six items rather than the first one.

6. Surface BitLocker protection state in management telemetry. Intune, Microsoft Defender for Endpoint, and Entra ID can all report on whether a device has a TPM-only or TPM+PIN protector and whether the CVE-2023-24932 dbx revocation has applied (the per-device Secure Boot dbx update status field surfaced in Intune / Defender for Endpoint). Make those fields first-class in your fleet dashboards. PIN-on / PIN-off and dbx-revoked / not-revoked should both be visible at the fleet level, not buried inside a per-device drill-down.

{` // Logical equivalent of: manage-bde -protectors -get C: // Run this against the parsed output to confirm the // device is using TPM+PIN rather than TPM-only.

function classifyProtectors(protectorTypes) { const hasPIN = protectorTypes.includes('TpmPin') || protectorTypes.includes('TpmPinStartupKey'); const hasTPM = protectorTypes.some((t) => t.startsWith('Tpm')); if (!hasTPM) return 'NoTPM -- not in scope of BitUnlocker'; if (hasPIN) return 'TPM+PIN -- defeats BitUnlocker entry vector'; return 'TPM-only -- vulnerable to BitUnlocker entry vector'; }

// Example: the default Windows 11 consumer configuration console.log(classifyProtectors(['Tpm', 'RecoveryPassword'])); // -> "TPM-only -- vulnerable to BitUnlocker entry vector" `}

If you genuinely cannot deploy TPM+PIN (kiosks running unattended, OT workloads, accessibility-driven exemptions), the partial mitigation stack is REVISE's dbx-revocation phase + firmware password + USB/PXE disabled in firmware + Kernel DMA Protection. Together these close the BitUnlocker entry vector on the patched code paths *and* the downgrade path *and* the firmware delivery channel. None of them changes the WinRE auto-unlock boundary -- only TPM+PIN does that -- so the next BitUnlocker-class CVE may still be exploitable on these devices until the corresponding patch ships. Treat this stack as a temporary mitigation, not a permanent answer.

None of these are new recommendations. The pre-boot PIN line in particular has been in the Microsoft Countermeasures page in some form since Vista [@ms-bitlocker-countermeasures]. What has changed is the operational consequence of not following it. BitUnlocker is what the consequence looks like today.

11. Frequently asked questions

BitUnlocker has produced a predictable list of misconceptions. Each question below names a common misconception about BitUnlocker and gives the correct framing -- because the wrong answers are where threat models get built quietly.

Yes against both -- the attack is upstream of the TPM seal, so the bus-elimination property of fTPM and Pluton does not help here. See §5.5 for the full mechanism and the contrast with TPM bus sniffing, which *does* fail against fTPM and Pluton because there is no exposed bus to sniff. No. BitUnlocker was *patched* on July 8, 2025 in KB5062553 [@kb5062553]. It was *disclosed* at Black Hat USA 2025 and DEF CON 33 in early August 2025, with the Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. Coordinated disclosure timelines mean the patch ships before the talk. Useful date to remember: KB5062553 = fix, August 2025 = public technical detail. Only against an attacker who cannot chain-load the pre-July-2025 `bootmgfw.efi`. Until REVISE / KB5025885 is deployed on a given device, the old signed boot manager remains trusted [@kb5025885] and the BitUnlocker entry vector remains usable from a USB stick. The patch closes the code paths in the new boot manager; the dbx update closes the old one's trust. They are different operations on different schedules. Yes against the BitUnlocker CVE class. A pre-boot PIN forces a human-presence check that WinRE structurally cannot satisfy from a boot-time recovery context. The Compass Security and SCRT TPM+PIN bypasses [@compass-2024] [@scrt-tpm-pin] are a separate, hardware-physical class that targets the bus between CPU and discrete TPM; they do not apply to fTPM or Pluton. For a TPM+PIN on Pluton or fTPM, none of the published attacks in this article succeed. No. The chain uses Microsoft-signed binaries throughout. The pre-patch `bootmgfw.efi` is Microsoft-signed under PCA 2011. `tttracer.exe`, `SetupPlatform.exe`, and the WinRE binaries inside the trust boundary are all Microsoft-signed. The bug class is logic flaws in the parsing of *unsigned data* (Boot.sdi, ReAgent.xml, BCD) by signed binaries. Secure Boot is doing exactly what it is designed to do; the boundary it enforces is not the boundary BitUnlocker crosses. No. Bitpixie scavenges the VMK from RAM via a soft-reboot bug in the pre-patch `bootmgfw.efi` (CVE-2023-21563, discovered August 2022 by Rairii, disclosed February 2023) [@neodyme-bitpixie]. BitUnlocker boots a malicious WinRE that inherits auto-unlock on the live volume. The shared structural pattern is that both are upstream of the TPM seal, both are defeated by TPM+PIN, and both work against fTPM and Pluton. The mechanism is different; the lesson is identical. STORM is the *Security Testing and Offensive Research at Microsoft* team -- Microsoft's internal red team. Alon Leviev, one of the BitUnlocker co-authors, also disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate]. The Downdate research showed that the Windows update pipeline could be coerced into installing older, vulnerable code paths. BitUnlocker is a different mechanism by the same researcher, one year later, on the recovery pipeline rather than the update pipeline.

The Shift+Restart chord ships in every copy of Windows. The recommendation that defeats it -- enable a pre-boot PIN -- has been on the Microsoft Countermeasures page since Vista. STORM's contribution is not that they found four bugs. It is that they made what happens when the recommendation is ignored impossible to look away from. The next move is the reader's.

To defend against malicious reset attacks, BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit. -- Microsoft Learn, BitLocker Countermeasures [@ms-bitlocker-countermeasures]

Measured Boot: The TCG Event Log from SRTM to PCR-Bound BitLocker

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

**Measured Boot is the system that lets Windows prove what code ran from power-on to logon.** A small immutable block called the CRTM measures the next stage, extending a SHA-256 digest into a TPM register (a PCR); each stage measures its successor, building a hash chain whose final value is uniquely determined by the entire ordered sequence of code that ran. BitLocker seals its Volume Master Key to a subset of those PCRs, so any unexpected change -- firmware update, Secure Boot key rotation, boot-manager swap -- forces a 48-digit recovery prompt. This article walks the chain event by event, explains why bitpixie (CVE-2023-21563) was unstoppable on TPM-only deployments, and gives you the six commands that turn the theory into a Monday-morning operational practice.

1. Two PCs That Hash Differently

At 06:00 on a Tuesday in March 2024, a senior administrator at a 500-seat law firm finishes patching her fleet of Dell OptiPlex 7090s overnight. At 08:42 she has answered her 173rd help-desk ticket, all variations on the same theme: Why is my laptop asking for a 48-digit BitLocker recovery key? The answer -- the answer the rest of this article exists to make obvious -- is that a single 32-byte SHA-256 register on every machine in her fleet now holds a different number than it did yesterday, and BitLocker's seal is bound to that number.

The patch she applied to make the fleet safer is the patch that locked it out.

Across town a second firm runs Secured-core PCs that ship with System Guard Secure Launch [@ms-learn-secured-core] enabled. Those machines absorb the same overnight UEFI delta without a single recovery prompt. Same vendor patch. Same Microsoft cumulative update. Same hour. Zero tickets. The difference is not the hardware; the difference is which subset of TPM registers BitLocker bound the disk-encryption key to.

A fixed-width append-only register inside a Trusted Platform Module. PCRs do not store; they *extend*. The TPM rewrites `PCR[N] := H(PCR[N] || measurement)`, where `H` is a cryptographic hash. PCRs reset to zero only at platform reset. A modern TPM 2.0 has 24 PCRs per hash bank, with banks for SHA-1, SHA-256, SHA-384, SHA-512, and SM3-256. A boot mode in which every stage of platform initialisation hashes the next stage's code and configuration into one or more PCRs *before* transferring control. Measured Boot is *reporting*, not *enforcement* -- it records what ran, but does not refuse to run anything. Secure Boot is the enforcement counterpart that refuses unsigned code; the two cooperate. Microsoft's `Trusted Boot` [@ms-learn-boot-process] extends the measurement chain into the Windows kernel.

By the end of this article you will be able to name every byte that went into that hash, predict whether any given administrative action will change it, and read the TCG event log on your own machine to confirm. You will see why the BitLocker seal is, in some configurations, a Faraday cage built on top of a fence the verifier never opened. You will learn that the chip Microsoft calls the Trusted Platform Module knows nothing of trust -- only of arithmetic over hashes -- and that the verifier, which knows what good looks like, is always someone other than the chip.

But first, the historical answer: how did a 32-byte register get into the position of deciding whether a PC boots cleanly or asks for a 48-digit key?

2. Origins: Arbaugh 1997 and the Chain-of-Hashes Axiom

The first paper to take the boot problem seriously is also one of the calmest. In 1997, three researchers at the University of Pennsylvania Distributed Systems Laboratory -- William A. Arbaugh, David J. Farber, and Jonathan M. Smith -- presented A Secure and Reliable Bootstrap Architecture [@aegis-1997] at the IEEE Symposium on Security and Privacy in Oakland. They opened with a line that ages disconcertingly well: "we find it surprising, given the great attention paid to operating system security that so little attention has been paid to the underpinnings required for secure operation, e.g., a secure bootstrapping phase for these operating systems."

They built a working prototype. A Pentium-class PC. A modified BIOS. A small PROM expansion card with public-key certificates. And, threaded through everything, an inductive structure they called AEGIS.

An ordered sequence in which each stage of platform initialisation verifies the cryptographic identity of the next stage *before* it executes. If every link verifies its successor, an external observer who trusts the first link transitively trusts the chain, modulo the cryptographic strength of the verification primitive.

AEGIS divided the boot into six levels (0 through 5). L0 was a small trusted ROM that ran the first POST phase, the signature-verification routines, and recovery code. L1 was the rest of the BIOS code plus CMOS. L2 was option-ROM expansion cards (the era's GPUs, network cards, SCSI controllers). L3 was the operating system boot block(s). L4 was the OS kernel. L5 was user programs and any network hosts the kernel reached. Each level verified the next before handing off; on a failed verification, L0 recovered the broken stage from a known-good network image. (The paper also presents a "four levels of abstraction" framing for one of its figures; the article uses the canonical six-level numbering.)

The smallest, lowest, most immutable code that runs after platform reset. It measures the next stage of firmware and extends that measurement into PCR[0] before transferring control. Modern PCs implement the CRTM in silicon -- Intel's Boot Guard Authenticated Code Module, AMD's Platform Security Processor firmware, or Microsoft's Pluton silicon -- because anything mutable is not actually a root of trust.

The architectural axiom that survived 28 years of evolution is this: there is always a bottom layer you cannot verify yourself. AEGIS does not eliminate that layer; it reduces trust to the smallest possible unverifiable thing. The L0 trusted ROM is the axiom; everything above it is provable from the axiom. Replace "trusted ROM" with "Boot Guard ACM" or "PSP boot ROM" or "Pluton silicon firmware" and the structure does not change.

AEGIS could not, on its own, make the next pivot. It had no hardware-rooted endorsement key. It had no append-only register that could not be lied to. It had no remote-attestation primitive -- the L0 ROM trusted itself, but an external auditor was forced to trust the BIOS's own report of the bootstrap. The trick AEGIS could not pull off is the trick the Trusted Computing Platform Alliance was about to attempt: make the root a chip.Arbaugh continued the work at the University of Maryland and later took a senior position at the National Security Agency. The bootstrap problem followed him; in 2005 he co-authored an early TPM-on-Linux survey that anticipates several of the PCR allocation conventions that PFP would formalise.

The TCPA was founded on October 11, 1999 [@wiki-tcg] by Compaq, Hewlett-Packard, IBM, Intel, and Microsoft. Its first specification [@wiki-tcg] shipped January 30, 2001. The first hardware-TPM-equipped PC shipped on the IBM ThinkPad T30 in 2002 [@wiki-tcg] (with a TPM 1.1-class Infineon SLB chip); the TPM 1.1b revision deployed in volume the year after. In 2003 the TCPA was reorganised as the Trusted Computing Group, with AMD joining as a founding board member.

The thing AEGIS could not do -- turn a chain of in-RAM hash comparisons into a record a remote party can trust -- is what the TPM became.

3. Early Approaches: TPM 1.1b, SHA-1, and the Original PCSI

"The first TPM version that was deployed was 1.1b in 2003" [@wiki-tpm] -- Wikipedia, drawing on the TCPA shipment record. A 24-pin chip in a tiny LPC-bus package, soldered to the motherboard of a ThinkPad T30. Sixteen PCRs. One hash bank: SHA-1, 20 bytes wide. A monotonic counter. An endorsement key, fused at manufacture. A storage root key, generated at first ownership. By 2010, hundreds of millions of business PCs shipped with one. By July 28, 2016, Microsoft's Windows 10 hardware logo programme required TPM 2.0 on every new OEM Windows 10 PC -- desktop, mobile, and server alike [@wiki-tpm].

The mechanic that did all the work is one operation: TPM_Extend. It takes a PCR index and a 20-byte digest. It produces a new PCR value defined as PCR[N] := SHA1(PCR[N] || digest).

The only writable mutation a TPM permits on a PCR. Given the current value `P` and a new measurement `M`, the TPM computes `H(P || M)` and writes the result back into the PCR. There is no `set`; there is no `clear` (PCRs reset only at platform reset, and some PCRs not even then). The hash chain is the *only* trace.

That two-letter primitive -- extend -- is doing more cryptographic work than its size suggests. A PCR is not a set of measurements; it is a sequence. If three boot stages measure three values a, b, c into PCR[0] in that order, the resulting PCR encodes H(H(H(0 || a) || b) || c). Reorder the stages and the final hash differs. Repeat a stage and the final hash differs. Skip a stage -- the move every rootkit dreams of -- and the final hash differs. Under collision-resistance of the underlying hash, producing the same final PCR via a different ordered sequence is computationally infeasible.

A naive design might use the PCR as a set: write each measurement into a separate slot, and let the verifier check that the set matches a known-good baseline. That design has two pathologies. First, an attacker who controls one stage can simply *not* report its measurement and let the verifier see a smaller set than ran. Second, order doesn't matter to a set; an attacker can rearrange the stages and slip a measured-but-vulnerable component in early, where its measurement still "matches" the baseline.

Extend solves both. You cannot omit a stage without changing the final hash. You cannot reorder. You cannot insert. The cost is that the verifier cannot read the PCR as a list of measurements -- it has to be given the list (the TCG event log) separately and re-derive the final PCR by replaying the extends. This is the trade we'll meet in Section 8 as a fundamental limit.

The PC Client Specific Implementation (PCSI) specification carved up the 24 PCRs of TPM 1.2 into eight indices that the world still uses today. PCR[0] holds the CRTM, the system firmware code, and the firmware host platform extensions. PCR[1] holds the host platform configuration (CMOS settings that change platform behaviour). PCR[2] holds the option ROM code. PCR[3] holds the option ROM configuration. PCR[4] holds the master boot record code (and on UEFI machines, the boot-loader image). PCR[5] holds the master boot record partition table (and on UEFI machines, the boot configuration). PCR[6] holds host platform manufacturer-specific events. PCR[7] holds host platform manufacturer events -- a category that, post-PFP, became Secure Boot policy.

A group of PCRs that share a hash algorithm. TPM 1.2 had one bank only (SHA-1). TPM 2.0 supports multiple banks simultaneously -- the same PCR index exists once per bank, with one digest per bank. A measurement into PCR[7] writes the same source bytes into every bank but produces algorithm-specific digests.

TPM 1.2 also defined the first remote-attestation primitive in industry hardware: TPM_Quote. The TPM signs a snapshot of selected PCR values plus a verifier-supplied nonce with a private key the chip alone holds (the attestation identity key, signed by a TCG-managed privacy CA). The verifier checks the signature, checks the nonce, checks the AIK certificate chain, and re-derives the expected PCR set from a TCG event log delivered separately. If the re-derivation matches the signed quote, the platform's boot history is authenticated.

It worked. For a while. Then, on February 23, 2017, the SHAttered team -- Marc Stevens (CWI Amsterdam) and Pierre Karpman (Inria) with Elie Bursztein, Ange Albertini, and Yarik Markov (Google Research) -- published the first public SHA-1 collision [@wiki-sha1]. Two PDF files with identical SHA-1 hashes. The collision cost about 110 GPU-years of compute [@wiki-sha1]. The implication for TPM 1.2 was immediate: a 20-byte SHA-1 PCR can no longer be assumed unique under attacker-controlled input.The SHA-1 choice in 2003 was state-of-the-art at the time, not negligence. NIST's SHA-256 had been published in 2001 but was not yet broadly trusted; SHA-1 was the IETF-blessed default for X.509 and many TLS deployments. The SHAttered collision required compute that did not exist commercially in 2003. By 2017 it required compute that anyone with a Google Cloud account could buy.

If the cryptographic floor is broken and you cannot re-floor in place -- a TPM 1.2 chip cannot grow a SHA-256 bank [@wiki-tpm] -- you replace the floor with one that can be moved. That is what TPM 2.0 became.

4. Evolution: TPM 2.0, Hash Agility, and the UEFI PFP

On April 9, 2014, the Trusted Computing Group announced the TPM Library Specification 2.0 [@wiki-tpm]. ISO ratified the result the following year as ISO/IEC 11889-1:2015 [@iso-11889-1-2015], and confirmed the standard as current in a 2021 review. The change set is large -- new algorithm framework, NV index ACLs, sessions, command authorization area, ECC primary keys -- but the line that matters for measurement is the simplest one: PCRs now exist in banks.

A property of a security system that lets operators or vendors replace one hash function with another without changing the system's interfaces. TPM 2.0 implements hash agility for PCRs (multiple banks), HMAC keys (algorithm parameter on the key), and signature primitives (algorithm parameter on the signature). Hash agility is not free: every bank costs storage, every bank costs extend cost, and the verifier must agree with the prover on which bank to use.

A TPM 2.0 chip can run a SHA-1 bank, a SHA-256 bank, and (often) a SHA-384 bank in parallel, plus optional SHA-512 and SM3-256. The same PCR index lives once per bank. A TPM2_PCR_Extend call updates every active bank with bank-specific digests; the source bytes are identical but the output is per-algorithm. TPM2_PCR_Allocate reconfigures the bank set at runtime, gated by platform authorization.

The event log structure had to grow with the chip. The pre-2014 log format -- TCG_PCR_EVENT, single SHA-1 digest -- could not carry per-bank digests. The PC Client PFP defined a new structure, TCG_PCR_EVENT2. From Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log], the wire format is:

typedef struct {
    TCG_PCRINDEX        PCRIndex;
    TCG_EVENTTYPE       EventType;
    TPML_DIGEST_VALUES  Digests;
    UINT32              EventSize;
    UINT8               Event[EventSize];
} TCG_PCR_EVENT2;

typedef struct {
    UINT32   Count;
    TPMT_HA  Digests;  // Count copies, one per bank
} TPML_DIGEST_VALUES;

typedef struct {
    UINT16  HashAlg;
    UINT8   Digest[size_varies_with_algorithm];
} TPMT_HA;

An in-RAM ordered list of `TCG_PCR_EVENT2` records, populated by firmware and OS components in the exact order they extend digests into PCRs. The log is *unsigned* -- only the PCR values are signed when the verifier later requests a quote. A verifier replays the log to re-derive the PCR values and accepts the log if the re-derivation matches the signed quote. The multi-bank digest container inside `TCG_PCR_EVENT2`. It holds a `Count` of `TPMT_HA` records, each carrying a hash-algorithm identifier (`HashAlg`, a TPM_ALG_ID) and the corresponding digest. A modern Windows log on a SHA-256-and-SHA-1 dual-bank TPM emits `Count = 2` per event with both digests of the same source bytes.

The very first event in a TPM-2.0-format log is, deliberately, a TPM-1.2-format record. From Microsoft Learn verbatim [@ms-tbs-get-tcg-log]: "The Signature member of the TCG_EfiSpecIdEventStruct structure is set to a null-terminated ASCII string of \"Spec ID Event03\"". That string is the self-describing handshake: a parser that doesn't know about banks reads the legacy event and either understands it (continuing as a 1.2 parser) or recognises the Spec ID handshake (and upgrades to the 2.0 parser). The cost of forward compatibility is precisely one event.The "Event03" suffix is not a typo. The TCG PC Client Platform Firmware Profile defines TCG_EfiSpecIDEventStruct with Signature[16] containing the ASCII string and a specVersionMajor/specVersionMinor/specErrata triplet. The "03" denotes the third revision of the format. Earlier "Spec ID Event02" structures exist in pre-1.21 PFP firmware; they encode banks differently and are extremely rare in Windows-era machines.

The bridge between the chip and the firmware is a UEFI protocol. EFI_TCG2_PROTOCOL [@uefi-org-specs] (UEFI 2.5 and later) exposes three calls that matter: HashLogExtendEvent (the one-shot "hash this blob, log it, extend the PCR" call), GetEventLog (return the in-progress event log to a caller), and GetCapability (which banks are active, which algorithms are supported). After ExitBootServices, the firmware publishes the final log as a UEFI configuration table; the OS reads it from there.

The Microsoft PFP-era PCR allocation is the table every modern Windows administrator should memorise.

PCR	TCG PFP definition	Microsoft WBCL convention	Linux IMA / shim convention
0	SRTM, BIOS, host platform extensions, embedded option ROMs	Firmware version (`EV_S_CRTM_VERSION`); platform firmware blob	Same
1	Host platform configuration	BIOS setup data	Same
2	UEFI driver and application code (option ROMs)	Pluggable option ROM code	Same
3	UEFI driver and application configuration	Option ROM data	Same
4	UEFI boot manager and boot attempts	`EV_EFI_BOOT_SERVICES_APPLICATION` for `bootmgfw.efi`	Same (shim/grub image)
5	Boot manager code and boot attempts	Boot partition GPT, EFI variables loaded by boot manager	Same
6	Host platform manufacturer events	Wake reason, S-state events	Same
7	Secure Boot policy	`SecureBoot`/`PK`/`KEK`/`db`/`dbx` variable digests	Same
8-9	OS-loader reserved	Unused on Windows	Linux kernel measurement (some distros)
10	OS-loader reserved	Unused on Windows	IMA file measurements (canonical)
11	OS-loader reserved	Microsoft WBCL events (BitLocker control PCR)	Unused
12	OS-loader reserved	Boot environment configuration	Unused
13	OS-loader reserved	ELAM driver hash and policy	Unused
14	OS-loader reserved	Boot-loader-authority events	shim MOK certificate enrolment
15	OS-loader reserved	Reserved	Reserved
16	Debug	Used during development	Same
17-22	Dynamic OS (DRTM use only)	Secure Launch, Authenticated Code Module	TrenchBoot, tboot
23	Application support	Reserved	Reserved

A small word on the index column: a 24-PCR TPM ranges from PCR[0] to PCR[23].The PFP allocates PCR[16] as a debug index that platform firmware may extend during development; the value resets to zero at TPM_Init, which is one of two PCRs (the other is PCR[23]) the platform may explicitly reset. Older PCSI-era documentation sometimes refers to PCR[24]; that is a historical artifact of an unsanctioned Infineon extension and is not part of the modern PFP allocation. The allocation itself is normative in the PFP, but it sits inside a wider policy frame: NIST SP 800-155 (BIOS Integrity Measurement Guidelines, December 2011 IPD) [@csrc-sp800-155-pdf] defined the federal procurement bar for "BIOS integrity measurement" -- a draft that, despite never finalising, became the de-facto procurement template for the SRTM measurement chain U.S. agencies require their suppliers to ship.

Note: If you click the canonical TPM 2.0 Library Specification link [@tcg-tpm-library] or the PC Client PFP link [@tcg-pfp], the trustedcomputinggroup.org host returns HTTP 403 to non-browser User-Agents and to some browser fingerprints. The specifications exist and are normative; we cite them by canonical URL. For verbatim struct definitions and the "Spec ID Event03" string, Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log] reproduces them word-for-word; Wikipedia's TPM article [@wiki-tpm] corroborates the spec metadata.

gantt dateFormat YYYY title Five generations of measured boot section Generation 1 AEGIS at UPenn (Arbaugh 1997) :a1, 1997, 1y section Generation 2 TCPA founded (1999) / TPM 1.1b (2003) :a2, 1999, 11y TPM 1.2 PCSI defines PCR[0-7] :a3, after a2, 11y section Generation 3 TPM 2.0 announced (April 9, 2014) :a4, 2014, 12y ISO/IEC 11889 (2015) / Hash agility :a5, 2015, 11y section Generation 4 Intel TXT GETSEC[SENTER] (2007) :a6, 2007, 19y Microsoft Secure Launch (Win10 1809) :a7, 2018, 8y section Generation 5 Azure Attestation / Intune DHA :a8, 2018, 8y PFP r2 / ML-DSA in flight :a9, 2025, 1y

We now have a self-describing log, a hash-agile PCR set, and a verbatim ABI. Who actually writes the log? And who reads it?

5. The Breakthrough: One Log, Many Consumers

Every trust decision a modern Windows machine makes about its own boot ultimately consults the same record. BitLocker's seal release. Windows Defender System Guard runtime attestation [@ms-learn-sgsl]. Windows Hello for Business device-bound key attestation. Microsoft Azure Attestation [@ms-aa-overview] policy evaluation. Microsoft Intune Device Health Attestation. Conditional Access posture checks. All of them, ultimately, read the TCG event log -- and the PCR snapshot it replays into. One log; every feature.

This is the article's structural insight. It is also the reason this specification has survived three generations of attacks: the cost of designing a new attestation feature on Windows is no longer "design a new measurement plane," it is "decide which PCRs your policy cares about."

Key idea: One log, many consumers. Every Windows trust decision about boot integrity -- BitLocker unseal, System Guard attestation, Hello for Business key attestation, Azure Attestation, Intune Device Health Attestation, Conditional Access -- ultimately consults the same TCG event log and the PCR snapshot it replays into. The cost of adding a new attestation feature is not a new measurement plane; it is a policy decision about which PCRs matter.

One log, every feature.

The cooperative writers populate the log in pipeline order, following the Microsoft Tbsi_Get_TCG_Log PCR allocation [@ms-tbs-get-tcg-log]. Firmware -- the silicon root of trust and everything above it through the UEFI driver execution environment -- writes PCRs 0 through 7. The Microsoft boot manager bootmgfw.efi writes additional events into PCRs 4, 11, and 12. The Windows OS loader winload.efi writes into PCRs 11 and 13. Into PCR 13 specifically, winload.efi writes the ELAM policy hash and the ELAM driver writes its own image digest (§6.5 walks the full PCR[13] cooperative sequence). The Windows kernel emits a EV_SEPARATOR event on every measured PCR once the boot-time measurement phase is complete, freezing the boot-time slice of the log for verifiers.

The unified reader path mirrors the writer fan-in. EFI_TCG2_PROTOCOL.GetEventLog exposes the main log to firmware drivers and applications before ExitBootServices; events measured after that call are published separately through the EFI_TCG2_FINAL_EVENTS_TABLE configuration table. Windows reads both during boot and exposes the merged log -- the firmware portion plus the OS-loader extensions -- to user mode through Tbsi_Get_TCG_Log [@ms-tbs-get-tcg-log]. Operators read it with the inbox tpmtool.exe or cross-platform tpm2_eventlog [@gh-tpm2-eventlog-man]; §6.7 walks the full tool set.

flowchart TD subgraph FW["Firmware (CRTM / PEI / DXE / BDS)"] F0["PCR[0]: CRTM, firmware blob"] F1["PCR[1]: BIOS setup"] F2["PCR[2]: option ROMs"] F3["PCR[3]: option ROM config"] F5["PCR[5]: GPT, EFI vars"] F6["PCR[6]: wake reason"] F7["PCR[7]: Secure Boot policy"] end subgraph BM["bootmgfw.efi"] B4["PCR[4]: boot mgr image (Authenticode)"] B11A["PCR[11]: WBCL boot mgr events"] B12["PCR[12]: boot config"] end subgraph WL["winload.efi"] W11["PCR[11]: kernel, HAL, boot-critical drivers"] W13A["PCR[13]: ELAM policy hash"] end subgraph ELAM["ELAM driver"] E13["PCR[13]: ELAM driver hash"] end subgraph K["Windows kernel"] SEP["EV_SEPARATOR on every measured PCR (freeze)"] end FW --> BM --> WL --> ELAM --> K

A single canonical log eliminates per-feature reinvention. Azure Attestation does not have to parse a different log than BitLocker. Hello for Business does not have to extend its own PCRs. The verifier community -- the part that knows what "good" means -- builds policies on top of one shared substrate.

We have named the log abstractly. What does an actual event look like, byte by byte, on the wire?

6. State of the Art: A Line-by-Line Walk Through the SRTM Chain

This is the section the practitioner audience came for. We walk the chain in the exact order events are logged on a modern UEFI Windows 11 24H2 machine. Reference: a Dell OptiPlex 7090 with Boot Guard, TPM 2.0 in SHA-256-only mode, Secure Boot enabled, BitLocker with TPM-only protector bound to the PFP-default UEFI profile.

The first measured event, after the initial EV_NO_ACTION Spec ID record described above, is a EV_S_CRTM_VERSION record. PCR index 0. Event type 0x00000008. Two SHA-256 digests (one per active bank if SHA-1 is also enabled). Event size 8. Event data: a little-endian UTF-16 string containing the firmware version, padded to 8 bytes. The CRTM extends its own version into PCR[0] before measuring anything else. This is the foundation event.

6.1 The CRTM and PCR[0]

The very first instruction the CPU fetches after reset is not in DRAM. On a modern x86, it is in an immutable silicon region whose location and contents differ by silicon vendor.

On AMD Zen-class platforms, the Platform Security Processor -- a 32-bit ARM core inside the SOC -- boots first, validates the platform firmware against a key fused into silicon, and only then releases the x86 cores from reset. On Intel platforms with Boot Guard, the Authenticated Code Module is loaded from firmware into the cache-as-RAM region, signed by a key whose hash is fused into Intel chipset OTP fuses, and verified by microcode before x86 main core start. On Microsoft Pluton SKUs, the Pluton silicon firmware runs first; on AMD Ryzen 6000-series and later parts with Pluton enabled, Pluton is implemented as a Microsoft-co-designed firmware mode running on the existing AMD PSP coprocessor, not as a separate chip.

In every case, that silicon-rooted CRTM measures the next stage of firmware before transferring control. From Microsoft's hardware-rooted trust documentation [@ms-learn-hwrot], verbatim: "This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM)." The SRTM extends PCR[0] with a chain of three early events: EV_S_CRTM_VERSION (firmware version), EV_S_CRTM_CONTENTS (the immutable CRTM code hash), and EV_POST_CODE (the POST code region hash). Then, if the platform has a separable firmware volume, an EV_EFI_PLATFORM_FIRMWARE_BLOB event covers the rest of the SPI flash region per the TCG PFP event-type registry surfaced in Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log]. The PFP closes PCR[0] with an EV_SEPARATOR event at the BDS boundary.

Where the firmware-version string differs, the SHA-256 digest of the EV_S_CRTM_VERSION event data differs. Where the EV_S_CRTM_VERSION digest differs, PCR[0] differs. That is the entire mechanism by which an overnight UEFI patch changes PCR[0]. Dell updated the firmware string from "1.16.0" to "1.17.0"; the bytes hashed; the PCR moved; the seal broke.

6.2 PEI/DXE, option ROMs, and PCR[1-3]

After the CRTM hands off, the Pre-EFI Initialisation (PEI) phase runs and the Driver Execution Environment (DXE) phase loads UEFI drivers. PEI does early silicon initialisation -- memory controller, cache topology, basic chipset config -- and DXE does device discovery, including option ROMs for plug-in cards.

Each option ROM that runs is measured into PCR[2]. The option ROM's configuration -- card-specific NVRAM state that survives reboot -- is measured into PCR[3]. The PFP also reserves PCR[1] for the platform configuration: CMOS settings, the SMBIOS table contents, and any BIOS-setup-visible knob that affects platform behaviour per the PCR-allocation mapping surfaced in Microsoft's Tbsi_Get_TCG_Log documentation [@ms-tbs-get-tcg-log]. Changing your boot order in BIOS setup changes PCR[1]. Disabling a USB controller in firmware changes PCR[1]. Installing a discrete GPU adds an EV_EFI_BOOT_SERVICES_DRIVER event into PCR[2] for the GPU's video BIOS.

6.3 Secure Boot variables and PCR[7]

PCR[7] is the Secure Boot policy PCR. It records the digests of the four variables that define Secure Boot identity -- SecureBoot (the on/off flag), PK (Platform Key), KEK (Key Exchange Key), db (allowed signers), and dbx (revocation list) -- plus any signed program execution events the firmware logs to PCR[7] under EV_EFI_VARIABLE_AUTHORITY [@gh-wack0-bitlocker].

Each variable contributes one EV_EFI_VARIABLE_DRIVER_CONFIG event whose Event field encodes (VariableName GUID, UnicodeName, VariableDataLength, VariableData) and whose digest is the SHA-256 of that entire structure. The digest is not over the variable data alone; it is over the GUID and name as well. This matters: when the May 2023 Microsoft dbx update shipped under KB5025885 [@ms-kb5025885] added the BlackLotus-vulnerable boot manager hashes to the revocation list, the variable data length grew, the structure changed, and the resulting EV_EFI_VARIABLE_DRIVER_CONFIG digest differed. Every UEFI Windows machine on Earth that consumed that dbx update saw PCR[7] move.

From the Wack0/bitlocker-attacks index [@gh-wack0-bitlocker], reproducing TCG EFI Platform Specification §6.4 verbatim: "If the platform provides a firmware debugger mode which may be used prior to the UEFI environment or if the platform provides a debugger for the UEFI environment, then the platform SHALL extend an EV_EFI_ACTION event into PCR[7] before allowing use of the debugger". The intent is clear: a debugged firmware is a different PCR[7] than a production firmware. The verifier can refuse to release a key to a debugged platform.

6.4 Boot manager (bootmgfw.efi) and PCR[4] + PCR[11]

The UEFI Boot Device Selection (BDS) phase locates EFI/Microsoft/Boot/bootmgfw.efi on the EFI System Partition, computes its Authenticode digest, verifies the Authenticode signature against db and dbx, logs an EV_EFI_BOOT_SERVICES_APPLICATION event into PCR[4] with that digest, and transfers control. PCR[4] now binds to the boot manager's image content. A different boot manager binary -- a different version, a different language pack -- produces a different PCR[4].

Microsoft's Portable Executable signature format. The Authenticode digest is computed over the PE image *excluding* fields the loader rewrites (file offset bytes, the checksum field, the digital-signature pointer). Authenticode is not the same as a SHA-256 over the file -- two byte-identical .exe files can have different SHA-256 but the same Authenticode digest, and vice versa. Boot Guard, Secure Boot, and PCR[4] all hash the Authenticode digest, not the raw file.

Once bootmgfw.efi runs, it extends its own events into PCR[11]. These are Microsoft-specific Windows Boot Configuration Log (WBCL) records, not generic TCG events. They include the BCD store contents, the boot-environment configuration, and Microsoft-private telemetry about the boot manager's policy decisions. PCR[11] is the BitLocker control PCR -- the index that captures Windows-side boot-time configuration.

The Microsoft-specific extension of the TCG event log carrying boot-manager, loader, and ELAM events. WBCL events use the TCG `EV_EVENT_TAG` event type with Microsoft-private sub-types. They are extended into PCR[11], PCR[12], and PCR[13]. WBCL is exposed by `Tbsi_Get_TCG_Log_Ex` and is what `tpmtool.exe getdeviceinformation` actually parses.

6.5 winload.efi and the ELAM handoff

bootmgfw.efi chains to winload.efi, the OS loader. winload measures the Windows kernel image (ntoskrnl.exe), the Hardware Abstraction Layer (hal.dll), the OS configuration data (the boot manager's view of boot-critical drivers), and each boot-critical driver in load order -- each into PCR[11] as a WBCL record. The kernel binary itself is part of that chain; a kernel update changes PCR[11].

The Early Launch Anti-Malware (ELAM) interface gives a vendor anti-malware driver a chance to run before all other drivers and approve or block subsequent driver load attempts. winload measures the ELAM policy file hash into PCR[13]; the ELAM driver, when loaded, extends its own image digest into PCR[13]; the ELAM driver then returns its allow/deny verdict on each subsequent driver, and winload logs those verdicts (also into PCR[13] under WBCL EV_EVENT_TAG).

6.6 Kernel and the final separator

Once the Windows kernel starts, it exposes the TCG event log through the TPM Base Services driver Tbs.sys, which is consumed by Win32 callers through Tbsi_Get_TCG_Log. The kernel emits a EV_SEPARATOR event into every measured PCR -- the "ready-to-boot" marker. After the separator, no further measured-boot events occur for the current boot session. The WBCL is frozen. A verifier reading the log at this point sees the complete boot history.

6.7 Reading the log from user mode

On a Windows 11 24H2 machine, the simplest way to read the log is tpmtool.exe getdeviceinformation from an elevated prompt -- it prints the parsed WBCL plus the current PCR values. For the raw binary log, Get-TpmEndorsementKeyInfo from PowerShell returns the EK chain, and MeasuredBootTool.exe -log <path> from the Windows HLK kit returns the raw binary log file written under C:\Windows\Logs\MeasuredBoot\*.log.

Cross-platform, tpm2_eventlog [@gh-tpm2-eventlog-man] from the tpm2-tools suite [@gh-tpm2-tools] parses any binary log conforming to the PC Client PFP -- including Windows-saved logs, because the WBCL extension is structurally compatible. The man page is precise: "tpm2_eventlog(1) -- Parse a binary TPM2 event log... The format of this log documented in the 'TCG PC Client Platform Firmware Profile Specification'." On Linux, the firmware-published log lives at /sys/kernel/security/tpm0/binary_bios_measurements.

{` // Simulate three iterative SHA-256 extends into a single PCR. // Initial PCR is 32 zero bytes. Each extend: PCR := SHA256(PCR || measurement).

async function sha256(buffer) { const hash = await crypto.subtle.digest('SHA-256', buffer); return new Uint8Array(hash); }

function concat(a, b) { const out = new Uint8Array(a.length + b.length); out.set(a, 0); out.set(b, a.length); return out; }

function toHex(arr) { return Array.from(arr).map(b => b.toString(16).padStart(2, '0')).join(''); }

async function extendChain(measurements) { let pcr = new Uint8Array(32); // 32 zero bytes for (const m of measurements) { pcr = await sha256(concat(pcr, m)); } return toHex(pcr); }

const a = new TextEncoder().encode('firmware-v1.16'); const b = new TextEncoder().encode('bootmgfw-2024-03'); const c = new TextEncoder().encode('winload-26100.123');

(async () => { const abc = await extendChain([a, b, c]); const cba = await extendChain([c, b, a]); console.log('PCR after a,b,c =', abc); console.log('PCR after c,b,a =', cba); console.log('Same value?', abc === cba); })(); `}

Run that snippet and you will see two completely different 32-byte hex strings. The PCR encodes the order. A verifier comparing your machine's PCR[11] against a known-good baseline is implicitly checking that the kernel, the HAL, and the boot-critical drivers all loaded in the expected sequence -- not just that they all loaded. Reorder the chain, even with identical inputs, and the PCR moves. This is the property that makes the chain-of-hashes axiom load-bearing.

6.8 The PCR allocation cheat sheet

Pin the table from Section 4 to your wall. Most operational questions reduce to "which PCR is affected by this change, and is it in my BitLocker profile?" Three quick rules:

Code changes go to even PCRs (0, 2, 4). Firmware blob, option ROM, boot manager. A firmware update moves PCR[0]; a discrete GPU swap moves PCR[2]; a boot-manager update moves PCR[4].
Configuration changes go to odd PCRs (1, 3, 5). BIOS setup, option ROM config, EFI variables seen by the boot manager.
Policy and identity go to PCR[7]. Secure Boot keys. Any dbx update moves PCR[7]. Disabling Secure Boot moves PCR[7]. Enrolling third-party db entries moves PCR[7].

PCR[11] is the OS-loader code chain on Windows (kernel, HAL, boot drivers). PCR[13] is the ELAM policy and driver. PCR[14] is, by Microsoft convention, boot-loader-authority events; by Linux shim convention, MOK enrolment. Same index; different ontology. Verifiers must pick a side.

6.9 BitLocker seal-binding

BitLocker's Volume Master Key is wrapped by a TPM-resident sealed blob whose policy is TPM2_PolicyPCR over a chosen PCR profile. The default UEFI profile is the bitmask 0x00000080 | 0x00000800 = 0x880 -- that is PCR[7] (bit 7 = 0x80) plus PCR[11] (bit 11 = 0x800) -- as documented in the BitLocker Group Policy reference [@ms-learn-bitlocker-gpo], which notes verbatim that "when Secure Boot State (PCR7) support is available, the default platform validation profile secures the encryption key using Secure Boot State (PCR 7) and the BitLocker access control (PCR 11)." The legacy CSM/BIOS profile is 0x00000015 | 0x00000800 = 0x815 -- that is PCR[0], PCR[2], PCR[4], plus PCR[11].

At seal time (when BitLocker enables, or when a user changes the protector configuration), the TPM records the current PCR values into the policy. At every subsequent boot, the boot manager rebuilds the session, calls TPM2_PolicyPCR with the current PCR values, and calls TPM2_Unseal. If the current PCRs match the seal-time digest, the TPM releases the VMK and BitLocker unlocks transparently. If they don't match, the TPM refuses and Windows prompts for the 48-digit recovery key.

From Microsoft's BitLocker countermeasures documentation [@ms-learn-bitlocker-counter]: "By default, BitLocker provides integrity protection for Secure Boot by using the TPM PCR[7] measurement. An unauthorized EFI firmware, EFI boot application, or bootloader can't run and acquire the BitLocker key". The PCR[7]-default choice is deliberate: PCR[7] is the policy PCR, not the code PCR. Firmware updates don't change a Secure-Boot-policy hash; only key-database updates do.

sequenceDiagram participant Firmware participant BootMgr as bootmgfw.efi participant TPM participant Winload as winload.efi Firmware->>TPM: TPM2_PCR_Extend (PCR[0-7]) BootMgr->>TPM: TPM2_PCR_Extend (PCR[4], PCR[11], PCR[12]) BootMgr->>TPM: TPM2_StartAuthSession BootMgr->>TPM: TPM2_PolicyPCR (selection = current profile) BootMgr->>TPM: TPM2_Unseal (sealed VMK blob) alt PCRs match seal-time digest TPM-->>BootMgr: VMK plaintext BootMgr->>Winload: hand off, VMK in protected memory Winload-->>Firmware: continue boot else PCRs do not match TPM-->>BootMgr: TPM_RC_POLICY_FAIL BootMgr-->>BootMgr: prompt for 48-digit recovery key end

The on-disk registry path that records the profile choice is HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI [@ms-learn-bitlocker-gpo]. The value is a 24-bit bitmask where bit N selects PCR[N]. A device that sealed under the default 0x880 profile and then has Group Policy changed to 0x815 will not automatically re-seal -- you must explicitly disable and re-enable the TPM protector with manage-bde -protectors [@ms-manage-bde-protectors] to rotate the policy.

A small utility decodes the bitmask:

{` function decodeProfile(mask) { const selected = []; for (let bit = 0; bit < 24; bit++) { if (mask & (1 << bit)) selected.push(bit); } return selected; }

console.log('Default UEFI profile (0x880):', decodeProfile(0x880)); console.log('Legacy CSM profile (0x815): ', decodeProfile(0x815)); console.log('A more restrictive profile (0x8D5):', decodeProfile(0x8D5));

// Output: // Default UEFI profile (0x880): [7, 11] (PCR[7]+PCR[11]) // Legacy CSM profile (0x815): [0, 2, 4, 11] (PCR[0]+PCR[2]+PCR[4]+PCR[11]) // A more restrictive profile (0x8D5): [0, 2, 4, 6, 7, 11] `}

Run it. Your machine's profile mask is one of those three (or close enough). If the mask includes PCR[0], every firmware update will trigger a recovery prompt. If it omits PCR[0] but includes PCR[7], only Secure Boot key changes (Microsoft's annual dbx updates, third-party Linux enrolments, BIOS-setup Secure Boot toggles) will. The four canonical recovery-prompt causes follow directly:

Cause	PCR affected	Mitigation
UEFI firmware update	PCR[0]	Suspend BitLocker before update; legacy profile only
Microsoft `dbx` update or Secure Boot key rotation	PCR[7]	Suspend BitLocker before patch Tuesday
Boot-manager binary swap (KB-driven update)	PCR[4], PCR[11]	Suspend BitLocker before cumulative update
Firmware setup change (virtualization toggle, device enable/disable)	PCR[1]	Suspend BitLocker before deliberate change

We have walked the chain. What about the chain we cannot trust -- the OEM-vendor-firmware-allowlist explosion that overwhelms remote verifiers?

7. Competing Approaches: DRTM, Late Launch, and Secure Launch

A quote from Microsoft's hardware-root-of-trust documentation [@ms-learn-hwrot] frames the problem precisely: "As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup. Two techniques exist to establish trust here -- either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist)."

The allowlist explodes. Every OEM, every model, every firmware revision, every Secure Boot key generation produces a fresh PCR[0]/PCR[7]/PCR[11] tuple. A central verifier that wants to assert "this fleet booted firmware Microsoft has signed off on" has to maintain a database whose cardinality grows quadratically in (vendors x firmware versions). By 2017 the table size made the verifier policy ungovernable for general-purpose Windows fleets.

The fix is structural: introduce a second measurement plane that does not depend on the OEM. From the same Microsoft document: "System Guard Secure Launch, first introduced in Windows 10 version 1809, aims to alleviate these issues by using a technology known as the Dynamic Root of Trust for Measurement (DRTM)." And: "Secure Launch simplifies management of SRTM measurements because the launch code is now unrelated to a specific hardware configuration."

DRTM is a CPU primitive. On Intel, it is GETSEC[SENTER], introduced with Trusted Execution Technology in 2007. From the Intel SDM mirror, verbatim: "GETSEC[SENTER] / Launch a measured environment. EBX holds the SINIT authenticated code module physical base address. ECX holds the SINIT authenticated code module size (bytes)." On AMD, the equivalent is the SKINIT instruction from the AMD-V (SVM) family, introduced with the first AMD-V silicon in 2005-2006 [@wiki-x86-virt]. Microsoft's Secure Launch implementation [@ms-learn-sgsl] issues SENTER or SKINIT from a small Secure Kernel Loader (SKL) inside winload.efi.

What SENTER and SKINIT do, at machine level, is roughly identical: they suspend all but one CPU, reset PCRs 17 through 22 in the TPM to a defined value (zero for SHA-256, all-ones for SHA-1 historically; the SHA-256 reset value is UNVERIFIED_FETCH -- the TCG PFP returns HTTP 403 to non-browser agents), load the launch module (Intel verifies the signature on its SINIT Authenticated Code Module; AMD measures its Secure Loader Block rather than checking a signature), and atomically transfer control to it with interrupts disabled and the IOMMU active. The ACM/SLB's measurement gets extended into PCR[17]; the Measured Launch Environment (MLE) it loads -- on Windows, the Hyper-V hypervisor and the secure kernel -- gets extended into PCR[18].

The code body that the DRTM primitive ($SENTER$/$SKINIT$) measures into PCR[18] after the Authenticated Code Module (Intel) or Secure Loader Block (AMD) has been measured into PCR[17] and verified. On Microsoft Secure Launch, the MLE is the hypervisor plus the secure kernel. On Linux+TrenchBoot, the MLE is the GRUB late-launch component plus the kernel.

The reason SENTER and SKINIT matter, beyond the resetting of PCRs 17-22, is what they don't measure. They do not measure the PEI/DXE firmware. They do not measure option ROMs. They do not measure the entire SRTM trail in PCRs 0-7. A verifier that consumes only PCRs 17-22 sees a uniform digest across every Intel platform (because every Intel platform runs the same Intel-signed ACM) and every Microsoft Secure-Launch-capable system (because every such system runs the same Microsoft-signed SKL). The OEM diversity is absorbed by ignoring the diverse measurements.

The Rutkowska / Wojtczuk SMM attack and the DRTM preconditions

Before SENTER could be trusted, it had to survive a DMA attack class that Joanna Rutkowska and Rafal Wojtczuk demonstrated at Black Hat DC 2009 [@itl-attacking-txt-2009]. Their paper's abstract is direct: "We describe a practical attack that is capable of bypassing the TXT's trusted boot process". The mechanism: between the signature check on the SINIT ACM and its execution, a DMA-capable peripheral could overwrite the verified payload. Intel's response was architectural -- route SINIT through IOMMU-protected memory, and refuse to start SENTER if the IOMMU is not on. The fix is enforced at the instruction level: the SDM mirror's GETSEC[SENTER] description lists the chipset and TPM preconditions GETSEC[SENTER] now checks before opening the measured-launch window. Every modern DRTM design rests on the assumption that the IOMMU is active at the late-launch instant.

DRTM does not replace SRTM; it layers on top. SRTM still measures everything pre-late-launch into PCRs 0-7 and 11-14. DRTM resets a separate slice (PCRs 17-22) and starts fresh. A verifier that wants the small OEM-invariant TCB consumes the DRTM slice and ignores PCRs 0-16. A verifier that wants the full pre-late-launch history consumes the SRTM slice and ignores 17-22. A verifier that wants both -- say, "the firmware was on the allowlist *and* the secure kernel started cleanly" -- consumes both. The cost is one extra `TPM2_Quote` selection mask. The benefit is that you can change attestation policy without changing the measurement plane.

Microsoft Secure Launch and the Secured-Core PC bar

Microsoft's Secured-core PC programme [@ms-learn-secured-core] packages Secure Launch with a set of other hardware requirements: SMM Supervisor, kernel DMA protection, Boot Guard or PSP firmware, Pluton or equivalent silicon root of trust, and Memory Integrity (HVCI) enabled by default. The Microsoft framing: "Microsoft is working closely with OEM partners and silicon vendors to build Secured-core PCs that features deeply integrated hardware, firmware and software to ensure enhanced security for devices, identities and data." The result is a tier-1 SKU set whose attestation evidence is the small OEM-invariant DRTM TCB, not the large SRTM history.

Operationally, the Secured-Core flag enables the configuration block at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios per Microsoft's Secure Launch configuration guide [@ms-learn-sgsl]. When the registry flag is set and the silicon supports late launch, winload.efi issues SENTER/SKINIT after measuring the early kernel, and the hypervisor launches inside the MLE.

TrenchBoot: open-source DRTM for Linux

DRTM is not Windows-only. The TrenchBoot project [@trenchboot-org] -- with contributors from Apertus Solutions, Oracle, and 3mdeb [@trenchboot-org] -- maintains an open-source DRTM stack for Linux and Xen on GRUB. From the TrenchBoot documentation repo [@gh-trenchboot-docs]: "TrenchBoot is a framework that allows individuals and projects to build security engines to perform launch integrity actions for their systems." The Linux side of the same primitive that Microsoft Secure Launch uses on Windows.

flowchart TD subgraph SRTM["SRTM chain (PCRs 0-7, 11-14)"] S1["CRTM"] --> S2["PEI/DXE"] --> S3["option ROMs"] --> S4["BDS"] S4 --> S5["bootmgfw.efi"] --> S6["winload.efi (early)"] end subgraph DRTM["DRTM chain (PCRs 17-22)"] D1["SKL issues SENTER / SKINIT"] --> D2["CPU resets PCRs 17-22"] D2 --> D3["ACM/SLB extended into PCR[17]"] D3 --> D4["MLE (hypervisor + secure kernel) into PCR[18]"] D4 --> D5["Secure kernel boots; IOMMU active"] end S6 --> D1

The comparison below synthesizes the TCG PFP PCR allocation surfaced in Microsoft's Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log] with the Microsoft hardware-root-of-trust documentation [@ms-learn-hwrot] and the BitLocker countermeasures unlock-mode enumeration [@ms-learn-bitlocker-counter]:

Property	SRTM (PCR[0-7,11-14])	DRTM (PCR[17-22])	TPM-only BitLocker (seal PCR[7,11])	TPM+PIN
Trust-anchor size	OEM CRTM + firmware + option ROMs + drivers (large)	Vendor ACM/SLB + MLE only (small)	Same as SRTM	Same + human PIN secret
Hardware required	Any TPM 2.0 platform	Intel TXT-capable or AMD SVM-capable + IOMMU	Same as SRTM	Same
Recovery prompts/year	High (firmware + dbx + boot manager)	Low (PCR[17-22] not in default profile)	High on TPM-only profile	Same as seal profile
bitpixie-class attack	Vulnerable	Not directly mitigated	Vulnerable	Mitigated (PIN required)
Verifier policy size	O(vendors x versions)	O(vendor)	O(profile)	O(profile + PIN policy)

DRTM solves the OEM diversity problem. It does not solve the problem that the log is unsigned, the measurement is a hash and not a good hash, and the CRTM is an axiom. What can measurement never prove?

8. Theoretical Limits: What Measurement Can Never Prove

Restate the axiom from §2: the first hash in the chain is an axiom; the silicon that computes it is itself unmeasured. CRTM is the Root of Trust for Measurement, not the Root of Trust for Everything. The trust we can claim is that, given the integrity of the silicon and the immutability of the embedded keys, the chain is a faithful record of what ran. The "given" is doing all the work.

Three limits, each architectural and not implementational.

8.1 Trust on first measurement

The CRTM has nothing under it. If you compromise the silicon -- through a faulTPM-class SoC voltage glitch against an AMD fTPM, through SPI-bus sniffing of a discrete TPM, through a Pluton supply-chain tamper, through an Intel Boot Guard key extraction -- the rest of the chain is, formally, useless. The verifier asks the chip "what ran?"; the chip computes the answer using cryptographic primitives the chip itself implements; if the chip is malicious, every answer is consistent with whatever boot history the attacker wishes. The TPM's TPM2_Quote signature is bound to the chip's own AIK; if the chip is the attacker, the signature is honest about a lie.

This is not a flaw of TPM 2.0. It is a feature of mathematics. You cannot bootstrap trust from nothing. AEGIS knew this in 1997; the TCG accepted it in 1999; every silicon root of trust still depends on it in 2026. The only mitigations are (a) make the silicon as small and audited and physically resistant as the budget allows (which is why Pluton ships a separate sub-millimetre microcontroller), and (b) bind the chip's identity to a manufacturer-rooted certificate chain that an out-of-band auditor can verify -- which is why Hello for Business enrollment cross-checks the EK certificate against the OEM root before issuing the device-bound key.

8.2 A PCR value is a hash, not a good hash

The TPM has no knowledge of what is good. PCR[0] holding 0xC4F7... is just a number. To the TPM it is no more or less suspicious than 0xA21E.... The TPM's job, during TPM2_PolicyPCR+TPM2_Unseal, is to refuse the key release if the PCRs do not match the seal-time digest -- regardless of whether the seal-time digest was a benign value or a malicious one.

A PCR value is a hash, not a *good* hash.

This is why a sealed BitLocker VMK released on a successful TPM2_PolicyPCR match is not a guarantee that the booted code was actually trustworthy. It is a guarantee that the booted code matched the seal-time digest. If at seal time the platform was running an older, signed, but vulnerable bootmgfw.efi, the seal binds to that boot manager's PCR[11]. Years later, when an attacker downgrades to that same older, signed boot manager, PCR[11] reproduces the seal-time digest exactly, and the TPM cheerfully releases the key. This is the mechanism that makes bitpixie work; we will meet it again in Section 9.

The verifier -- BitLocker policy, Azure Attestation policy, Intune DHA, your fleet management tool -- is the only entity that knows what good means. The TPM provides reporting infrastructure; the verifier provides policy infrastructure. Measurement is reporting infrastructure, not policy infrastructure.

Key idea: Measurement is reporting infrastructure, not policy infrastructure. The TPM knows what was measured; only the verifier knows what is good. Every BitLocker unseal, every Azure Attestation, every Intune DHA verdict is a policy decision made by software outside the TPM, against a number the TPM merely reports.

Note: A sealed VMK released on a successful TPM2_PolicyPCR match is not a guarantee that the booted code was actually trustworthy. It is a guarantee that the booted code matched the seal-time digest. If seal time captured a vulnerable but signed binary, every subsequent boot of that same vulnerable signed binary will unseal cleanly. This is the architectural reason bitpixie works against TPM-only BitLocker even on fully patched 2025 firmware.

8.3 The log is unsigned

TPM2_Quote signs only the PCR values plus the verifier's nonce. It does not sign the TCG event log. A malicious firmware can extend an honest digest into the TPM and report a different event in the log it hands the OS. The PCR is correct; the log is a fabrication. Detection comes only from the verifier replaying the log against the quoted PCRs and flagging a mismatch.

In practice this is not a problem on benign firmware, because the firmware has no incentive to lie about its own events. It becomes a problem precisely in the cases where the firmware is the attacker -- BlackLotus-class implants that own the boot manager, faulTPM-class chip compromises that own the TPM. In those cases, a verifier that trusts both the log and the quote without replaying is trusting a forged document.

The mitigation is structural and well-known: verifiers MUST replay. Azure Attestation, Intune DHA, and Microsoft's reference attestation library all replay the log against the quoted PCRs and refuse to issue a token on mismatch. Operators rolling their own attestation pipeline often skip the replay step, especially in early-prototype deployments. Skip the replay and you have an unauthenticated event list dressed up as evidence.

8.4 The cuckoo attestation class (Parno 2008)

There is a class of attack that no amount of replay or PCR profile tightening can stop. Bryan Parno's 2008 HotSec paper [@parno-hotsec-pdf] names the problem the cuckoo attack and proposes the first formal model for establishing trust in a platform under that threat. The abstract, paraphrased lightly to fit this article's word-list: any naive approach falls victim to a cuckoo attack; the model, in Parno's own phrasing, "reveals the cuckoo attack problem".

An attestation-relay attack in which a verifier challenges a compromised device, the compromised device proxies the challenge to a separate, genuine, attested device elsewhere, the genuine device produces a valid signed quote, the compromised device returns that quote as if it were its own, and the verifier accepts. Without out-of-band identification of *this* device's endorsement key, the verifier cannot distinguish "the EK that signed the quote" from "an EK in the world that signed a quote." Named by Bryan Parno in 2008 by analogy with the cuckoo bird's brood parasitism. A TPM-resident asymmetric key whose certificate is signed by the platform's Endorsement Key certificate chain, used to sign `TPM2_Quote` responses. The verifier checks the AK's certificate chain to the OEM root before trusting the quote. If the EK chain is not pre-bound to *this* device's serial number (or some other out-of-band identifier), an attacker can relay the challenge to a different TPM and return a valid signature from that TPM's AK.

The cuckoo class is closeable, but only by binding the AK to this device's identity before trust is needed. Microsoft Autopilot [@ms-aa-tpm-concepts] and Windows Hello for Business do this transparently during device enrollment: the EK certificate chain is captured at first boot, cross-checked against the OEM root, and the resulting AK is bound to a specific Microsoft Entra ID device object. Ad-hoc attestation deployments that do not capture the EK chain at enrollment are vulnerable.

Bryan Parno is now at Carnegie Mellon [@cmu-parno] and was on sabbatical at Amazon during 2025. The cuckoo paper remains, on its eighteenth birthday, the canonical reference for the class.

Permanent limits accepted. What are people actively trying to fix that we have not solved yet?

9. Open Problems: bitpixie, the dbx-Update UX, and What's Next

The fix is the breakage. The patch that closes the most dangerous BitLocker bypass of the decade is also the patch that drowns help-desks in 48-digit recovery prompts. The structural entanglement of these two facts is the central open problem of measured boot in 2026.

9.1 bitpixie (CVE-2023-21563)

An attacker reaches behind a fully-patched, BitLocker-enabled Windows 11 laptop. They plug in a LAN cable. They plug in a USB keyboard. They press F12 to boot from network. Within five minutes the disk encryption key is on their disk.

That is bitpixie. From the Neodyme write-up [@neodyme-bitpixie]: "Thanks to a bug discovered by Rairii in August 2022, attackers can extract your disk encryption key on Windows' default 'Device Encryption' setup. This exploit, dubbed bitpixie, relies on downgrading the Windows Boot Manager. All an attacker needs is the ability to plug in a LAN cable and keyboard to decrypt the disk." The CVE is CVE-2023-21563 [@nvd-2023-21563], described as a "BitLocker Security Feature Bypass Vulnerability" with the MSRC advisory at CVE-2023-21563 [@msrc-2023-21563].

The mechanism is the second aha moment from Section 8 made operational. From SySS's bitpixie technical write-up [@syss-bitpixie]: "The bitpixie vulnerability in Windows Boot Manager is caused by a flaw in the PXE soft reboot feature, whereby the BitLocker key is not erased from memory. To exploit this vulnerability on up-to-date systems, a downgrade attack can be performed by loading an older, unpatched boot manager."

The chain in detail: (1) The attacker boots the target normally. The boot manager unseals the VMK, hands it to winload.efi, and loads BitLocker into the boot path. (2) Before winload.efi zeroes the VMK from RAM, the attacker triggers a PXE soft reboot (a feature of older boot manager versions) that returns control to the boot manager without a full platform reset. (3) The attacker now PXE-boots a Linux image that scans physical memory for the BitLocker FVE marker -FVE-FS- and extracts the VMK. The platform reset never happened, the RAM never cleared, the TPM never re-quoted -- the VMK is just lying there in untouched physical memory.

The downgrade: the older boot manager whose soft-reboot path leaks the VMK is still signed by the Microsoft 2011 production certificate, which is still in db on every Secure Boot machine until that certificate's natural 2026 expiry. PCR[7] -- the policy PCR -- accepts the downgraded boot manager because the boot manager is still validly signed. PCR[11] still matches the seal-time digest because, at seal time, that exact older boot manager was the one running. The TPM unseals. BitLocker unlocks. The attack proceeds.

This is the third aha moment from the article's structure: a PCR replay attack with a still-trusted older signed binary. The TPM is not malfunctioning. The policy is not misconfigured. The seal is doing exactly what it was sealed to do: release the key if the boot reproduces the boot it was sealed against. The attacker just produced the seal-time boot, in 2024, using a signed-but-vulnerable binary the verifier has not revoked.

Public disclosure landed at the 38th Chaos Communication Congress in December 2024 [@38c3-bitpixie]. From the talk abstract verbatim: "since 2022, when Rairii discovered the bitpixie bug (CVE-2023-21563). While this bug is 'fixed' since Nov. 2022 and publically known since 2023, we can still use it today with a downgrade attack to decrypt BitLocker." The full attack chain was demonstrated on stage by Thomas Lambertz of Neodyme. The proof-of-concept code is at github.com/martanne/bitpixie [@gh-martanne-bitpixie].The repository handle martanne is the GitHub username; the discoverer is Rairii (August 2022); the 38C3 presenter is Thomas Lambertz (Neodyme). Press accounts that refer to "martanne" as a person are confusing the GitHub handle with an author identity.

9.2 The KB5025885 / Windows UEFI CA 2023 rotation

Microsoft's structural response is documented in the canonical KB article on Boot Manager revocations [@ms-kb5025885]. The fix is in three stages. Stage 1: enroll the new Windows UEFI CA 2023 certificate in the Secure Boot db variable. Stage 2: replace existing boot manager binaries with copies signed by the 2023 CA instead of the 2011 CA. Stage 3: revoke the 2011 CA in dbx. The full rollout is gated on the 2026 natural expiry of the original Microsoft production signing certificate.

Every one of those three stages changes PCR[7]. Every one. Stage 1 adds bytes to db; Stage 3 adds bytes to dbx; even Stage 2, which doesn't touch the Secure Boot variables directly, ships a new boot manager binary whose Authenticode digest moves PCR[4]. On TPM-only BitLocker bound to 0x880 = PCR[7] + PCR[11], the recovery prompt fires twice for every customer.

9.3 BlackLotus (CVE-2022-21894 "Baton Drop")

The bitpixie story does not stand alone. On March 1, 2023, ESET researcher Martin Smolár disclosed BlackLotus [@eset-blacklotus] -- in his own words, "the first publicly known UEFI bootkit bypassing the essential platform security feature -- UEFI Secure Boot -- is now a reality." BlackLotus exploits CVE-2022-21894 [@nvd-2022-21894] ("Baton Drop"), a Secure Boot bypass in a Microsoft-signed boot manager. From the ESET write-up [@eset-blacklotus]: "Although the vulnerability was fixed in Microsoft's January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate -- but vulnerable -- binaries to the system in order to exploit the vulnerability."

The structural fix for BlackLotus is identical to the structural fix for bitpixie: revoke the vulnerable signed binaries in dbx. Microsoft shipped the BlackLotus dbx revocations in May 2023; that update is the source of most of the "PCR[7] moved overnight" stories from the second half of 2023. The break-fix-break loop is now a recurring operational reality, not an exception.

the first publicly known UEFI bootkit bypassing the essential platform security feature -- UEFI Secure Boot -- is now a reality. -- Martin Smolár, ESET Research, March 1, 2023

9.4 The break-fix-break loop

Key idea: The fix is the breakage. Every dbx update that closes a Secure Boot bypass changes PCR[7]. Every PCR[7] change forces a 48-digit recovery prompt on every TPM-only BitLocker machine on the platform. The patch that closes BlackLotus or bitpixie is the operational pain. Pre-boot authentication (TPM+PIN) blocks the downgrade attack from releasing the VMK without the user's PIN, but it does not eliminate PCR[7]-driven recovery: a selected-PCR change still forces suspend/resume or a planned reseal.

flowchart LR A["BlackLotus disclosed
(March 2023)"] --> B["Microsoft May 2023 dbx update
revokes vulnerable boot managers"] B --> C["PCR[7] changes on every
UEFI Windows machine"] C --> D["TPM-only BitLocker fires
fleet-wide 48-digit prompts"] D --> E["Operators delay patches
or roll back to gain stability"] E --> F["Window of vulnerability
re-opens for class"] F --> A

Note: The only safe pattern when applying UEFI firmware, BIOS, or Secure Boot DB/DBX changes is to suspend BitLocker first. Run Suspend-BitLocker -RebootCount 1 from an elevated PowerShell prompt, apply the patch, and let the suspend auto-resume on the next clean boot. The TPM never sees a PCR mismatch because BitLocker is not asking the TPM for the VMK during the patch reboot.

9.5 Post-quantum agility for the attestation key

Looking ahead, the next structural break is cryptographic: the TPM's signing primitives (RSA-2048, ECC P-256) do not survive Shor's algorithm on a sufficiently large quantum computer. The TCG's PC Client Platform Firmware Profile revision 2 work is targeting post-quantum agility for attestation keys -- ML-DSA (Dilithium) and ML-KEM (Kyber) variants of the signature and key-encapsulation primitives that TPM2_Quote and TPM2_ActivateCredential depend on.

The constraint that limits the rollout is mechanical. The TPM 2.0 command and response buffer is, by default, 4096 bytes. A Dilithium Level 3 (ML-DSA-65) signature is 3,309 bytes per FIPS 204 [@csrc-nist-gov-204-final]. An RSA-2048 signature is 256 bytes. The buffer survives RSA quotes with vast headroom; it has roughly 800 bytes of headroom for an ML-DSA-65 quote. ML-KEM-768 (NIST Category 3) ciphertexts are 1,088 bytes per FIPS 203 [@csrc-nist-gov-203-final], with public keys at 1,184 bytes -- still tight if you also need an ML-DSA-65 signature on the same response. The PFP r2 work is largely about negotiating buffer growth across the TPM-firmware-OS path so the post-quantum primitives fit. As of 2026 this is UNVERIFIED_FETCH from the TCG (the TCG specifications site [@tcg-tpm-library] returns HTTP 403 to non-browser User-Agents), but Microsoft has signalled interim TPM 2.0 deployments with enlarged buffers.

9.6 DRTM coverage gaps

DRTM is a Secured-core feature; not every fleet runs Secured-core hardware. Raw Intel TXT has shipped on vPro platforms since the Q3 2007 introduction of the Intel DQ35J board [@itl-attacking-txt-2009], but the deployable surface for Microsoft Secure Launch is narrower because Secured-Core also requires HVCI, kernel DMA protection, and an SMM Supervisor. In practice Secure Launch is available on Intel Coffee Lake (Core 8th-generation) and later platforms; on AMD with Zen 2 and later (Ryzen 3000+ desktop; EPYC 7002+ server with SKINIT); and on Qualcomm Snapdragon SD850 and later on the ARM side. Fleets dominated by pre-2018 hardware -- and there are many of them, especially in cost-sensitive deployments -- cannot use Secure Launch as a SRTM allowlist substitute.

For those fleets, the only deployable mitigation against bitpixie remains pre-boot authentication (TPM+PIN). The cuckoo class remains open against ad-hoc attestation pipelines that do not bind AKs to device serials at provisioning. The OEM allowlist combinatorial explosion remains the unsolved problem that pushed Microsoft to DRTM in the first place.

9.7 PFP r2 in flight

The PC Client Platform Firmware Profile is in active revision. PFP r2 is expected to formalise SHA-3 support, change the default banks to SHA-384 and SHA-512 (with SHA-256 retained for legacy compatibility), and codify the PCR[14] semantics that have been a Microsoft-vs-Linux ontology disagreement for the past decade. As of 2026 the revision is UNVERIFIED_FETCH from the TCG canonical URL [@tcg-pfp] (same 403 class); the tpm2_eventlog man page [@gh-tpm2-eventlog-man] tracks the spec by name without a rev number, deliberately so it can absorb r2 without rebuild.

For practitioners who need a current catalogue of hardware-debugger gaps that PCR[7]'s `EV_EFI_ACTION` event was supposed to close, the Wack0/bitlocker-attacks repository [@gh-wack0-bitlocker] maintains a curated index, including a reference to a DFRWS Europe 2023 paper from the Brazilian Federal Police that catalogued debug-mode firmware shipped to retail. The TCG EFI Platform Specification §6.4 quote reproduced there -- *"If the platform provides a firmware debugger mode... the platform SHALL extend an EV_EFI_ACTION event into PCR[7]"* -- exists precisely because shipped firmware historically did not always do this. The PCR[7] floor is not as solid as the specification suggests.

You have read 8,000 words. You have a recovery prompt to clear on Monday morning. What do you do?

10. Practical Guide: A Monday-Morning Checklist

Six actions. Each one tied to a verified Microsoft Learn or TCG source. Run them in order; you will know more about your fleet's measured-boot posture in twenty minutes than most operators learn in a year.

10.1 Inspect your log

Run tpmtool.exe getdeviceinformation from an elevated prompt; §6.7 enumerates the cross-platform and Linux equivalents. For a clean machine-readable dump, save the binary log via MeasuredBootTool.exe -log <path> [@ms-tbs-get-tcg-log] (Windows HLK), then parse it with tpm2_eventlog [@gh-tpm2-eventlog-man] for a portable text dump. The event stream conforms to the TCG_PCR_EVENT2 struct documented in the Tbsi_Get_TCG_Log reference [@ms-tbs-get-tcg-log].

10.2 Confirm your BitLocker PCR profile

Run manage-bde -status C: from an elevated prompt. Confirm a Numerical Password protector exists -- without one, you cannot recover from a profile mismatch and you are one PCR drift away from data loss. Then inspect HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidationProfileUEFI. On a Secure Boot UEFI machine the value should be 0x880 (PCR[7] + PCR[11]) per the BitLocker countermeasures documentation [@ms-learn-bitlocker-counter]: "By default, BitLocker provides integrity protection for Secure Boot by using the TPM PCR[7] measurement."

If you see 0x815 (PCR[0,2,4,11]), you are on the non-PCR[7] legacy validation profile (a CSM/legacy boot, or a UEFI system where Secure Boot PCR[7] binding is unavailable) and every firmware update will trigger a recovery prompt. The fix is to verify Secure Boot is on (Confirm-SecureBootUEFI from PowerShell), then re-seal by disabling and re-enabling the TPM protector.

10.3 Suspend BitLocker before every firmware update

The only safe pattern is this:

```powershell # Run as administrator. # Suspend BitLocker for the next 1 reboot. BitLocker auto-resumes after the # next clean boot completes, regardless of how many additional boots happen. Suspend-BitLocker -MountPoint "C:" -RebootCount 1Now run the OEM firmware updater or the Windows cumulative update that touches Secure Boot. The PCRs will move; BitLocker will not see a mismatch because the seal check is bypassed for this boot. After the patch reboot, BitLocker automatically re-seals to the new PCR values. To verify, run:

manage-bde -status C:

The output should show "Protection On" and the new PCR profile.

</Spoiler>

### 10.4 Enable Secure Launch on Secured-Core hardware

If your hardware supports DRTM (Intel TXT-capable Coffee Lake or later, AMD Zen 2 or later with `SKINIT`, ARM SD850 or later), enable Secure Launch. The configuration guide [@ms-learn-sgsl] lists the four paths: MDM via Intune, Group Policy, the Windows Security UI, or the registry directly at `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios`. Once enabled, Secure Launch absorbs OEM firmware diversity into the small DRTM TCB, reducing the verifier's allowlist burden from O(vendors x firmware versions) to O(vendor).

### 10.5 For high-value devices, switch to TPM+PIN

This is the only deployed mitigation that closes bitpixie pre-attack. From Microsoft's countermeasures documentation [@ms-learn-bitlocker-counter], four unlock modes exist: TPM-only, TPM+startup-key, TPM+PIN, TPM+startup-key+PIN. Of those, only the modes that require a human secret survive a downgrade attack -- the attacker can recreate the seal-time PCRs by booting an older signed boot manager, but they cannot recreate the PIN.

Enable it with `manage-bde -protectors -add C: -tpmandpin <PIN>`. Users will type the PIN at boot. For Secured-Core fleets where the BIOS exposes USB and TPM+PIN before the OS, this is the best practical security/UX trade. For high-value developer or executive endpoints it is non-negotiable.

> **Note:** bitpixie. Every other recoverable class -- evil-maid via tampered USB, cold-boot RAM extraction at modest cost, supply-chain implants on the firmware -- has either operational mitigations or is out-of-budget for the threat model. bitpixie does not. Pre-boot authentication closes it; nothing else does.

### 10.6 Bind your attestation keys to the device at provisioning

The cuckoo class only closes if the verifier knows the *specific* TPM's endorsement key before trust is needed. Microsoft Autopilot and Hello for Business do this transparently [@ms-aa-tpm-concepts] during device enrollment, capturing the EK certificate chain and cross-checking it against the OEM root before issuing the device-bound key. Ad-hoc deployments -- "we joined our domain after first boot" -- usually skip this step and leave the cuckoo path open. If you run an attestation pipeline outside Hello for Business or Azure Attestation, audit your AK provisioning: is the EK chain captured at first boot, and is it bound to a unique device record?

The Monday-morning steps are six items long. The structural questions are not. We close with the questions every reader still has.

## 11. Frequently Asked Questions

<FAQ title="Frequently asked questions about Measured Boot and PCR-bound BitLocker">

<FAQItem question="Why am I being prompted for a 48-digit recovery key after a BIOS update?">
Because PCR[0] or PCR[7] changed. BitLocker's seal binds the Volume Master Key to a specific subset of PCR values captured at seal time. A UEFI firmware update changes the `EV_S_CRTM_VERSION` and `EV_EFI_PLATFORM_FIRMWARE_BLOB` digests in PCR[0]; a Secure Boot `dbx` update changes PCR[7]. On boot, the TPM runs `TPM2_PolicyPCR` against the current PCRs, fails the match, and refuses to release the VMK. BitLocker falls back to the recovery-key protector. The fix is to suspend BitLocker before the patch with `Suspend-BitLocker -MountPoint "C:" -RebootCount 1`, per Microsoft's BitLocker countermeasures documentation [@ms-learn-bitlocker-counter].
</FAQItem>

<FAQItem question="What's the difference between Secure Boot and Measured Boot?">
Secure Boot is *enforcement*: it refuses to run code that isn't signed by a trusted certificate in the `db` variable. Measured Boot is *reporting*: it records what ran -- signed or not -- into PCRs and the TCG event log. They cooperate but don't substitute. Secure Boot stops a bootkit from running. Measured Boot lets a remote verifier confirm, after the fact, that no bootkit ran. The TPM-based Trusted Boot extension [@ms-learn-boot-process] continues the measurement chain into the Windows kernel, drivers, and ELAM.
</FAQItem>

<FAQItem question="If Secure Boot is on, do I still need Measured Boot?">
Yes. The remote-attestation evidence chain is a measured-boot artifact -- Azure Attestation, Intune Device Health Attestation, Hello for Business device-bound key attestation, BitLocker PCR-bound unseal, and System Guard runtime attestation all consult the TCG event log and PCR snapshot. Secure Boot has no remote-reporting story; it cannot, by itself, prove to a verifier in Azure that this laptop in the field booted the firmware Microsoft signed off on. Measured Boot is what makes that proof possible.
</FAQItem>

<FAQItem question="Why does BitLocker bind to PCR[7] instead of PCR[0,2,4,11]?">
Because PCR[7] is the *policy* PCR, not the *code* PCR. Firmware updates and option-ROM changes move PCR[0] and PCR[2]; Secure-Boot-policy hashes don't change unless the actual `PK`/`KEK`/`db`/`dbx` variables change. The result: a fleet on the default UEFI profile (`0x880` = PCR[7] + PCR[11]) survives Dell and HP and Lenovo firmware updates without recovery prompts, because those vendors' firmware updates move PCR[0] and not PCR[7]. The trade-off is that PCR[7] only moves when Secure Boot's identity moves -- which is exactly when you do want a recovery prompt (a key revocation is a real security event). Microsoft makes the trade-off explicit in the BitLocker countermeasures documentation [@ms-learn-bitlocker-counter].
</FAQItem>

<FAQItem question="Can attestation prove my OS isn't compromised right now?">
No. Attestation proves what *booted*. It captures the boot-time state of the platform up to a `EV_SEPARATOR` event the kernel emits early in OS bootstrap. Anything that happens after the separator -- a malicious kernel driver loaded at runtime, a memory-corruption exploit in a Win32 service, a rootkit that bypasses HVCI -- is invisible to PCR-based attestation. The runtime-attestation problem is what Windows Defender System Guard runtime attestation [@ms-learn-sgsl] and Microsoft's hypervisor-isolated runtime checks try to address; that is a separate trust system layered on top of measured boot, not part of it.
</FAQItem>

<FAQItem question="What is PCR[14] for on Windows?">
Microsoft's Windows Boot Configuration Log convention uses PCR[14] for boot-loader-authority events -- WBCL records that capture which authorities the boot manager consulted for code-integrity decisions. The Linux shim convention uses PCR[14] for Machine Owner Key (MOK) enrolment events. Same PCR index; different ontology. A verifier reading PCR[14] must know which OS produced the log it is reading; the value is meaningless without that context. This is one of the corner cases PFP r2 is expected to formalise.
</FAQItem>

<FAQItem question="Is bitpixie fixed?">
Not on TPM-only BitLocker, not yet. The structural fix is KB5025885 [@ms-kb5025885] (May 2023) which enrolls the new Windows UEFI CA 2023 certificate and ultimately revokes the 2011 CA in `dbx`. Full revocation is gated on the 2011 CA's 2026 natural expiry. Until then, an attacker can still downgrade to a 2011-signed boot manager whose PXE-soft-reboot path leaks the VMK. The only pre-attack mitigation that closes the class today is pre-boot authentication: TPM+PIN, or TPM+startup-key, or both. The 38C3 talk demonstrated the attack on fully-patched late-2024 firmware.
</FAQItem>

</FAQ>

<StudyGuide slug="measured-boot-tcg-event-log" keyTerms={[
  { term: "PCR (Platform Configuration Register)", definition: "Append-only TPM register that extends rather than stores. Modern TPMs have 24 PCRs per hash bank; `PCR[N] := H(PCR[N] || measurement)`." },
  { term: "CRTM (Core Root of Trust for Measurement)", definition: "The smallest, lowest, immutable code that runs after platform reset. It measures the next firmware stage into PCR[0] and is an axiomatic root, not a verified one." },
  { term: "SRTM (Static Root of Trust for Measurement)", definition: "The measurement chain rooted at the CRTM, covering PCRs 0-7 and 11-14 across firmware, boot manager, OS loader, ELAM, and kernel." },
  { term: "DRTM (Dynamic Root of Trust for Measurement)", definition: "Mid-boot CPU primitive (Intel `GETSEC[SENTER]`, AMD `SKINIT`) that resets PCRs 17-22 and atomically launches a vendor-signed Authenticated Code Module plus a Measured Launch Environment." },
  { term: "TCG Event Log / WBCL", definition: "Ordered list of `TCG_PCR_EVENT2` records (with Microsoft-specific WBCL extensions in PCRs 11/12/13) that the verifier replays to re-derive PCR values from a `TPM2_Quote`." },
  { term: "TPM2_PolicyPCR / TPM2_Unseal", definition: "TPM 2.0 commands that bind a sealed blob's release to a specific PCR profile. BitLocker uses this pair to release the VMK only when current PCRs match the seal-time digest." },
  { term: "Authenticode", definition: "Microsoft PE-image digest format used for code signing. PCR[4] hashes the Authenticode digest of `bootmgfw.efi`, not the raw bytes of the file." },
  { term: "Cuckoo Attack", definition: "An attestation-relay attack (Parno 2008) in which a compromised device proxies a verifier's challenge to a different genuine TPM and returns that TPM's valid signed quote. Closeable only by pre-binding the AK to the device serial." },
]} />

The Day 8.5 Million Devices Couldn't Boot -- and How Microsoft Rebuilt Recovery as a Security Surface

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

**On July 19, 2024, the Windows Recovery Environment worked exactly as designed -- and that was the problem.** WinRE assumed a human operator per machine, and CrowdStrike's Channel File 291 priced that assumption at 8.5 million endpoints. The Windows Resiliency Initiative -- Quick Machine Recovery, MVI 3.0, the user-mode endpoint security platform, Intune-surfaced WinRE state, Point-in-Time Restore, and Cloud Rebuild -- is Microsoft's first systemic admission that the recovery path is part of the security architecture. This article maps the architecture, the program, and the trade-off it cannot remove.

1. A Fleet That Cannot Boot Itself

At 04:09 UTC on July 19, 2024, CrowdStrike pushed a new Channel File 291 to its Falcon sensor on Windows. Forty-eight minutes later -- 04:57 UTC, give or take an hour depending on which time zone the failing devices happened to wake into -- the calls began. By the time CrowdStrike reverted the file at 05:27 UTC, roughly 8.5 million Windows endpoints were stuck in a bug-check loop on csagent+0xe14ed: a read-out-of-bounds page fault inside a kernel-mode driver registered as SERVICE_SYSTEM_START (Start=1), so it reloaded on every reboot [@crowdstrike-tech-details, @ms-security-jul27, @ms-crowdstrike-jul20].

The fix was published almost immediately. "Boot to Safe Mode," it said. "Delete C-00000291*.sys. Reboot." If the volume was BitLocker-encrypted, find the recovery key first [@ms-kb5042421]. The instruction was technically correct. It was also a procedure for one machine. The Windows Recovery Environment that the procedure depended on -- WinRE -- worked exactly as it was designed to work, on every one of those 8.5 million devices [@ms-crowdstrike-jul20]. That was the problem.

Think about the engineering. The recovery partition was where it should be. The Boot Configuration Data store pointed at the right winre.wim. The two-failed-boots trigger fired. The blue Safe Mode tile rendered. The keyboard input handler took keystrokes. The NTFS read-write driver inside WinRE deleted the bad channel file. The reboot succeeded. Every line of code in the recovery path behaved exactly as the engineers in Redmond had specified. The architecture did not break.

What broke was the architecture's central assumption: that a person would be sitting in front of the screen.

The assumption was a security choice as much as a usability choice, and that the cost of that choice was a denial-of-service event measured not in seconds of downtime but in person-days of triage. What follows: the WinRE architecture as it actually exists on every Windows 11 device today, the lineage that produced that architecture, the failure mode that priced the architecture's blind spot, and the Windows Resiliency Initiative that Microsoft began assembling in the months after the incident.

A second thesis follows from the first. Recoverability is a security property. A platform that cannot recover at scale cannot guarantee availability; a platform that cannot guarantee availability cannot keep its confidentiality and integrity promises either, because operations teams in the middle of a fleet-down event will eventually pull every encryption layer and every signing check that gets in their way. The two halves of the CIA triad we usually study -- confidentiality and integrity -- have spent decades crowding out the third. CrowdStrike forced the third one back onto the page.

If WinRE worked perfectly on July 19, 2024, what does it actually do? And how did a recovery primitive end up being the architecture's single point of human dependence? Those questions are next.

2. The Architecture: WinRE, `winre.wim`, `boot.sdi`, ReAgentC

Before we explain how WinRE failed at scale, we have to be precise about what WinRE is. Most engineers know it as the screen that appears after two bad boots. That description is correct and unhelpful. WinRE is a Windows Preinstallation Environment image -- winre.wim -- backed by a system deployment image ramdisk and managed by ReAgentC.exe, registered with the Windows Boot Manager via an entry in the Boot Configuration Data store [@ms-winre-tech-ref, @ms-reagentc, @ms-bcd]. Each of those four moving pieces does one job; together they make the recovery surface possible.

A small, self-contained Windows operating system used to install, deploy, and repair Windows desktop editions and Windows Server [@ms-winpe-intro]. WinPE is the substrate of Windows Setup, the install media's `boot.wim`, and `winre.wim`. The base image requires 512 MB of RAM and automatically reboots after 240 hours of continuous use on Windows 10 1803 and later [@ms-winpe-intro]. Originally released to manufacturing in 2002 by a Microsoft team that included Vijay Jayaseelan, Ryan Burkhardt, and Richard Bond [@wiki-winpe]. A small image-format file that the Windows Boot Manager uses to allocate a RAM disk into which a WIM image can be mounted at boot time. The WinRE BCD entry references `boot.sdi` through a `ramdiskoptions` element; the `osdevice` element then names `winre.wim` as the image to mount inside that RAM disk [@ms-bcd, @ms-winre-tech-ref]. The binary database that replaced `boot.ini` in Windows Vista. The BCD lives on the EFI System Partition on UEFI machines and is the data structure the boot manager reads to decide what to boot. Each entry is a typed collection of *elements* -- `device`, `osdevice`, `path`, `winpe`, `ramdiskoptions`, `recoverysequence`, and others -- manipulated with `bcdedit.exe` [@ms-bcd]. A dedicated GPT partition holding `winre.wim`, identified by partition Type ID `DE94BBA4-06D1-4D40-A16A-BFD50179D6AC` and recommended for placement immediately after the Windows partition. The minimum size is 300 MB, with 250 MB of free space recommended to accommodate future updates [@ms-uefi-gpt]. On Image Configuration Designer media, this partition is the default layout; clean Setup may instead use a `\Recovery\WindowsRE` folder inside the Windows partition [@ms-winre-tech-ref].

Restated in the order a practitioner encounters them on disk, the four pieces are:

The recovery partition. The default UEFI/GPT layout from the Image Configuration Designer places a Windows RE Tools partition after the Windows partition, sized to hold winre.wim with headroom for cumulative-update growth [@ms-uefi-gpt]. The GPT Type ID DE94BBA4-06D1-4D40-A16A-BFD50179D6AC lets bootmgr find the partition without depending on the Windows volume's drive letter. A \Recovery\WindowsRE folder inside the OS volume is an equally valid alternative; some OEMs use one, some the other.The variability is invisible at runtime: bootmgr follows the BCD, not the disk layout. But it matters at provisioning time. Always check reagentc /info after deployment to know which arrangement you have, because the Microsoft-recommended fix for "winre.wim is too small after a cumulative update" (KB5028997) depends on which partition the image lives in.
winre.wim. A customised WinPE image. The lineage goes back to Windows PE 1.0, RTMed in 2002 from Windows XP RTM [@wiki-winpe]. Today's winre.wim is built from Windows 10 / 11's WinPE 10 line and includes the recovery shell, Startup Repair, System Restore (when enabled on the host), command prompt, and a curated list of optional drivers. The base image still inherits the WinPE rules: 512 MB minimum RAM, 240-hour reboot cap on Windows 10 1803+ [@ms-winpe-intro].
boot.sdi. Sits on the recovery partition (or in \Recovery\WindowsRE\) and acts as a fixed-size container into which the boot manager creates a RAM disk at boot time [@ms-bcd].The .sdi extension stands for *System Deployment Image*, the same file format used by older Windows Deployment Services workflows in which a thin ramdisk holds a boot.wim for PXE installs. The RAM disk is where winre.wim is mounted. boot.sdi is small (a few megabytes), unmodifiable in normal operation, and one of the parsers later abused by the BitUnlocker chain [@ms-bitunlocker-blog]; we return to that in Section 9.
ReAgentC.exe. The in-box management tool. Microsoft Learn documents the supported switches: /info, /enable, /disable, /setreimage /Path <Folder>, /boottore, /setbootshelllink, and the now-deprecated /setosimage (no longer used on Windows 10 or later) [@ms-reagentc]. The same page notes that for offline operations on WinPE 2.x/3.x/4.x images, administrators must instead use Winrecfg.exe from the Windows Assessment and Deployment Kit -- a clue that the online mode of ReAgentC.exe predated the offline mode. The tool has shipped since at least Windows 7; the precise RTM month is not surfaced on Microsoft Learn today.The web is full of confident claims that ReAgentC.exe first shipped in Vista, Windows 7, or Windows 8. The safe attribution is "Windows 7 onwards" because that is the era when the recovery-partition + ReAgentC model became the supported default. Microsoft Learn does not name an exact ship version, and the AI summaries that do are inferring from circumstantial evidence [@ms-reagentc].

All four pieces have to cooperate at the worst possible moment: when the Windows partition refuses to boot. The question for the next section is the literal handoff. How does the firmware end up running winre.wim?

3. The Mechanism: How a WinRE Boot Actually Happens

There is a sentence that appears in dozens of TechNet-era guides and AI summaries: Windows boots WinRE by running winload.exe /recovery. That sentence is wrong. There is no /recovery switch on winload.efi or winload.exe. The BCD Boot Options Reference enumerates every legal element on a boot entry, and recoverysequence is one of them; a command-line switch with that name is not [@ms-bcd]. WinRE is selected through the BCD, not through a flag passed to the loader.

Note: The BCD Boot Options Reference defines every element on a boot entry: device, osdevice, path, description, recoverysequence, winpe, ramdisksdidevice, ramdisksdipath, and a few dozen others [@ms-bcd]. None of them is exposed as a winload.exe /recovery command-line flag. The recovery handoff happens entirely inside the boot manager, before winload.efi ever runs.

Walk the literal boot sequence on a UEFI machine [@ms-winre-tech-ref, @ms-bcd]:

Firmware passes control to bootmgfw.efi on the EFI System Partition. (On legacy BIOS, it would be bootmgr from the active partition.)
The boot manager reads the BCD store. There is one entry of type Windows Boot Manager and one or more entries of type Windows Boot Loader.
The OS loader entry carries an element called recoverysequence, set to the GUID of a separate BCD entry. That separate entry is the WinRE configuration.
On a normal boot, the boot manager loads the OS entry's path (\Windows\System32\winload.efi) against the OS volume named in device/osdevice, and winload.efi brings up the kernel.
On a recovery trigger -- two failed boots, a corrupted system file, an explicit reagentc /boottore, or the user choosing Restart from the Advanced Startup menu -- the boot manager instead follows recoverysequence to the WinRE entry.
The WinRE entry's elements look like this: winpe Yes, osdevice ramdisk=[recovery]\Recovery\WindowsRE\Winre.wim,{ramdiskoptionsguid}, device ramdisk=[recovery]\Recovery\WindowsRE\Winre.wim,{ramdiskoptionsguid}, and path \Windows\System32\Boot\winload.efi. The ramdiskoptions element it points to in turn carries ramdisksdidevice and ramdisksdipath (\Recovery\WindowsRE\boot.sdi).
The boot manager creates a RAM disk backed by boot.sdi, mounts winre.wim inside it, and starts winload.efi against that ramdisk. From winload.efi's point of view, the OS being booted is the one inside winre.wim. The kernel comes up in the RAM disk and presents the Windows RE entry-point UI.

flowchart TD F[UEFI firmware] --> BM[bootmgfw.efi on ESP] BM --> BCD[Read BCD store] BCD --> CHK{Trigger fired?} CHK -- No --> OS[OS loader entry, winload.efi, Windows partition] CHK -- Yes --> RS[Follow recoverysequence GUID] RS --> WRE[WinRE BCD entry: winpe Yes, osdevice ramdisk=...winre.wim] WRE --> RD[Allocate RAM disk from boot.sdi] RD --> MNT[Mount winre.wim into RAM disk] MNT --> WL[winload.efi loads WinPE kernel] WL --> UX[WinRE entry-point UI]

The five auto-trigger conditions are enumerated verbatim in the Windows RE Technical Reference [@ms-winre-tech-ref]:

Two consecutive failed attempts to start Windows.
Two consecutive unexpected shutdowns within two minutes of boot completion.
Two consecutive system reboots within two minutes of boot completion.
A Secure Boot error (except for issues related to Bootmgr.efi).
A BitLocker error on touch-only devices.

flowchart LR A[Two failed boots] --> ENT[Enter WinRE] B[Two unexpected shutdowns within 2 min of boot] --> ENT C[Two reboots within 2 min of boot] --> ENT D[Secure Boot error -- not Bootmgr.efi] --> ENT E[BitLocker error on touch-only device] --> ENT

Walking the BCD elements themselves makes the absence of any /recovery switch visible. Here is a minimal model of what the boot manager actually consumes.

{` // Paraphrased from the BCD Boot Options Reference. Real bcdedit output is text, // but the boot manager reads it as a typed key/value store.

const bcd = { bootmgr: { type: 'Windows Boot Manager', default: '{current}', displayorder: ['{current}'], }, '{current}': { type: 'Windows Boot Loader', device: 'partition=C:', osdevice: 'partition=C:', path: '\\Windows\\system32\\winload.efi', description: 'Windows 11', recoverysequence: '{a1b2-...-winre-guid}', recoveryenabled: 'Yes', }, '{a1b2-...-winre-guid}': { type: 'Windows Boot Loader', device: 'ramdisk=[\\Device\\HarddiskVolume4]\\Recovery\\WindowsRE\\Winre.wim,{ramdiskopts}', osdevice: 'ramdisk=[\\Device\\HarddiskVolume4]\\Recovery\\WindowsRE\\Winre.wim,{ramdiskopts}', path: '\\Windows\\system32\\Boot\\winload.efi', description: 'Windows Recovery Environment', winpe: 'Yes', nx: 'OptIn', }, '{ramdiskopts}': { type: 'Device Options', description: 'Ramdisk Options', ramdisksdidevice: 'partition=\\Device\\HarddiskVolume4', ramdisksdipath: '\\Recovery\\WindowsRE\\boot.sdi', }, };

// The boot manager picks one of these entries, depending on whether // recoverysequence has been activated. No command-line flag is involved.

const chosen = bootDecision(2, false, false); console.log('Loader path the boot manager invokes:'); console.log(' ' + chosen.path); console.log('Backing device:'); console.log(' ' + chosen.osdevice); console.log('winpe flag (Yes means "boot a WIM into a ramdisk"):'); console.log(' ' + (chosen.winpe || '(unset, normal OS boot)')); `}

That is the entire mechanism. Two failed boots flip an in-BCD counter; the boot manager follows recoverysequence instead of the default loader path; the WinRE entry mounts winre.wim in a RAM disk; the kernel inside winre.wim comes up. No flags, no shells, no scripts.

Now we know what WinRE is and how it boots. The remaining historical question is how this architecture came to be, and what about it did not change between 2007 and July 19, 2024.

4. Historical Origins: From the Recovery Console to the Recovery Partition (2000-2012)

Every architectural choice in WinRE was a response to something that did not work the year before. Walk the four pre-WRI generations of Windows recovery and the story is one long relaxation of the assumption that recovery requires physical media.

Generation 1: Emergency Repair Disk (NT 3.x and 4.0, 1993-2000)

A floppy disk plus a %SystemRoot%\repair directory contained snapshotted SYSTEM, SOFTWARE, SAM, and SECURITY registry hives [@wiki-recovery-console]. The administrator booted from the three Windows NT Setup floppies, pressed R for Repair, fed the floppy when prompted, and Setup wrote the snapshotted hives back over the damaged on-disk copies. ERD repaired the registry, nothing more. If NTOSKRNL.EXE itself was missing, the operator was reduced to a DOS floppy plus EXPAND from the install CD. The architecture's failure mode was the obvious one for a floppy-based snapshot system: the floppy got lost; the snapshot was stale; the scope was too narrow.

The Windows NT 3.x and 4.0 recovery mechanism: a snapshot of the registry hives written to a floppy by `RDISK.EXE` plus a small `%SystemRoot%\repair` folder. Restored only the registry; required the NT Setup floppies to boot. Wikipedia's *Recovery Console* article identifies the Recovery Console as ERD's successor [@wiki-recovery-console].

Generation 2: Recovery Console (Windows 2000, February 17, 2000)

The Recovery Console replaced the binary "restore the snapshot" decision with a programmable shell. Boot from the Windows 2000 or XP install CD; choose Repair; the operator landed in a cmd.exe-shaped environment with around three dozen internal commands: copy, del, attrib, chkdsk, fixboot, fixmbr, bootcfg, and the rest [@wiki-recovery-console]. Authentication required the local Administrator password; filesystem access was sharply constrained (read-only by default; on the boot volume only the root and %SystemRoot% were writable, unless Group Policy relaxed those limits).

The Windows 2000/XP/Server 2003 command-line repair shell. Initial release February 17, 2000; superseded by the Windows Recovery Environment in Windows Vista. Loadable from the install CD or installable as a startup option via `winnt32 /cmdcons`. Wikipedia lists Windows Recovery Environment as its named successor [@wiki-recovery-console].

The Recovery Console did not fail technically. It failed culturally. By 2005 the Windows administrator population had shifted decisively to GUI tools. A 2005 user with a corrupt WINLOAD.EXE and no install CD had no path to repair the box without buying replacement media. There was no automatic-repair logic and no on-disk presence; the install CD was always required, and every fix demanded muscle memory the typical administrator no longer had.

Generation 3: WinRE on Installation Media (Windows Vista, January 2007)

Vista shipped a full GUI recovery environment built on the brand-new Windows PE 2.0 [@wiki-winpe]. winre.wim carried Startup Repair (a probe-and-fix playbook for boot failures), System Restore (now backed by the Volume Shadow Copy Service), Complete PC Restore, Windows Memory Diagnostic, and a command prompt for the cases nothing else fit. Vista was also the version that introduced the Boot Configuration Data store and bootmgr, replacing NTLDR and the plain-text boot.ini [@ms-bcd]. The same BCD that today still routes the recovery handoff was written for Vista.The Microsoft Learn "Vista WinRE Overview" page in the previous-versions archive (cc766056) is now misdirected and renders an unrelated USMT migration topic instead of the original article. The load-bearing claim that WinRE was introduced in Vista is independently supported by the Windows PE Wikipedia article's version table (WinPE 2.0 built from Vista RTM) and by Microsoft Learn's Push-button reset overview, which dates Push-Button Reset to Windows 8 and frames it as built on the existing WinRE architecture [@wiki-winpe, @ms-pbr-overview].

Vista WinRE had two architectural problems that the next generation fixed. OEMs were free to put winre.wim wherever they wanted on disk; there was no standard partition. And the install DVD remained the fallback for any user whose OEM had not pre-installed WinRE -- which, by 2010, was most users, none of whom still owned the DVD.

System Restore is itself a sub-thread worth noting. It first shipped in Windows ME (year 2000), was re-implemented atop VSS in Vista, and remained off by default on Windows 10 and 11 [@wiki-system-restore]. The Vista move made it callable from WinRE even when the host Windows would not boot -- a property that, twenty-five years later, Point-in-Time Restore is re-engineering for the cloud.

Generation 4: Recovery Partition + ReAgentC + BCD `recoverysequence` (Windows 7, 2009; standardised in Windows 8 and beyond)

This is the architecture every Windows 11 device still runs.

Windows 7 dropped winre.wim onto a dedicated recovery partition with a GPT Type ID that lets bootmgr find it without depending on the Windows volume's drive letter [@ms-uefi-gpt]. ReAgentC.exe became the in-box management tool [@ms-reagentc]. The BCD recoverysequence element became the mechanism by which the OS loader entry points at the WinRE entry. The two-failed-boots trigger entered the Windows RE Technical Reference's enumeration of automatic conditions [@ms-winre-tech-ref].

Generation 4 did not fail. The five auto-trigger conditions still fire on Windows 11 24H2. ReAgentC's switches are still the supported management surface. The recovery-partition GPT Type ID is still DE94BBA4-06D1-4D40-A16A-BFD50179D6AC. It is the architectural floor every later generation extends, including Quick Machine Recovery.

What Generation 4 did not solve was the cost of recovery at fleet scale. WinRE-on-disk handled one machine perfectly; it had nothing to say about ten thousand machines, each still bounded by the time it took to walk to a desk.

gantt dateFormat YYYY axisFormat %Y section Pre-WinRE Emergency Repair Disk (NT 3.x / 4.0) :1993, 2000 Recovery Console (Windows 2000 onwards) :2000, 2008 section WinRE WinRE on installation media (Vista) :2007, 2009 Recovery partition + ReAgentC (still current) :2009, 2026 section Recovery flavours Push-Button Reset (Windows 8 onwards) :2012, 2026 Autopilot Reset (Win 10 1709) :2017, 2026 Quick Machine Recovery (24H2) :2025, 2026 Intune Remote Recovery / Cloud Rebuild :2025, 2026

A few parallel paths deserve naming. Push-Button Reset, introduced in Windows 8 in 2012, gave consumers an in-WinRE "Refresh" or "Reset"; image-less reset in Windows 10 and Cloud Download in Windows 10 version 2004 (May 2020) made the reset progressively less dependent on locally-staged install images [@ms-pbr-overview]. Autopilot Reset, shipped in Windows 10 1709 (October 2017), let Intune issue an MDM-initiated wipe-and-rebuild that preserved the device's Entra ID join. Microsoft Diagnostics and Recovery Toolset (DaRT) -- the descendant of Winternals ERD Commander acquired in 2006 and shipped under MDOP starting July 2007 (MDOP 2007), with subsequent releases through MDOP 2008 (April 2008) -- gave Software Assurance customers a richer enterprise tool on top of WinPE [@wiki-mdop-dart]. Older recovery mechanisms quietly aged out: Last Known Good Configuration was no longer the default boot-failure response on Windows 8 onward, and the deprecated-features lifecycle framework is the canonical place to track such retirements today [@ms-deprecated].

By the early 2010s, the architecture that still runs on every Windows 11 device today was largely in place [@ms-winre-tech-ref, @ms-reagentc]. None of these tools gave WinRE permission to call Windows Update from inside the recovery environment. That gap is the next chapter.

5. The Forcing Function: July 19, 2024

We know what WinRE is. We know how it boots. We can now see the CrowdStrike incident as the architecture's stress test. The headline numbers are well-rehearsed at this point; what matters here is the technical cause, the kernel-resident dependency it expressed, and the procedure Microsoft published.

The fault

CrowdStrike's Falcon sensor for Windows version 7.11, released in February 2024, introduced a new IPC Template Type used by behavioural detection logic [@crowdstrike-rca-pdf]. The Template Type declared twenty-one input parameter fields. The integration code that invoked the in-driver Content Interpreter to evaluate Template Instances against host activity supplied only twenty inputs [@crowdstrike-rca-pdf]. For more than four months, Channel File 291 contained no Template Instance whose criterion read the twenty-first field. That made the mismatch latent.

At 04:09 UTC on July 19, 2024, CrowdStrike pushed a new Channel File 291 containing a Template Instance that referenced the twenty-first field with a non-wildcard matching criterion [@crowdstrike-rca-pdf, @crowdstrike-tech-details]. The Content Interpreter loaded the instance, looked up the twenty-first input pointer in its input-pointer array, and read past the end of that array. Sensors running 7.11 or later that received the update between 04:09 and 05:27 UTC tripped the latent out-of-bounds read [@crowdstrike-tech-details].

The crash

Microsoft's Windows Error Reporting analysis, published in the security blog on July 27, 2024, recorded the global crash signature as nt!KeBugCheckEx followed by nt!KiPageFault and then csagent+0xe14ed, with r8=ffff840500000074 as the invalid pointer that the read tried to dereference [@ms-security-jul27]. Microsoft confirmed that the analysis matched CrowdStrike's own conclusion: a read-out-of-bounds memory safety error in the csagent.sys driver.

flowchart TD A[Falcon 7.11 ships in Feb 2024 with IPC Template Type declaring 21 fields] --> B[Integration code supplies only 20 inputs] B --> C[Latent OOB potential -- no instance references field 21] C --> D[July 19 04:09 UTC: new Channel File 291 adds non-wildcard 21st-field criterion] D --> E[Content Interpreter reads input-pointer index 20] E --> F[Page fault at csagent+0xe14ed] F --> G[nt!KiPageFault -> nt!KeBugCheckEx] G --> H[Bug check; system reboots] H --> I[csagent.sys reloads -- registered SERVICE_SYSTEM_START Start=1 -- bug check again] I --> J[Boot loop on 8.5 million endpoints]

The kernel-resident dependency

csagent.sys loaded early in boot. Microsoft's WER post-mortem shows the driver registered with REG_DWORD Start 1 -- the SERVICE_SYSTEM_START class, loaded by the kernel before user-mode comes up [@ms-security-jul27]. That placement is the entire point of a kernel-mode security agent: it has to instrument the kernel boundary at the moment user-mode would otherwise be invisible to it. The cost of that placement is that when an early-boot driver page-faults, the bug check happens before the operating system is interactive. The remediation -- delete C-00000291*.sys -- could not be issued from a running Windows, because there was no running Windows.

The fault dynamic above is easier to describe than it is to file. CrowdStrike's own technical-details post is explicit about the file-type distinction: "Although Channel Files end with the SYS extension, they are not kernel drivers" [@crowdstrike-tech-details]. The kernel-mode component is `csagent.sys`. The Channel Files in `C:\Windows\System32\drivers\CrowdStrike\` are *data* that the Content Interpreter inside `csagent.sys` reads. The fault was a bug in `csagent.sys`'s interpretation of a particular Channel File; both ends matter, and the file extension on the data file is incidental.

The recovery procedure

Microsoft published KB5042421 within hours [@ms-kb5042421]. The text reduced to three steps: boot to Safe Mode (which on Windows 11 means letting WinRE select Safe Mode from the Advanced startup options tree); delete C:\Windows\System32\drivers\CrowdStrike\C-00000291*.sys; reboot. For BitLocker-encrypted volumes the procedure had a fourth, preliminary step: surface the recovery key. KB5042421 walks the user through the Entra ID self-service flow at aka.ms/aadrecoverykey: log on from a phone, choose Manage Devices, View BitLocker Keys, Show recovery key [@ms-kb5042421].

The instruction was correct. It was also unambiguously per-machine.

We currently estimate that CrowdStrike's update affected 8.5 million Windows devices, or less than one percent of all Windows machines. -- Microsoft, *Helping our customers through the CrowdStrike outage*, July 20, 2024 [@ms-crowdstrike-jul20].

The bottleneck

Each device's recovery was a function of time-to-physical-access, plus time-to-BitLocker-key, plus time-to-keyboard. None of those terms scaled. A laptop on a desk that the owner happened to be near recovered in five minutes. A laptop on a desk where the owner was on holiday recovered when someone arrived to swipe their badge. A server in a remote data centre recovered when a hand reached the iLO or KVM. A point-of-sale device in a checked-bag-only baggage hall recovered when someone wheeled a USB keyboard out to it. Multiply by 8.5 million.

The architecture that delivered Safe Mode to every one of those devices did exactly what its 2009 specification said it would do. The architecture that delivered Safe Mode to every one of those devices left enterprises stranded for days. Both sentences are true. The contradiction is the whole point.

Note: WinRE booted correctly. The Safe Mode tile rendered. The two-failed-boots trigger fired. The recovery partition was where it should be. The BCD recoverysequence led to the right winre.wim. The keyboard handler took keystrokes. Every line of code did what it was specified to do. The single unwritten line of the specification -- one operator, please -- was the line that did not scale.

The instruction was correct, the procedure was published within hours, and the floor was on fire for days. The next question -- the one Microsoft was already being asked at WESES, the closed-door September 10, 2024 endpoint-security partner summit [@ms-weses] -- was whether the floor could not be on fire next time.

6. The Breakthrough: Quick Machine Recovery

Quick Machine Recovery, announced at Microsoft Ignite on November 19, 2024 [@ms-wri-ignite-2024] and generally available on Windows 11 24H2 build 26100.4700+ in August 2025 per the November 18, 2025 update [@ms-wri-ignite-2025], did not add any new technology to WinRE that had not been in WinPE since 2002. Networking drivers, DHCP clients, HTTPS stacks: all of these were already in winre.wim's base image, inherited from the WinPE Optional Components that have shipped with the OS for two decades [@ms-winpe-intro]. What QMR added was an answer to a question WinRE had never been asked: when you are inside the recovery environment with no operator at the keyboard, who do you call?

The Windows 11 24H2 feature, available on build 26100.4700 or later, that lets WinRE establish network connectivity from inside the recovery environment, query Windows Update for a remediation matching the current failure signature, download and apply that remediation, and reboot -- all without requiring an operator at the keyboard [@ms-qmr]. Announced at Microsoft Ignite on November 19, 2024 [@ms-wri-ignite-2024]; first shipped in Windows 11 Insider Preview build 26120.3653 on March 28, 2025 [@ms-qmr-insider-mar2025]; generally available in August 2025 [@ms-wri-ignite-2025].

The five-phase loop

Microsoft Learn documents QMR as five phases [@ms-qmr]:

Crash detection. The same two-failed-boots trigger already in the Windows RE Technical Reference [@ms-winre-tech-ref] fires the recovery path.
Boot to recovery. The existing BCD recoverysequence mechanism from Section 3 routes the system into WinRE.
Network connection. WinRE establishes wired Ethernet, or WPA/WPA2 password-based Wi-Fi using a credential pre-staged via reagentc.exe /SetRecoverySettings. As of the Microsoft Learn page's current wording, only wired and WPA/WPA2 password-based wireless are supported [@ms-qmr]; enterprise certificates and WPA3-Enterprise are on the November 18, 2025 roadmap but not yet shipped [@ms-wri-ignite-2025].
Remediation. The recovery environment scans Windows Update for a published remediation matching the device's failure signature, downloads it, and applies it.
Reboot. On success, the device boots normally. On no-match, the device can either present the manual recovery menu (the one-time scan mode, the default for unmanaged systems) or loop with a configurable interval (the looped mode) until either a remediation arrives or the operator-set total wait time expires [@ms-qmr].

sequenceDiagram participant D as Device (OS) participant W as WinRE participant N as Network participant WU as Windows Update participant O as OS partition D->>W: Two failed boots -> follow recoverysequence W->>N: Acquire Ethernet or WPA2 Wi-Fi W->>WU: Query for remediation matching failure signature WU-->>W: Remediation package (or "none found") alt Remediation available W->>O: Apply remediation to OS partition W->>D: Reboot D-->>D: Normal boot succeeds else None found, one-time mode W->>D: Present manual recovery menu else None found, looped mode W-->>W: Sleep wait_interval, retry until total_wait_time end

The default-on/off matrix

The Microsoft Learn QMR page is explicit on defaults [@ms-qmr]. Cloud remediation is enabled by default, with one-time scan auto-remediation, on systems that are not under enterprise management -- Windows Home and unmanaged Pro. It is disabled by default on enterprise-managed systems -- Windows Enterprise, Education, and managed Pro. The rationale follows from how those populations think: enterprise administrators want to gate cloud remediation behind their own deployment-ring process, and consumers benefit from the default-on behaviour because they do not have a ring process at all. The same Microsoft Learn page documents an Intune Settings Catalog policy under Remote Remediation > Enable Cloud Remediation for administrators who want to switch the policy on at the tenant level [@ms-qmr].

The test-mode flow

QMR ships with a dry-run mechanism. reagentc.exe /SetRecoveryTestmode configures the WinRE entry for a simulated recovery cycle; reagentc.exe /BootToRe triggers the cycle on the next reboot; the simulated remediation appears in Settings > Windows Update > Update history rather than mutating the production OS [@ms-qmr]. Microsoft suggests using the test mode to validate the per-device QMR configuration before relying on it in production.

The pseudocode

The five phases collapse into a short loop. The version below is paraphrased from the Microsoft Learn QMR page [@ms-qmr] and shows how the two settings interact.

{` // Paraphrased from the Microsoft Learn QMR specification.

const config = { cloud_remediation_enabled: true, // default on Home/unmanaged Pro auto_remediation_mode: 'looped', // 'one_time' | 'looped' total_wait_time_minutes: 60, wait_interval_minutes: 10, wifi: { ssid: 'corp-recovery', psk: '***', encryption: 'WPA2' }, };

function detectFailureSignature() { return { driver: 'csagent.sys', offset: '0xe14ed', signature: 'oob-read' }; }

function scanWindowsUpdate(signature) { if (signature.driver === 'csagent.sys' && signature.signature === 'oob-read') { return { id: 'qmr-csagent-291', action: 'delete', path: 'C\\Windows\\System32\\drivers\\CrowdStrike\\C-00000291*.sys' }; } return null; }

function qmrEnterRecovery() { console.log('Phase 1: crash detected (two failed boots)'); console.log('Phase 2: booted into WinRE via BCD recoverysequence');

if (!config.cloud_remediation_enabled) { console.log('Cloud remediation disabled; falling back to Startup Repair'); return; }

console.log('Phase 3: acquiring network (' + config.wifi.encryption + ' Wi-Fi)'); const sig = detectFailureSignature(); let elapsed = 0;

while (true) { console.log('Phase 4: scanning Windows Update for remediation matching ' + sig.driver); const remediation = scanWindowsUpdate(sig); if (remediation) { console.log(' -> Applying ' + remediation.id + ' (delete ' + remediation.path + ')'); console.log('Phase 5: reboot into repaired Windows'); return; } if (config.auto_remediation_mode === 'one_time') { console.log('No remediation found; presenting manual recovery menu'); return; } elapsed += config.wait_interval_minutes; if (elapsed >= config.total_wait_time_minutes) { console.log('Looped mode exhausted; falling back to manual recovery menu'); return; } console.log(' -> No match; sleeping ' + config.wait_interval_minutes + ' min'); } }

qmrEnterRecovery(); `}

The counterfactual

Had QMR existed on July 19, 2024, the per-device labour would have been zero. Microsoft and CrowdStrike would have published a Windows Update remediation that deletes C-00000291*.sys; every affected device would have entered WinRE on its second failed boot, picked up the remediation, applied it, and rebooted. The 8.5-million-device fleet cost would have collapsed from operator-days to network-minutes. The CrowdStrike RCA published August 6, 2024 documents that the fault-to-rollback time was 78 minutes [@crowdstrike-tech-details, @crowdstrike-rca-pdf]; QMR would have made time-to-rollback and time-to-fleet-recovery the same number, plus the per-device Windows Update transit. That is the empirical case Microsoft is making.

Key idea: Quick Machine Recovery did not add new technology to WinRE. It added a question. WinRE has always had networking drivers; it had never been told it had permission to phone home. The technical innovation is policy, not code -- the Windows Update endpoint framing is a commitment that the recovery environment may, in well-defined circumstances, act on behalf of the operator who is not there.

QMR re-priced the per-device cost of recovery from O(N) to roughly O(1). But QMR alone does not explain why Microsoft is calling this the Windows Resiliency Initiative rather than the Quick Machine Recovery Release. The next section unpacks the five layers WRI puts around QMR.

7. The Program: The Windows Resiliency Initiative as Five Layers

WRI is not one feature. It is a layered program. Each layer is a Microsoft-named deliverable with a Microsoft-cited source. The temptation, on reading any single WRI blog post, is to confuse the layer with the program. The layers are concentric. They are also dated.

Walk the five layers. Each has a Microsoft term, a primary anchor, and a published status as of November 18, 2025.

Layer	Microsoft term	Anchor	Status as of Nov 18, 2025
Prevent: stop bad updates leaving the partner	Safe Deployment Practices (SDP), part of MVI 3.0	[@ms-wri-ignite-2024], [@ms-mvi], [@ms-wri-jun-2025]	Effective April 1, 2025 [@ms-wri-ignite-2025]
Prevent: stop bad code being kernel-resident	Windows endpoint security platform (user-mode antivirus)	[@ms-wri-ignite-2024], [@ms-wri-jun-2025], [@ms-wri-ignite-2025]	Private preview July 2025; named partners in [@ms-wri-jun-2025]
Manage: see the incident at scale	Intune surfaces WinRE state; Mission Critical Services for Windows	[@ms-wri-ignite-2025]	Coming soon
Recover: heal the unbootable machine	Quick Machine Recovery	[@ms-wri-ignite-2024], [@ms-qmr], [@ms-wri-ignite-2025]	GA August 2025
Recover: rebuild without shipping hardware	Point-in-Time Restore, Cloud Rebuild, Windows 365 Reserve	[@ms-wri-ignite-2025]	PITR Insider preview Nov 2025; W365R GA; Cloud Rebuild coming

flowchart LR subgraph L1[1. Prevent: stop bad updates at the partner -- MVI 3.0 SDP] subgraph L2[2. Prevent: stop bad code being kernel-resident -- user-mode AV platform] subgraph L3[3. Manage: see the incident at scale -- Intune surfaces WinRE state] subgraph L4[4. Recover the unbootable: Quick Machine Recovery] subgraph L5[5. Rebuild without shipping hardware: PITR / Cloud Rebuild / W365 Reserve] CORE[Windows endpoint -- recoverable at fleet scale] end end end end end

Layer 1: Safe Deployment Practices and MVI 3.0

Microsoft Virus Initiative 3.0 became effective on April 1, 2025 [@ms-wri-ignite-2025]. Membership now requires partners to commit to four named obligations [@ms-mvi]: a signed nondisclosure agreement; use of Microsoft Trusted Signing (the hosted descendant of Authenticode) for AV/EDR driver code-signing; documented Safe Deployment Practices for content updates (gradual rollouts with deployment rings and monitoring); and certification within the last 12 months by at least one of AV-Comparatives, AVLab Cybersecurity Foundation, AV-Test, MRG Effitas, SE Labs, SKD Labs, VB 100, or West Coast Labs [@ms-mvi]. The June 26, 2025 WRI update lists eight named partner endorsements -- Bitdefender (Florin Virlan), CrowdStrike (Alex Ionescu), ESET (Juraj Malcho), SentinelOne (Stefan Krantz), Sophos (John Peterson), Trellix (Jim Treinen), Trend Micro (Rachel Jin), and WithSecure (Johannes Rave) -- and the November 18, 2025 update confirms the effective date verbatim: "Effective April 1, 2025, Version 3.0 of the Microsoft Virus Initiative added new requirements for all Windows antivirus (AV) partners to maintain signing rights for Windows AV drivers" [@ms-wri-jun-2025, @ms-wri-ignite-2025].

Microsoft's program for third-party antivirus and endpoint detection vendors that ship products on Windows. MVI 3.0, effective April 1, 2025, adds Safe Deployment Practices, mandatory Trusted Signing, NDA, and 12-month independent test-lab certification as preconditions to maintain Windows AV driver signing rights [@ms-mvi, @ms-wri-ignite-2025].

The model is structurally identical to the canary / progressive-rollout pattern formalised in the Google SRE Book chapter on Release Engineering: hermetic builds, multiple deployment rings, gated promotion between rings, "Push on Green", and the option to cherry-pick at the same revision when a critical change is needed mid-cycle [@sre-release-eng]. MVI 3.0 is not a Microsoft invention; it is a Microsoft mandate of a model that has been industry practice for two decades. The mandate is what is new.

Layer 2: The Windows endpoint security platform

The same November 19, 2024 keynote committed to a Windows endpoint security platform that lets partners ship their detection logic outside kernel mode, with a private preview promised to security-partner programs by July 2025 [@ms-wri-ignite-2024]. The June 26, 2025 update confirmed the date with named partner endorsements [@ms-wri-jun-2025]. The architectural premise is the one BSOD survivors recognise immediately: a faulty user-mode component can be killed by Task Manager; a faulty kernel-mode driver bug-checks the system.

Graphics drivers, for example, will continue to run in kernel mode for performance reasons. -- Microsoft, *Preparing for what's next*, November 18, 2025 [@ms-wri-ignite-2025].

Microsoft is careful to frame WRI as a floor-raiser, not a kernel ban. The November 18, 2025 update enumerates the driver-resiliency playbook for the surfaces that will remain in kernel mode: mandatory compiler safeguards (control-flow integrity, CFG, stack canaries), driver isolation, DMA-remapping, a higher signing bar, and expanded in-box Microsoft drivers and APIs that third parties can call rather than reimplementing [@ms-wri-ignite-2025]. The argument is that the kernel surface that must exist (graphics, storage, some networking) should be smaller, better isolated, and equipped with mitigations that contain a single fault.

The June 2025 partner roster is the most pointed piece of evidence that the user-mode direction predates and outlasts the July 2024 incident. CrowdStrike itself is named [@ms-wri-jun-2025]. The vendor that started the chain reaction is publicly endorsing the architectural concession the chain reaction priced into existence.

The Windows Resiliency Initiative is not Microsoft's only post-2023 security program. The umbrella is the *Secure Future Initiative* (SFI), announced in November 2023 as the company-wide response to identity-based attacks on Microsoft itself. WRI is the workstream inside SFI that owns Windows availability, kernel resilience, and the recovery path; SFI also owns identity hardening, supply-chain controls, and engineering culture changes. Microsoft's published WRI blogs are explicit that the recoverability program is "the Windows pillar of our Secure Future Initiative" framing, not a stand-alone effort [@ms-wri-ignite-2024, @ms-wri-jun-2025].

Layer 3: Intune-surfaced WinRE state

The November 18, 2025 update names a new Intune signal: "Intune will surface when a Windows device has booted into the Windows Recovery Environment (WinRE)" [@ms-wri-ignite-2025]. The same signal will appear in the Azure Portal for Windows Server VMs that switched into WinRE. The same update introduces a WinRE plug-in model: IT administrators can push custom recovery scripts through Intune, with the model documented as third-party-MDM-adoptable. Both are "coming soon" as of that announcement [@ms-wri-ignite-2025].

The architectural insight here is that Microsoft-pushed remediations (QMR) and administrator-pushed remediations (Intune scripts) must be expressible against the same WinRE surface, with Intune providing the visibility and audit layer.

Layer 4: Quick Machine Recovery

Already covered in Section 6. Status: GA August 2025 on Windows 11 24H2 build 26100.4700+ [@ms-qmr, @ms-wri-ignite-2025]. Autopatch QMR management is in preview at the November 2025 announcement [@ms-wri-ignite-2025].

Layer 5: Rebuild without shipping hardware

The November 18, 2025 update introduces three Microsoft-cloud-side recovery actions [@ms-wri-ignite-2025]:

Point-in-Time Restore (PITR). Cloud-orchestrated rollback to an earlier point-in-time snapshot of the device's full state. Status: available in the Windows Insider preview build the week of the announcement.
Cloud Rebuild. Intune-portal-triggered clean OS reimage using Autopilot for zero-touch provisioning, with user data and settings restored from OneDrive and Windows Backup for Organizations. Status: coming.
Windows 365 Reserve. A temporary Cloud PC for users whose endpoint is unusable. Status: generally available.

Each of these targets a scenario QMR cannot fix. PITR addresses regressions that the user-mode WU pipeline cannot patch back -- driver downgrades that need to roll back state, not push a new patch. Cloud Rebuild addresses devices whose local Windows is genuinely beyond surgical repair. Windows 365 Reserve addresses the productivity gap while the local device is being recovered.

All five layers are anchored on Microsoft blogs and Microsoft Learn pages. None of them is unique to Microsoft. Apple, ChromeOS, and the Linux atomic distributions have each chosen a different layered architecture for the same problem. What does the field actually look like?

8. Competing Models: Apple, ChromeOS, and the Linux Atomic Distributions

Microsoft is not the first vendor to treat recovery as part of its security architecture. It is, at consumer scale, among the last. Apple, Google, and the Linux atomic-distribution community each picked a different layer to anchor on.

Apple macOS: Signed System Volume + paired/fallback recoveryOS + 1TR

macOS 10.15 (Catalina, 2019) introduced the read-only system volume. macOS 11 (Big Sur, 2020) added the Signed System Volume on top of it: a SHA-256 Merkle tree over every block of the system volume, sealed by Apple at install or update time [@apple-ssv]. On Apple Silicon, the bootloader verifies the seal before transferring control to the kernel; on Intel-based Macs with the T2 Security Chip, the bootloader forwards the measurement and signature to the kernel, which verifies the seal directly before mounting the root file system [@apple-ssv]. On verification failure, the Mac drops into recoveryOS automatically and prompts the user to reinstall.

The recovery side has three flavours [@apple-boot]: a paired recoveryOS that exactly matches the installed system version; on Apple Silicon, a fallback recoveryOS (the previous OS version); and a hardware-anchored 1TR ("one true recovery") environment that survives even when the paired recoveryOS is broken. The 1TR environment is anchored in the Secure Enclave, which is the macOS analogue of Windows's signed bootmgfw.efi on the EFI System Partition.

What Apple excels at is tampered system files and failed updates: the first block read fails Merkle verification; the snapshot pointer flips to the prior good snapshot; the user reboots into a working system. What Apple does not have is an analogue of QMR's targeted remediation pipeline. The macOS answer to a faulty signed third-party security agent is "reinstall macOS". That is wipe-and-reload, not surgical repair.

ChromeOS: Verified Boot + A/B root partitions + auto-rollback

ChromeOS's verified-boot design has been the same since 2010 [@chromium-verified-boot]. A read-only boot stub, anchored in write-protected EEPROM, computes a cryptographic hash of the read-write firmware (SHA-1 in the original 2010 specification; SHA-256 in current production firmware) and verifies an RSA signature (at least 2048 bits) against a permanently stored public key [@chromium-verified-boot]. The verified read-write firmware then hashes the kernel and verifies its signed hashes. A transparent block device in the kernel verifies each block against a stored hash tree on every read, with the tree's root signed by the firmware.

The recovery story is the brilliant part. ChromeOS devices have two root partitions, ROOT-A and ROOT-B, plus a separate stateful partition for user data [@chromium-autoupdate]. Each root partition carries a remaining_attempts counter (default 6) stored in unused GPT bits next to the bootable flag. On N consecutive failed boots, the boot loader falls back to the other partition. Auto-updates always write to the partition not currently in use, never the booted one. The result is that ChromeOS recovers from a faulty signed system update in one reboot per device, automatically, without an operator action. This is the empirical upper bound on automation: no fielded platform recovers a signed-but-faulty boot path faster than one reboot.

Linux atomic distributions: OSTree, rpm-ostree, bootc

OSTree, the upstream of Fedora's atomic desktops and CoreOS, is "Git for operating system binaries" [@fedora-silverblue]. It stores content-addressed objects under /ostree/repo, builds atomic deployments as hardlink farms under /boot/loader/entries/ostree-$stateroot-$checksum.$serial.conf, performs a three-way merge of /etc between the booted deployment and the new one, and atomically swaps the boot directory by flipping a symlink between /ostree/boot.0 and /ostree/boot.1 [@ostree-atomic]. The crash-safe guarantee is verbatim: "if the system crashes or you pull the power, you will have either the old system, or the new one" [@ostree-atomic].

Fedora Silverblue, Fedora CoreOS, Endless OS, and (since 2024) Fedora's bootc container-based desktops all ship OSTree by default [@fedora-silverblue]. Where OSTree excels is server fleets and developer workstations; where it struggles is layered third-party packages crossing deployments (the rebase/deploy friction) and the absence of a network-reachable in-recovery remediation analogue to QMR.

Traditional Linux: dracut + GRUB rescue + initramfs

The "manual safe-mode + delete-the-file" model. A skilled operator with shell access plus iLO / iDRAC / IPMI serial-over-LAN can repair a Linux box; everyone else is in trouble. The CrowdStrike-style incident response on traditional Linux would look exactly the same as it did on Windows: per-device, skilled operator, no automation. The Linux distributions that did avoid this fate are the OSTree-based atomic ones; the conventional ones are at the same operator-bound floor Windows just climbed off.

flowchart TB subgraph WIN[Windows: WinRE + QMR] WIN_WIM[winre.wim on recovery partition or in OS-volume folder] --> WIN_WU[Windows Update endpoint] end subgraph APL[Apple: macOS] APL_PR[Paired recoveryOS] --> APL_SNAP[APFS snapshot revert] APL_FB[Fallback recoveryOS / 1TR in Secure Enclave] --> APL_SNAP end subgraph CHR[ChromeOS] CHR_BOOTA[ROOT-A] --> CHR_FALLBACK[Boot loader falls back to other root] CHR_BOOTB[ROOT-B] --> CHR_FALLBACK end subgraph OS[Linux atomic / OSTree] OS_DEPNEW[New deployment] --> OS_PRIOR[Prior deployment retained for rollback] end

A head-to-head comparison

The dimensions that matter are: year shipped, in-recovery network capability, auto-remediation, signed-but-faulty-driver protection, per-device operator cost during a fleet event, trust floor, and encrypted-volume recovery story.

Dimension	Windows WinRE + QMR	Apple SSV + recoveryOS	ChromeOS A/B + verified boot	Linux atomic (OSTree)	Conventional Linux
Year shipped	WinRE 2007 [@wiki-winre]; QMR 2025 [@ms-qmr]	SSV 2020; recoveryOS / 1TR 2020 [@apple-ssv, @apple-boot]	Verified Boot 2010 [@chromium-verified-boot]	OSTree 2012 (dev started 2011); rpm-ostree later [@ostree-atomic, @fedora-silverblue]	dracut 2009; GRUB 2 2009
In-recovery network capability	Yes (WPA/WPA2 Wi-Fi or wired) [@ms-qmr]	Yes for reinstall; no targeted remediation	Yes for recovery image fetch	No standard pipeline	No
Auto-remediation without operator	Yes (one-time or looped) [@ms-qmr]	No (user confirms reinstall)	Yes (boot loader fallback) [@chromium-autoupdate]	No (user selects rollback in GRUB)	No
Protection against signed-but-faulty drivers	Behavioural via MVI 3.0 SDP + user-mode AV [@ms-mvi, @ms-wri-jun-2025]	DriverKit / System Extensions push third parties out of kernel	A/B rollback auto-recovers in one boot cycle	Layered package rolls back with deployment	None
Per-device operator cost in a fleet event	O(1) -- publish remediation once	O(N) -- each user reinstalls	O(0) -- automatic per device	O(N) -- each user selects rollback	O(N) -- skilled operator per device
Trust floor (unrecoverable without external media)	Corrupted `bootmgfw.efi`, missing WinRE, lost BitLocker key	Failed 1TR (very rare)	Both root partitions plus EEPROM corrupted	GRUB unreachable	GRUB unreachable
Encrypted-volume recovery story	BitLocker recovery key required [@ms-qmr]	FileVault key required if at-rest read needed	Stateful partition holds user data only	LUKS passphrase required	LUKS passphrase required

The notable row is the per-device operator cost during a fleet event. QMR moves Windows from O(N) (pre-WRI) to O(1) (post-WRI). ChromeOS was already at O(0) thanks to the A/B rollback. Apple, conventional Linux, and OSTree-based Linux remain at O(N).

Key idea: The per-device operator cost row is the one Microsoft engineered WRI to change. QMR moves Windows from O(N) to O(1). ChromeOS was already at O(0) by virtue of A/B rollback. Apple, conventional Linux, and OSTree-based Linux remain at O(N). This is the empirical justification for the thesis that resilience is a security property: pre-WRI Windows, despite shipping BitLocker, HVCI, and Secure Boot, had a recoverability complexity class worse than ChromeOS. A faulty signed driver could exploit that gap to deny service at fleet scale.

Three vendors got to fleet-scale recovery earlier. Microsoft's catch-up move is constrained by what Microsoft does not control: OEM partition layouts, BIOS/UEFI variance, BitLocker key escrow.Apple ships hardware-plus-OS and Google ships ChromeOS against an OEM-certified hardware spec, both of which let those vendors specify partition layout end to end. Microsoft ships the OS and asks OEMs to follow the Image Configuration Designer defaults; some do, some do not. The KB5028997 workaround for "recovery partition too small for new winre.wim" is precisely the artefact of Microsoft not being able to mandate the layout [@ms-winre-tech-ref, @ms-kb5028997]. Those constraints set hard limits on what WRI can fix, and they are the reason the trust-floor row in the table is longer for Windows than for ChromeOS.

9. Theoretical Limits and the BitUnlocker Counter-Current

Two well-known results from the systems and security literature say that no fielded recovery primitive can be perfect, and Microsoft's own offensive-research team demonstrated, at Black Hat USA 2025 in August 2025, exactly which limit WRI runs into [@alon-leviev].

The trust-floor lower bound

No system can recover from corruption of all of its boot-path code without external media, because the verification step that detects corruption is itself part of the boot-path code. ChromeOS encodes this with a write-protected EEPROM that an attacker cannot rewrite without a hardware write-protect override [@chromium-verified-boot]; Apple encodes it with the 1TR environment anchored in the Secure Enclave [@apple-boot]; Windows encodes it by requiring the EFI System Partition plus a signed bootmgfw.efi. Below that floor, QMR, OSTree, and APFS snapshots are all helpless. The recovery surface bounded by what fits in write-protected non-volatile storage is the lower bound on automated recovery.

The end-to-end argument applied to recovery

Saltzer, Reed, and Clark's 1984 End-to-End Arguments in System Design [@saltzer-reed-clark-1984] argued that correctness checks belong at the endpoints of a communication system, not in intermediate nodes. Applied to update pipelines, the argument predicts that bug-free updates cannot be guaranteed by intermediate nodes (the vendor's QA fleet, the CDN, the Windows Update service). Correctness can only be observed at the endpoint. The corollary is that the probability of a faulty update reaching production cannot be driven to zero by any amount of pre-release testing; the platform's design must instead bound blast radius and time-to-recovery of the faulty updates that will inevitably ship. MVI 3.0's SDP bounds the first (deployment rings); QMR bounds the second (network-reachable remediation). The argument is identical to the canary / progressive-rollout pattern in Google's SRE Book Release Engineering chapter [@sre-release-eng].

The attack-surface trade-off

An auto-unlocking, network-reachable recovery environment expands the Trusted Computing Base. Every additional capability added to the recovery path is a new code path; a new code path is a new attack vector. The BitUnlocker research, by Netanel Ben Simon and Alon Leviev at Microsoft's Security Testing and Offensive Research (STORM) team [@alon-leviev, @ms-bitunlocker-blog], is the most pointed evidence we have that the trade-off is real.

STORM -- Security Testing and Offensive Research at Microsoft -- is the internal red team. Their job is to break Microsoft products before someone else does. BitUnlocker was first presented at Black Hat USA 2025 and DEF CON 33, both in August 2025; the four CVEs were patched in the July 8, 2025 cumulative update, ahead of the disclosure [@alon-leviev, @ms-bitunlocker-blog]. The patches landed one Patch Tuesday cycle before QMR went generally available [@ms-wri-ignite-2025]. In the same summer, the same vendor that made WinRE reachable from Windows Update made WinRE harder to abuse. The set of hardware, firmware, and software components on which a system's security policy ultimately depends. A bug in a TCB component can undermine the entire security policy; everything outside the TCB is, by definition, untrusted relative to it. Recovery environments expand the TCB because they need privileged access to encrypted user state.

The four BitUnlocker CVEs are all rated CVSS 6.8:

CVE-2025-48804 [@ms-bitunlocker-blog] -- BitLocker Security Feature Bypass via boot.sdi parsing.
CVE-2025-48003 [@ms-bitunlocker-blog] -- BitLocker Security Feature Bypass via SetupPlatform.exe / Shift+F10 abuse during the WinRE Apps Scheduled Operation.
CVE-2025-48800 [@ms-bitunlocker-blog] -- BitLocker Security Feature Bypass via tttracer.exe abuse during Offline Scanning.
CVE-2025-48818 [@ms-bitunlocker-blog] -- BitLocker Security Feature Bypass via BCD parsing in the Online PBR exploit chain; the fourth pillar of the chain.

The published Microsoft Security blog post on BitUnlocker enumerates the architectural attack surfaces verbatim under three section headings: Attacking Boot.sdi Parsing, Attacking ReAgent.xml Parsing, and Attacking Boot Configuration Data (BCD) Parsing [@ms-bitunlocker-blog]. The premise is the same in every case. WinRE must read the OS volume's BitLocker recovery material to perform repairs. Therefore WinRE has code paths that, given the right inputs, can obtain the decrypted Full Volume Encryption Key. The four CVEs each find a parser or debugger inside WinRE whose input handling can be steered by an attacker with brief physical access to flip the recovery flow into a state where the decrypted FVEK becomes reachable.

flowchart TD PA[Physical access foothold] --> SDI[Attacking boot.sdi parsing -- CVE-2025-48804] PA --> RA[Attacking ReAgent.xml / SetupPlatform.exe -- CVE-2025-48003] PA --> BCD[Attacking BCD parsing / Online PBR -- CVE-2025-48818] PA --> TT[Abusing tttracer.exe Offline Scanning -- CVE-2025-48800] SDI --> FVEK[Reach decrypted FVEK on OS volume] RA --> FVEK BCD --> FVEK TT --> FVEK FVEK --> EX[BitLocker bypass; data exfiltration]

The encrypted-volume impossibility

Unattended recovery of an encrypted volume without the key is impossible. It is a security correctness requirement, not a limitation that engineering can fix. QMR explicitly does not bypass BitLocker [@ms-qmr]. Apple's FileVault, ChromeOS's TPM-bound user partition, and Linux LUKS all share this property; none of them gets to be exempt from the requirement that the key be present somewhere before the encrypted volume can be modified offline.

Note: Every additional capability added to the recovery path is an additional attack vector against the encrypted user state that the recovery path is privileged to access. QMR's network reachability is a feature for the operator and a feature for the attacker. The article's thesis is not WRI makes Windows safer in absolute terms; it is WRI moves the trade-off to a different curve. The same vendor making the recovery surface reachable from Windows Update is the vendor that has to harden it against itself.

The upper bound

ChromeOS A/B auto-rollback recovers a single device in one reboot cycle without operator action [@chromium-autoupdate]. This is the empirical upper bound on automation. No fielded platform recovers a signed-but-faulty boot path faster than one reboot per device. QMR matches the ChromeOS upper bound in the steady state once a remediation is published; the only thing QMR cannot do that ChromeOS does is recover from the first signed-but-faulty update before Microsoft has authored the remediation. The lower bound on time-to-fleet-recovery is set by the production lead time of Microsoft's own QA pipeline plus the time to author and publish the targeted patch.

Microsoft's own offensive-research team published the BitUnlocker chain one Patch Tuesday before QMR went generally available. That is not a coincidence; it is the price of moving WinRE up the trust ladder. The next question -- what has not been priced yet? -- belongs in the open-problems list.

10. Open Problems: Where Microsoft Has Not Committed

WRI is a current commitment with a published roadmap. The roadmap has explicit holes. Each of the six below is documented from a primary Microsoft source -- either by what the source says or, in the most honest cases, by what it does not say.

Network protocol surface in WinRE. The Microsoft Learn QMR page is explicit: only wired Ethernet and WPA/WPA2 password-based Wi-Fi are supported as of November 2025 [@ms-qmr]. Enterprise 802.1X and WPA3-Enterprise with device certificates are committed in the November 18, 2025 update as coming soon under the Wi-Fi 7 for Enterprise and WinRE-reads-from-Windows lines, but no shipping date is published [@ms-wri-ignite-2025]. For an enterprise on 802.1X, this is the most visible gap: a managed-fleet device on a corporate SSID cannot reach Windows Update from inside WinRE today.

Safe-mode hardening as a discrete deliverable. The phrase "safe mode hardening" has no first-party Microsoft anchor as a discrete WRI deliverable. The closest documented item is Administrator Protection, announced in the November 19, 2024 Ignite blog as a constraint on elevated-context behaviour [@ms-wri-ignite-2024]. That is not the same thing. The Safe Mode boot path that the CrowdStrike incident used to delete C-00000291*.sys was the same Safe Mode boot path that has existed since Windows NT; nothing in the WRI primary sources commits to changing what Safe Mode does or does not load. Honest reading: WRI re-prices the recovery surface around Safe Mode; it does not (yet) change Safe Mode itself.

Cross-vendor partition layout. The Microsoft Learn WinRE Technical Reference [@ms-winre-tech-ref] documents the recommended ICD-media layout but does not enforce it. Clean Windows Setup, OEM-installed Windows, and ICD-media-installed Windows produce different recovery-partition layouts, and the existence of KB5028997 (the well-known workaround for "recovery partition too small for the new winre.wim") is a direct consequence. ChromeOS and macOS do not have this problem because Google and Apple control the layout end to end. Microsoft chose, decades ago, not to.

Third-party MDM support for the WinRE plug-in model. The November 18, 2025 update describes the WinRE plug-in model as third-party-MDM-adoptable, but no third-party MDM vendor had shipped a plug-in or a QMR management surface as of that announcement [@ms-wri-ignite-2025]. Customers on JAMF, Workspace ONE, Tanium, or similar do not yet have a documented integration path. If the future of recovery is Intune-coupled, WRI's reach is bounded by Intune adoption.

BitLocker key escrow as a WRI deliverable. No WRI primary source ([@ms-wri-ignite-2024, @ms-wri-jun-2025, @ms-wri-ignite-2025]) names "BitLocker recovery key flows" as a discrete WRI deliverable. The adjacent items are: hardware-accelerated BitLocker on new devices starting spring 2026 [@ms-wri-ignite-2025]; the BitUnlocker CVE patches in July 2025 [@ms-bitunlocker-blog]; and the Entra ID self-service BitLocker recovery flow at aka.ms/aadrecoverykey [@ms-kb5042421]. The current state is that BitLocker key escrow is an Entra ID and Intune feature, not a WRI feature. QMR's value is bounded by BitLocker key availability for the encrypted-volume fraction of any fleet; a WRI deliverable that improved key escrow would compound QMR's benefit. None has been announced.

Recovery in air-gapped and sovereign environments. QMR routes through Windows Update. Air-gapped fleets, sovereign-cloud customers, and offline manufacturing networks cannot reach Windows Update from WinRE. The November 18, 2025 update mentions Connected Cache, but no QMR-Connected-Cache integration is committed [@ms-wri-ignite-2025]. For the high-assurance customer who today does not let manufacturing endpoints talk to the public Internet at all, QMR is a feature for someone else.

Note: The six items above are gaps in the roadmap, anchored either by what Microsoft has explicitly named as coming-soon or by the absence of a primary source. They are not features. The article distinguishes Microsoft-committed deliverables (cited to a primary source) from adjacent inferences. Readers reviewing WRI for their own fleets should do the same.

These six gaps are where the next year of WRI roadmap will be argued. None of them is closed; some are closed-soon. For the practitioner, the immediate question is what to do, today, with what is shipping right now.

11. Practitioner's Guide

Everything above is architecture. This section is the checklist.

1. Verify WinRE is provisioned. Run reagentc /info from an elevated prompt. The output should say Windows RE status: Enabled and point at a sensible WinRE location -- typically \?\GLOBALROOT\device\harddisk0\partitionN\Recovery\WindowsRE or C:\Windows\System32\Recovery\WindowsRE. If the status is Disabled, run reagentc /enable. If the recovery partition is too small for a new winre.wim (a known issue surfacing with cumulative updates that grow the image, surfaced as a System event ID 4502 with ErrorPhase 2), follow KB5028997 [@ms-kb5028997, @ms-winre-tech-ref].

The mitigation, in outline: disable WinRE temporarily (`reagentc /disable`); shrink the OS partition via `diskpart` by enough megabytes (250 MB minimum per Microsoft's published procedure) to host a larger recovery partition; recreate the recovery partition with the GPT Type ID `DE94BBA4-06D1-4D40-A16A-BFD50179D6AC` and the GPT attributes value `0x8000000000000001` that hides it from automounting; re-enable WinRE (`reagentc /enable`) so the new `winre.wim` is copied into the resized partition. The Microsoft Support KB article carries the exact `diskpart` commands [@ms-kb5028997], with the Windows RE Technical Reference as the architectural anchor [@ms-winre-tech-ref]. Test on a representative device first; the resize is not reversible without re-imaging.

2. Audit your QMR posture before turning it on. On Enterprise, Education, and managed Pro, cloud remediation is off by default [@ms-qmr]. Decide first; ring second; roll out third. The Intune Settings Catalog path is Remote Remediation > Enable Cloud Remediation. Pre-stage a WPA/WPA2 Wi-Fi credential via reagentc.exe /SetRecoverySettings if your recovery network is wireless.

3. Use the test-mode dry run. reagentc.exe /SetRecoveryTestmode followed by reagentc.exe /BootToRe triggers a simulated QMR cycle. The simulated remediation appears in Settings > Windows Update > Update history rather than mutating the production OS. Run it on a pilot ring before depending on QMR in a real incident [@ms-qmr].

4. Plan for BitLocker key availability. Ensure recovery keys are escrowed to Entra ID, not just printed on a card in a drawer. Enable the Entra ID self-service flow at aka.ms/aadrecoverykey so an unattended user can retrieve their own key during an incident [@ms-kb5042421].

5. Know the difference between Cloud Reset, QMR, and Autopilot Reset. Cloud Reset (in-Windows Reset this PC > Cloud download) reinstalls a running OS [@ms-pbr-overview]. QMR runs in WinRE before the OS boots, applying targeted patches from Windows Update [@ms-qmr]. Autopilot Reset re-provisions a bootable device via Intune. Three different tools, three different scenarios; do not confuse them in your runbook.

6. Watch for the November 2025 Intune signals. Once Intune surfaces WinRE state in the admin centre, build the muscle of looking for it. The roll-up that tells you "12 devices are in WinRE right now" is the operational primitive Microsoft did not have through July 2024 [@ms-wri-ignite-2025].

Note: Promote step 3 (the test-mode dry run) into your incident-response runbook now [@ms-qmr]. The time to discover that the recovery Wi-Fi SSID changed last quarter is not in the middle of a fleet-down event.

Note: QMR cannot decrypt the OS volume. It applies Windows Update patches that take effect on the next boot, but it cannot run against an encrypted volume's contents without the BitLocker recovery key being available [@ms-qmr]. If a device's BitLocker key is not escrowed to Entra ID and the user is not available to read it from a printout, QMR cannot help. Key escrow is upstream of recovery; treat it that way.

The reagentc /info output is short and uniform enough that a small script can classify the device's WinRE health. The block below sketches one in JavaScript pseudocode.

{` // reagentc /info is a small, deterministic text block. Parse it.

const sampleOutput = ` Windows Recovery Environment (Windows RE) and system reset configuration Information:

Windows RE status:         Enabled
Windows RE location:       \\\\?\\\\GLOBALROOT\\\\device\\\\harddisk0\\\\partition4\\\\Recovery\\\\WindowsRE
Boot Configuration Data (BCD) identifier: a1b2c3d4-...-winre-guid
Recovery image location:
Recovery image index:      0
Custom image location:
Custom image index:        0

REAGENTC.EXE: Operation Successful. `;

function classify(output) { const status = /Windows RE status:\s+(\w+)/.exec(output)?.[1]; const location = /Windows RE location:\s+(\S+)/.exec(output)?.[1] || ''; const partitionMatch = /partition(\d+)\\Recovery\\WindowsRE/.exec(location); const onPartition = !!partitionMatch; const onOsVolume = /^[A-Z]:\\Recovery\\WindowsRE/.test(location);

if (status !== 'Enabled') { return { status, action: 'reagentc /enable -- WinRE is not active' }; } if (!onPartition && !onOsVolume) { return { status, action: 'Unknown layout; verify with diskpart and reagentc' }; } if (onPartition) { return { status, layout: 'recovery-partition', partition: partitionMatch[1], note: 'If cumulative updates fail with insufficient-space errors, see KB5028997', }; } return { status, layout: 'os-volume-recovery-folder', note: 'OEM-style layout; some Intune' + ' policies assume a separate partition. Confirm before relying on remote remediation.' }; }

console.log(classify(sampleOutput)); `}

The practical questions answered, the article closes with a set of FAQs that catch the common misconceptions.

12. Frequently Asked Questions and Closing Thoughts

No. WRI's *Windows endpoint security platform* gives MVI partners a user-mode runtime so their detection logic does not have to live in a kernel-mode `.sys` file [@ms-wri-jun-2025, @ms-wri-ignite-2025]. Kernel-mode drivers as a class are not retired: the November 18, 2025 update is explicit that "graphics drivers, for example, will continue to run in kernel mode for performance reasons" [@ms-wri-ignite-2025], and the driver-resiliency playbook (compiler safeguards, driver isolation, DMA-remapping, higher signing bar) is precisely for the kernel-mode surface that will remain. No. The Microsoft Learn QMR page is explicit that the recovery flow does not decrypt the OS volume [@ms-qmr]. If the BitLocker recovery key is unavailable, QMR cannot help. The recommended escrow path is Entra ID, with the user-facing self-service flow at `aka.ms/aadrecoverykey` [@ms-kb5042421]. No. The BCD Boot Options Reference enumerates every legal element on a boot entry, and there is no `/recovery` flag on `winload.efi` or `winload.exe` [@ms-bcd]. WinRE is selected by following the `recoverysequence` element of the OS-loader entry to a separate BCD entry whose `winpe` is `Yes` and whose `osdevice` mounts `winre.wim` from a `boot.sdi`-backed RAM disk. The entire handoff is inside the boot manager, before `winload.efi` runs. No. The four CVE-2025-48800/-48003/-48804/-48818 advisories were patched in the July 8, 2025 cumulative update before QMR went generally available in August 2025 [@ms-bitunlocker-blog, @ms-wri-ignite-2025]. The patches addressed parser and debugger code paths inside WinRE; they did not remove WinRE's ability to read the OS volume's BitLocker recovery material, which is a feature WinRE needs in order to perform any repair on an encrypted volume. No. The Secure Future Initiative (SFI), announced in November 2023, is Microsoft's company-wide security program. WRI is the Windows-specific workstream inside SFI that owns Windows availability, kernel resilience, and the recovery surface; the published WRI blogs frame it as the Windows pillar of SFI rather than a stand-alone effort [@ms-wri-ignite-2024, @ms-wri-jun-2025]. QMR will not connect. The Microsoft Learn page is explicit that only wired Ethernet and WPA/WPA2 password-based Wi-Fi are supported [@ms-qmr]. The November 18, 2025 update commits to WPA3-Enterprise with device certificates as part of the WinRE-reads-from-Windows networking work and the *Wi-Fi 7 for Enterprise* line, but it does not give a shipping date [@ms-wri-ignite-2025]. For now, enterprises whose recovery story depends on QMR over Wi-Fi must either stand up a dedicated WPA2-PSK recovery SSID or rely on wired recovery. The code is mostly the same. What changed is the *policy* that lets WinRE call Windows Update without an operator at the keyboard. WinPE has shipped networking drivers since 2002 [@ms-winpe-intro], and `winre.wim` has been bootable from a recovery partition since 2009. The breakthrough is the commitment that the recovery environment is allowed to phone home -- and the surrounding program (MVI 3.0, the user-mode AV platform, Intune visibility) that makes it usable as a fleet-scale primitive.

Closing

The Windows Recovery Environment that worked perfectly on July 19, 2024 is the same Windows Recovery Environment that became Microsoft's most important security surface on August 1, 2025. The architecture did not change in the year between. The question we ask of it did.

The CrowdStrike incident did not invent the case for resilience as a security property. It priced it. Two months after the bug check signature csagent+0xe14ed made the rounds, Microsoft and the MVI cohort sat down at WESES to argue out what would become MVI 3.0 [@ms-weses]. Three months after that, the Ignite 2024 keynote committed to Quick Machine Recovery and to a user-mode antimalware platform [@ms-wri-ignite-2024]. Five months after that, the first QMR code shipped on the Beta Channel [@ms-qmr-insider-mar2025]. Twelve months after the incident, MVI 3.0 was binding [@ms-wri-ignite-2025]. Thirteen months after, QMR went generally available -- and BitUnlocker had been patched a month earlier in the July 2025 cumulative update. Sixteen months after, Microsoft published the rebuild-without-shipping-hardware roadmap [@ms-wri-ignite-2025].

WRI does not eliminate the trade-off between recoverability and attack surface. It moves the trade-off to a curve where the per-device cost of a fleet-down event is not bounded by human attention, and where the recovery code path is hardened by the same vendor's offensive-research team. Those are different curves than the ones the platform was on in July 2024. They are not the curves a textbook chapter on Windows internals would have predicted in 2014. They are also still the curves of a single vendor's program, anchored on a small number of blog posts and Microsoft Learn pages, and the work of validating them belongs in every fleet that depends on Windows for availability.

If WinRE worked perfectly on July 19, 2024 and that was the problem, the test of WRI is whether the next July 19, 2026 never makes the news.

The TPM in Windows: One Primitive, Twenty-Five Years, and the Chip Microsoft Bet On Twice

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

The TPM (1.2 since 2007, 2.0 since 2014) is the hardware root of trust under almost every Windows security feature shipped since Vista -- BitLocker, Measured Boot, Credential Guard, Windows Hello, device attestation. Twenty-five years of engineering refined a single primitive (measure, extend, seal, quote) into something one chip could underwrite. Twenty-five years of attacks (Andzakovic 2019, TPM-Fail 2020, faulTPM 2023) have argued empirically about how passive that chip can be. The current state of the art -- Microsoft Pluton on the CPU die, Microsoft-signed Rust firmware (on 2024 AMD and Intel platforms) delivered via Windows Update -- closes the bus and the TEE attack surfaces, but centralizes firmware trust on Microsoft. Post-quantum migration is the next frontier.

1. The chip nobody asked for

On June 24, 2021, Microsoft announced Windows 11 [@ms-windows-experience-blog-2021] -- and told hundreds of millions of working PCs they were no longer eligible to upgrade. Not because they were too slow. Because they did not have a small chip most users had never thought about: a TPM 2.0. The PR backlash was immediate; the technical rationale was almost invisible. Why was Microsoft willing to take that much heat over a piece of silicon?

The next morning, Microsoft's security team tried to explain [@ms-security-blog-windows11-2021]. The argument was four words long: hardware root of trust.

All certified Windows 11 systems will come with a TPM 2.0 chip to help ensure customers benefit from security backed by a hardware root-of-trust.

That sentence sat awkwardly against the user experience: a green checkmark in the PC Health Check tool, or a red X telling you to buy a new computer. The deeper claim -- that a passive cryptoprocessor underwrote the security guarantees of half the operating system -- was not something Microsoft had ever asked consumers to think about. For OEMs, the requirement was old news. Since July 28, 2016 [@ms-learn-oem-tpm], every new Windows device model had been contractually required to "implement and enable by default TPM 2.0." The 2021 mandate did not introduce the chip. It made an existing OEM rule into a visible install gate.

A small, isolated cryptoprocessor that holds keys, performs cryptographic operations, and records integrity measurements -- usually on a separate package or block of silicon that the host operating system cannot read directly. The TPM is "passive": it executes commands sent to it but never reaches into the host's memory. The PC Health Check tool was pulled and re-released. Reddit and Hacker News spent a weekend arguing about whether Microsoft had effectively bricked older hardware to sell new licenses. Microsoft's reply -- that TPM-by-default produces measurable population-level security gains even when individual users do not understand it -- was correct, but never quite the rebuttal that a consumer audience could engage with. The politics of "Trusted Computing" had returned, twenty years after the original Stallman objection [@wikipedia-trusted-computing].

This article is about that piece of silicon: what it does, why Windows needs it more than ever, and why twenty-five years of engineering and twenty-five years of attacks have together produced a chip that quietly defines what modern Windows can defend against -- and what it cannot.

The central claim, which the rest of this piece will earn: a passive cryptoprocessor designed in 1999 became the load-bearing pillar of half of Windows security, and the history of attacks against it has been a sustained empirical argument about exactly how passive that pillar is allowed to be.

2. The problem the TPM was built to solve

Picture an engineer at IBM in early 2000. The Windows kernel has just been rooted again. The newly shipped DPAPI master keys -- introduced with Windows 2000's general availability on February 17, 2000 [@wikipedia-windows-2000] -- are recoverable in seconds once SYSTEM falls. Stolen ThinkPads come back with their fresh EFS volumes already decrypted. Where do you put a secret that the OS cannot read?

Software-only key storage was Generation 0. Windows had DPAPI, EFS, and LSA secrets [@ms-learn-cryptography-portal], all deriving their wrapping keys from the user's logon credential or from system-level material. Every derivation had the same structural problem: the unwrapping key, sooner or later, lived in the kernel's address space. An attacker who reached SYSTEM (or who carried the disk away to a separate machine) could replay it. A volume encrypted "at rest" was decryptable as soon as the disk was readable -- and a disk you can read is a disk you can read offline. Microsoft now states the constraint plainly: a TPM-resident key, by contrast, "truly can't leave the TPM" [@ms-learn-how-windows-uses-tpm]. That property cannot be retrofitted onto software-only storage.

Key idea: Software-only key storage cannot defend against an attacker who reaches SYSTEM, and cannot defend against an attacker who carries the disk away. To survive both, the secret must live in silicon that the OS itself cannot read.

In October 1999 [@wikipedia-tcg], five PC-industry incumbents took that observation and turned it into an industrial coalition: Compaq, Hewlett-Packard, IBM, Intel, and Microsoft incorporated the Trusted Computing Platform Alliance.The Wikipedia Trusted Computing Group article gives the day-precision date as October 11, 1999. The original TCPA press release URL has not survived; the founder list and date are consistent across secondary sources. TCPA's charter was narrow: define a chip that could hold keys an x86 OS could not export, record boot-time integrity measurements, and sign attestations about that boot. The first chip to ship against the resulting TPM Main Specification 1.1b [@tcg-tpm-main-spec] appeared in 2003 [@wikipedia-tpm]. Atmel, Infineon, and STMicroelectronics built it [@wikipedia-tpm].

In parallel, Microsoft Research ran its own bet. Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman [@england-2003-trusted-open-platform] published "A Trusted Open Platform" in IEEE Computer, July 2003. The codename inside Microsoft was Palladium; the public name was the Next-Generation Secure Computing Base, NGSCB. It described a Windows where high-assurance code could run isolated from a possibly-compromised OS kernel, anchored in a hardware secure coprocessor that looked very much like a TPM. The motivating sentence read like a thesis: NGSCB extends personal computers "to offer mechanisms that let high-assurance software protect itself from the operating systems, device drivers, BIOS, and other software running on the same machine."

NGSCB never shipped as advertised. By 2005, reports indicated [@wikipedia-ngscb] that Microsoft would ship "only part of the architecture, BitLocker, which can optionally use the Trusted Platform Module to validate the integrity of boot and system files prior to operating system startup." The "Nexus" hypervisor, the user-mode high-assurance "agents," the protected paths for keyboard and display -- all dropped against the Vista deadline.The deadline pressure on Vista is legendary. The architecture team chose to ship the smallest piece of NGSCB the existing chip could underwrite -- BitLocker -- and shelved the rest. That shelved piece eventually returned, fifteen years later, as Virtualization-Based Security and Credential Guard.

The shelved primitives, however, did not die. Measured boot -- the firmware measures the boot loader, the boot loader measures the kernel, each measurement extended into a register that cannot be rewound -- migrated into Vista BitLocker and, later, into Windows 8 Measured Boot. Sealed storage -- a key tied to a measured boot state, unreleasable unless the boot state matches -- became the defining property of every TPM-bound BitLocker volume. Remote attestation -- a device signing a quote of its own measurements for a remote verifier -- became Device Health Attestation. NGSCB shipped, just not as itself.

In the early 2000s, Richard Stallman and the Free Software Foundation framed Trusted Computing as "treacherous computing" [@wikipedia-trusted-computing]: hardware secured "for its owner, but also against its owner." That objection has aged unevenly. The DRM concerns the FSF predicted did not dominate -- Hollywood never got the protected video paths it wanted on PCs. The trust-centralization concern has aged well: the modern Pluton debate raises a structurally similar question about who holds the signing key on the world's PC fleet, and the answer is now political rather than technical.

TCPA had built a chip that could hold a key the OS couldn't read. Which keys, under whose authority, against which threats? The first answer was almost good enough -- and it lasted about a decade.

3. Generation 1 and Generation 2: TPM 1.1b -> 1.2, and why they failed

If you opened a 2007 ThinkPad and looked at the LPC bus next to the Super-IO chip, you would see a small Infineon SLB chip [@andzakovic-2019-tpm-sniffing]. That was your TPM 1.2. It did exactly one job, and Vista's BitLocker was the first feature to depend on it.

The architectural skeleton of TPM 1.x [@wikipedia-tpm] was simple. At least sixteen Platform Configuration Registers, with the PC Client TPM Interface Specification mandating 24 per active bank. Hash algorithm: SHA-1. Asymmetric algorithm: RSA-2048. A single root of storage, the Storage Root Key, whose private half never left the chip. An Endorsement Key burned in at manufacture as the chip's permanent identity. An HMAC-SHA1 authorization model over command parameters. A "Take Ownership" ceremony where the platform owner created the SRK and bound it to an owner secret.

A TPM-internal register modified only by a one-way "extend" operation: $\text{PCR}_{\text{new}} = H(\text{PCR}_{\text{old}} \,\|\, \text{measurement})$. Static PCRs (0-15) cannot be rolled back without a full platform reset. TPM 2.0 also defines *dynamic* PCRs (16, 17-22, and 23 in the PC Client profile) that can be reset at specific localities via `TPM2_PCR_Reset`. DRTM uses PCRs 17-22 at locality 4 to re-launch a known measurement chain mid-run; PCRs 16 and 23 are resettable at lower localities for debug and application use. Either way, PCRs are the data structure that compresses a chain of measurements into a single attestable digest. The TPM's permanent identity key, generated at manufacture and accompanied by an EK certificate from the chip vendor's CA. The EK is non-migratable and is used during attestation to prove that a given key was generated inside a genuine TPM. It is also the privacy-sensitive part of TPM identity: the EK is unique to one chip, so unrestricted use of the EK in attestation reveals which physical machine you are. The root of the TPM's key hierarchy. In TPM 1.x there was exactly one SRK per chip, created during the "Take Ownership" ceremony. Every protected key in the hierarchy was a child of the SRK -- if you cleared the SRK, every key tied to it was lost. A restricted signing key the TPM uses to sign quotes of PCR values for a remote verifier. Naming changed with the spec: in TPM 1.x it was the Attestation Identity Key (AIK), a separate RSA key whose binding to a real TPM was asserted by a Privacy CA's certificate over the EK. In TPM 2.0 it is the Attestation Key (AK), a primary key in the Endorsement Hierarchy *derived from the same Endorsement Primary Seed as the EK* -- the AK is a sibling of the EK, not a copy, and it is certified by the EK rather than being an alias of it. Either way, the AIK/AK signs the quote; the EK never directly signs anything.

TPM 1.2 [@wikipedia-tpm], shipped in late 2003 and standardized as ISO/IEC 11889:2009, layered on the practical machinery: locality (a way for code at different privilege levels to extend different PCRs), monotonic counters, NV indices, transport sessions, and the eight-PCR split between firmware (PCR[0..7]) and OS (PCR[8..15]). It was the chip that mass-deployed in essentially every business PC from 2006 to 2014. When Windows Vista [@wikipedia-ngscb] reached volume-license RTM in late 2006 and broad availability in early 2007, BitLocker [@ms-learn-bitlocker] (Enterprise and Ultimate editions only) became the first mainstream Windows feature whose security depended on the chip: BitLocker sealed the Volume Master Key to PCR values describing the boot-loader chain, so that a stolen disk could not be decrypted offline. Secure Boot binding (PCR[7]) would not arrive until UEFI Secure Boot [@ms-learn-oem-secure-boot] shipped with Windows 8 in 2012.

flowchart TD EK["Endorsement Key (EK)
RSA-2048, burned at manufacture"] Owner["Owner secret
(Take Ownership)"] SRK["Storage Root Key (SRK)
RSA-2048, single per chip"] K1["Storage key
(child)"] K2["Binding key
(child)"] K3["Signing key
(child)"] AIK["Attestation Identity Key
(independent RSA key)"] PCA["Privacy CA"]

Owner --> SRK
SRK --> K1
SRK --> K2
SRK --> K3
AIK --> PCA
EK -. cert .-> PCA

The problem with all of this was not that anyone broke it. The problem was that the architecture hard-coded its cryptographic primitives into its data structures. SHA-1 was not a configurable algorithm; it was the literal width of the PCR register and of every hash field in the spec. RSA-2048 was not a configurable algorithm; it was the literal layout of the EK, the SRK, and every protected key blob. If the world deprecated SHA-1, you did not patch the firmware. You replaced the chip.

NIST SP 800-131A deprecated SHA-1 [@nist-sp-800-131a-r2] digital signatures starting in 2011. The 2017 SHAttered collision [@google-2017-shattered] drove the point home.The 2017 SHAttered SHA-1 collision does not retroactively break Vista BitLocker in practice -- to do that, an attacker would have to choose firmware blobs whose hashes collide, not merely demonstrate a collision exists. But it ended any defense of "SHA-1 in PCRs is fine because nobody can collide it." Algorithm flexibility cannot be retrofitted onto silicon whose data structures hard-code SHA-1. There were other limitations: a single SRK hierarchy meant clearing the chip's storage hierarchy also reset chip identity; the Privacy CA model for attestation never deployed at scale; ECC was missing; and the HMAC-based authorization model made every command exchange a piece of bespoke crypto plumbing.

Generation	Year	Hash	Asym	Hierarchies	Status
Software-only (LSA / PStore)	1996+ [@wikipedia-windows-nt-4]	varies	varies	n/a	NT 4.0 baseline; disk-readable wrapping keys
Software-only (DPAPI / EFS)	2000+	varies	RSA-1024 (EFS)	n/a	Defeated by offline disk theft and by SYSTEM compromise
TPM 1.1b	2003	SHA-1	RSA-2048	1 (SRK)	First mass deployment; superseded by 1.2
TPM 1.2	2003-2014	SHA-1	RSA-2048	1 (SRK)	Vista/7/8 BitLocker baseline; algorithm-rigid
TPM 2.0	2014+	SHA-1 + SHA-256 (+ SHA-3, future PQC)	RSA, ECC	4 (Platform / Endorsement / Storage / Null)	Current; ISO/IEC 11889:2015

TCG accepted the constraint in 2014 and started over. The 2.0 design did not add features to 1.2. It answered a different question: how do you let one TPM survive twenty years of cryptographic transitions?

4. Generation 3: TPM 2.0 -- one primitive, many algorithms

On April 9, 2014 [@wikipedia-tpm], the Trusted Computing Group [@tcg-tpm2-library-spec] did something rare in standards bodies: they threw away a working specification and started from a different question. The result was the TPM 2.0 Library Specification, Family 2.0, Level 00, Revision 116. A year later it became ISO/IEC 11889-1:2015 Edition 2 [@iso-iec-11889-1-2015], which removed the "industry consortium" objection from procurement teams in regulated environments. By July 28, 2016 [@ms-learn-oem-tpm], Microsoft had quietly made TPM 2.0 a contractual must-have for every new Windows OEM SKU.

Four conceptual changes carry the architecture.

4.1 Algorithm agility

Every cryptographic algorithm in TPM 2.0 carries an integer identifier. PCRs no longer have a single hash; they have banks, one per supported algorithm, all extended in parallel by a single command. Microsoft's own documentation [@ms-learn-how-windows-uses-tpm] describes the contract: when firmware extends PCR[0] with the IBV's CRTM measurement, the TPM extends both the SHA-1 bank and the SHA-256 bank, and on newer parts the SHA-384 bank as well.The PC Client Platform TPM Profile mandates SHA-1 + SHA-256 minimum, not SHA-256-only. Backwards compatibility had a cost. Future-proofing against SHA-3 and post-quantum algorithms is now a matter of registering a new ID, not replacing silicon.

A property of a cryptographic protocol or device whereby the choice of hash, signature, or encryption algorithm is decoupled from the protocol's data structures. Algorithm-agile systems carry algorithm identifiers alongside their cryptographic blobs, so a new algorithm can be added by registering an ID rather than by re-laying out the wire format. TPM 2.0 is algorithm-agile; TPM 1.x was not.

4.2 Four hierarchies, four primary seeds

Where TPM 1.x had a single SRK, TPM 2.0 has four hierarchies -- Platform, Endorsement, Storage, Null -- each rooted in a per-hierarchy primary seed. Primary keys are derived deterministically: call TPM2_CreatePrimary with the same template against the same seed, and you get the same key back, byte-for-byte. The Apress textbook by Arthur, Challener, and Goldman [@arthur-challener-goldman-2015] -- the de-facto developer reference for the spec -- describes this as the architectural fix to a real operational problem: the platform owner can clear the storage hierarchy without losing the device's endorsement identity.

flowchart TD subgraph Platform["Platform Hierarchy
(firmware-only)"] PSeed["Platform Primary Seed"] PSRK["Platform SRK"] PSeed --> PSRK end subgraph Endorsement["Endorsement Hierarchy
(privacy-sensitive)"] ESeed["Endorsement Primary Seed"] EK["EK"] AK["AK
(restricted signing)"] ESeed --> EK ESeed --> AK EK -. cert .-> AK end subgraph Storage["Storage Hierarchy
(owner-cleared)"] SSeed["Storage Primary Seed"] SRK["SRK"] Sealed["Sealed VMK
(BitLocker)"] Bound["Hello key
(per-user)"] SSeed --> SRK SRK --> Sealed SRK --> Bound end subgraph Null["Null Hierarchy
(reset on every reboot)"] NSeed["Null Primary Seed
(per-boot random)"] end

4.3 Enhanced Authorization

The most interesting change is how TPM 2.0 talks about access control. Every protected object has a policyDigest, an algorithm-agile hash of an arbitrarily complex set of conditions. To use the object, the caller starts a policy session (TPM2_StartAuthSession with TPM_SE_POLICY) and walks predicates -- TPM2_PolicyPCR, TPM2_PolicyAuthorize, TPM2_PolicySigned, TPM2_PolicyCommandCode, TPM2_PolicyAuthValue -- each extending the running session digest. At the end, the TPM checks that the session digest matches the object's policyDigest, and only then authorizes the operation. BitLocker, in its current Microsoft Learn description [@ms-learn-bitlocker], uses this to seal the Volume Master Key to PCR[7] (Secure Boot policy) and PCR[11] (BitLocker control flags). Any tampering with Secure Boot configuration -- or any non-BitLocker boot path -- causes unseal to fail.

TPM 2.0's flexible authorization mechanism. Each protected object carries a hash (policyDigest) of the predicates required to use it. A caller builds an equivalent digest by walking a sequence of TPM2_Policy* commands inside a policy session; the TPM only authorizes the operation if the two digests match. This is the mechanism that lets BitLocker bind the VMK to specific PCR values, lets Hello bind a key to a PIN gesture with anti-hammering, and lets attestation servers compose policies they did not design into the chip.

4.4 The unifying primitive: measure, extend, seal, quote

The reason any of this matters for Windows is that the entire feature surface compresses down to four operations on the same set of registers.

Measure. A piece of code computes the hash of the next piece of code (or configuration) about to run.
Extend. That hash is folded into a PCR via PCR_new = H(PCR_old || hash). The operation is one-way: PCRs cannot be rewound.
Seal. A symmetric key (or arbitrary blob) is encrypted under the TPM's Storage hierarchy with a policyDigest that names a specific set of PCR values. TPM2_Unseal releases the blob if and only if the live PCR state matches.
Quote. The TPM signs a snapshot of selected PCRs with an Attestation Key. A remote verifier can check the signature against a known AKpub and an EK certificate chain.

The boot of a measured Windows machine is exactly this loop. The Core Root of Trust for Measurement -- a small piece of immutable firmware -- measures the next stage and extends PCR[0]. Each stage measures the next: PCR[2] for option ROMs, PCR[4] for the Windows Boot Manager, PCR[7] for the Secure Boot policy, PCR[11] for BitLocker volume control flags, and on through ELAM and the kernel. Microsoft's Trusted Boot description [@ms-learn-secure-boot-process] walks the chain.

sequenceDiagram participant FW as Firmware (CRTM) participant BM as Bootmgr participant Win as Windows kernel participant TPM as TPM FW->>TPM: PCR_Extend(PCR[0], H(firmware)) FW->>BM: Hand off BM->>TPM: PCR_Extend(PCR[4], H(bootmgr)) BM->>TPM: PCR_Extend(PCR[7], H(SecureBoot policy)) BM->>Win: Hand off Win->>TPM: PCR_Extend(PCR[11], H(BitLocker control)) Win->>TPM: TPM2_Unseal(VMK, policyDigest = PCR[7],PCR[11]) TPM-->>Win: VMK if PCRs match policy, else error

Now compress the Windows feature catalogue against those four operations.

BitLocker [@ms-learn-bitlocker] seals the VMK to a PCR policy.
Measured Boot and Device Health Attestation [@ms-learn-azure-measured-boot] quote PCRs to a remote verifier.
Credential Guard [@ms-learn-credential-guard] seals the VBS-isolated NTLM/Kerberos secrets with a policy that includes the VBS measurement.
Windows Hello for Business [@ms-learn-hello-for-business] creates a per-user RSA-2048 or P-256 key whose authorization policy requires the PIN gesture and is bounded by the TPM's anti-hammering counter.
Virtual smart cards, DPAPI-NG, and TPM key attestation [@ms-learn-tpm-key-attestation] for ADCS-issued certificates all sit on the same primitives.

Note: BitLocker, Measured Boot, Credential Guard, Windows Hello, virtual smart cards, DPAPI-NG, and TPM key attestation are not seven independent uses of a chip. They are seven policy expressions over the same four operations -- measure, extend, seal, quote -- on the same PCR set. The TPM is not a checkbox shared by features. It is one primitive that defines what hardware-rooted security can do in Windows.

Key idea: One primitive -- measure, extend, seal, quote -- underwrites every Windows hardware-rooted security feature shipped since Vista. The TPM's value to Windows is not a list of cryptographic operations. It is a single, composable contract: "this key only releases when the boot looks like this."

By July 28, 2016, TPM 2.0 was a hidden contractual requirement under the entire Windows OEM channel. By June 24, 2021, Microsoft made the same chip the visible install gate for Windows 11. The architecture had won the building. Then attackers started taking it apart.

5. The threat model collapses inward (2019-2024)

On March 13, 2019, a New Zealand security researcher named Denis Andzakovic posted a blog entry [@andzakovic-2019-tpm-sniffing] that, in retrospect, started the modern era of TPM offense. He demonstrated two LPC-bus sniffing attacks on two different machines. On an HP business laptop running TPM 1.2, he used a DSLogic Plus logic analyzer connected via the laptop's debug header (7 wires: LCLK, LFRAME, LAD[0:3], and ground) to lift the BitLocker Volume Master Key off the LPC bus. On a Surface Pro 3 running TPM 2.0, he spent $40 NZD on a Lattice iCE40 ICEStick FPGA (8 connections: GND, LCLK, LFRAME#, LRESET#, LAD[0:3]) and replicated the attack. With the disk in hand and the motherboard accessible, a thief could decrypt a TPM-only BitLocker volume in the time it took to boot it once. Andzakovic open-sourced the FPGA gateware [@andzakovic-lpc-sniffer-code] the same day.Andzakovic credits Hector Martin (@marcan) for prototyping LPC sniffing earlier; the 2019 write-up was the first end-to-end public demonstration with reproducible code.

The structural insight, which has not been backed away from, is that Windows does not enable TPM 2.0 parameter encryption on the BitLocker boot path. The VMK travels in plaintext at the LPC bus's 33 MHz clock across a few millimetres of PCB.Why doesn't Windows turn on parameter encryption for BitLocker? The boot-time pressure is real -- pre-OS code lives in a tight memory budget and parameter encryption requires HMAC-signed sessions. The pragmatic mitigation Microsoft documents is preboot authentication (PIN or startup key), which makes the bus-sniffed VMK insufficient on its own.

The attack would not stay a one-laptop curio. In late 2020, F-Secure's (later WithSecure) Henri Nurmi released an SPI variant [@withsecure-2020-spi-sniffing] and a public BitLocker-key extraction tool. A year later, Thomas Dewaele and Julien Oberson at SCRT reproduced the LPC attack [@scrt-2021-tpm-sniffing] on a Lenovo ThinkPad L440 with a chip (labeled P24JPVSP, identified by SCRT as probably equivalent to the ST33TPM12LPC) and published a tutorial. By October 2024, SCRT had industrialized the attack [@scrt-2024-bitlocker-pin] across "the three major enterprise-grade laptop manufacturers (i.e. Lenovo, HP, and Dell)" in "a few minutes."

The first reassurance the industry reached for was: ship the TPM inside the chipset. No bus, no sniff. Both Intel (Platform Trust Technology, fTPM-in-CSME [@wikipedia-intel-me]) and AMD (fTPM-in-PSP) had already done this for cost reasons. The second reassurance lasted eight months.

In November 2019, Daniel Moghimi, Berk Sunar, Thomas Eisenbarth, and Nadia Heninger -- soon to be USENIX Security 2020 -- released TPM-Fail [@tpmfail-microsite]. Their finding: Intel PTT and a STMicro ST33 dTPM both leaked ECDSA private keys through ordinary timing side channels in their scalar multiplication. The numbers were brutal:

A local adversary can recover the ECDSA key from Intel fTPM in 4-20 minutes depending on the access level. We even show that these attacks can be performed remotely on fast networks, by recovering the authentication key of a virtual private network (VPN) server in 5 hours. -- TPM-Fail, tpm.fail [@tpmfail-microsite], 2019

NVD assigned CVE-2019-11090 [@cve-2019-11090] to Intel PTT and CVE-2019-16863 [@cve-2019-16863] to STMicroelectronics' ST33TPHF2ESPI. The latter entry is blunt: "STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL." Both chips were certified at the moment of disclosure -- the STMicro chip held both Common Criteria EAL4+ and FIPS 140-2 Level 2, while the Intel chip held FIPS 140-2 [@tpmfail-microsite]. Certification did not catch the bug. The presentation is preserved in the USENIX Security 2020 proceedings [@moghimi-2020-usenix-tpmfail].

Note: Removing the bus did not remove the attack surface. It relocated it from the PCB to the trusted execution environment that hosted the firmware TPM. The fTPM closes one channel and opens another -- and the certification regime that was supposed to catch both missed the timing leak in chips that had passed their respective certification programmes (STMicro: Common Criteria EAL4+ and FIPS 140-2 Level 2; Intel: FIPS 140-2). The "fTPM has no bus to sniff" reassurance was a category error.

The final beat came four years later. In April 2023, Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert posted faulTPM (arXiv:2304.14717) [@jacob-2023-faultpm], with reproducible code at github.com/PSPReverse/ftpm_attack [@pspreverse-ftpm-attack]. The attack: voltage-glitch the AMD Platform Security Processor and walk out with the entire internal TPM state. The paper's own claim is the sentence that, more than any other, framed the modern TPM threat model.

this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection. -- Jacob, Werling, Buhren, Seifert, faulTPM (2023) [@jacob-2023-faultpm]

Two to three hours of physical access. Anti-hammering bypassed because anti-hammering is enforced by the TPM, and once the TPM's internal state is on your bench you set the counter to zero. PCR-policy bypassed because the sealed blob's wrapping key is in the extracted state. The structural punch is that this makes BitLocker TPM+PIN on AMD fTPM with a low-entropy PIN less secure than a TPM-less passphrase (a corollary the faulTPM paper makes explicit [@jacob-2023-faultpm]): the TPM concentrates all your trust into a chip whose internal state can be exfiltrated.

timeline title Three generations of TPM attack section Bus sniffing 2019 March : Andzakovic - \$40 FPGA, BitLocker VMK off LPC bus 2020 December : WithSecure - SPI variant and key-extraction tool 2021 November : SCRT reproduces on Lenovo ThinkPad L440 2024 October : SCRT - few-minute attack on Lenovo, HP, Dell section Side channel in fTPM 2019 November : TPM-Fail (Moghimi, Sunar, Eisenbarth, Heninger) 2019 November : CVE-2019-11090 (Intel PTT), CVE-2019-16863 (STMicro) section Fault injection in fTPM 2023 April : faulTPM - full AMD fTPM state extracted in 2-3 h

Attack class	TPM form	Cost	Time	Source
LPC bus sniffing (BitLocker VMK)	Discrete TPM 1.2 / 2.0	$0 (logic analyzer) -- ~$40 NZD (iCE40 FPGA, Surface Pro 3)	Minutes once wired	Andzakovic 2019; SCRT 2021/2024
SPI bus sniffing	Discrete TPM 2.0	~$50 (logic analyzer)	Minutes once wired	WithSecure 2020-2024
Timing side channel on ECDSA	Intel PTT, STMicro ST33	Software-only	4-20 min local; 5 h remote VPN	TPM-Fail 2019/2020
Voltage glitch on PSP	AMD fTPM	~$200 (glitching rig)	2-3 h physical	faulTPM 2023

If a $40 FPGA defeats discrete TPM, a network packet defeats Intel PTT, and a few hours of physical access defeats AMD fTPM completely -- where does the next generation of TPM live? Microsoft's answer was on the CPU die itself.

6. State of the art: five realizations of one specification

All five chips in this section pass the same TCG conformance suite. They expose the same TPM2_* command surface to Windows. They fail to completely different attackers. The architecture is identical; the attack surface is everything.

A *discrete* TPM is a separate chip on the motherboard, talking to the host over LPC, SPI, or I2C. A *firmware* TPM is a TPM 2.0 implementation running inside an existing trusted execution environment on the host -- Intel CSME (Platform Trust Technology), AMD PSP (fTPM), or a dedicated Microsoft IP block (Pluton). Both pass the same TCG specification; they differ in physical location, attack surface, and update channel. A zero-knowledge protocol that lets a TPM prove "I am a real TPM certified by vendor X" without revealing which chip is talking. Replaces the TPM 1.2 Privacy CA model, which required a third-party CA to mediate every attestation. ECDAA is the elliptic-curve variant standardized in TPM 2.0.

6.1 Discrete TPM

The classical chip. Infineon, STMicroelectronics, Nuvoton. Hangs off the motherboard's LPC, SPI, or I2C bus. Best certifications (Common Criteria EAL4+, FIPS 140-2/3). One bug class: bus sniffing in minutes for $40 against the BitLocker boot path that Windows leaves in plaintext.

6.2 Intel PTT

TPM 2.0 inside the Converged Security and Management Engine -- historically on the Platform Controller Hub die, and increasingly on the SoC die in integrated-platform Intel processors since Tiger Lake. Either way, no physical bus to sniff. Defeated by TPM-Fail [@tpmfail-microsite] timing side channel; firmware-patched, but inherits CSME's broader attack surface and CSME's update story (UEFI capsule via OEM, lifecycle entirely under the OEM's control).

6.3 AMD fTPM (PSP)

TPM 2.0 inside the AMD Platform Security Processor [@wikipedia-amd-psp] (an ARM TrustZone Cortex-A5 core integrated into every modern Ryzen SoC). Ships in essentially all Ryzen-class client SoCs since 2017. No physical bus to sniff. Defeated end-to-end by the faulTPM [@jacob-2023-faultpm] voltage-glitch attack against the PSP. The structural problem is shared TEE: the same coprocessor is responsible for memory encryption setup, secure-boot enforcement, and TPM service, and a single fault-injection path drops all of those.

6.4 Microsoft Pluton

A Microsoft IP block on the CPU SoC die, with Microsoft-authored Rust firmware (on 2024 AMD and Intel platforms) [@ms-learn-pluton] delivered through Windows Update. According to Microsoft's hardware list, Pluton "is currently available on devices with the following chipsets running on Windows 11: AMD: Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series ... Intel: Core Series Processors -- Ultra 200V Series, Ultra Series 3 and Series 3 ... Qualcomm: Snapdragon 8cx Gen 3 and Snapdragon X Series." The same page notes that "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety."

The thesis is laid out in Microsoft's November 17, 2020 announcement post [@ms-pluton-blog-2020], which links explicitly to Andzakovic. The architectural framing is unusually direct.

The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU. -- Microsoft Security Blog, November 17, 2020 [@ms-pluton-blog-2020]

Three things change at once. The bus is gone -- Pluton is on-die, so dTPM bus-sniffing has no surface to attack. The TEE host is dedicated -- Pluton is not the same coprocessor that runs SEV memory encryption or ME runtime services. And the firmware ships through Windows Update -- so when a Pluton firmware vulnerability is found (and one will be found), the patch reaches the deployed fleet through Windows Update rather than through OEM UEFI capsule rollouts.The Pluton-as-TPM page makes the trade-off explicit: "Microsoft Pluton can be used as a TPM, or with a TPM. Although Pluton builds security directly into the CPU, device manufacturers might choose to use discrete TPM as the default TPM." [@ms-learn-pluton-as-tpm] Several enterprise security teams have publicly cited the Pluton update model as a reason to keep dTPM as their default for high-assurance fleets even where Pluton silicon is available.

6.5 vTPM

A software TPM emulation, typically inside a hypervisor. Azure Trusted Launch [@ms-learn-azure-trusted-launch] is Microsoft's flagship implementation: "Trusted Launch is the default state for newly created Azure Gen2 VM and scale sets." The vTPM lives in a host-protected memory region and inherits the trust of the host. For cloud workloads where the threat model already includes "the hypervisor host is honest," this is the right shape; for adversarial physical access, it is not.

6.6 Head-to-head

Dimension	dTPM	Intel PTT	AMD fTPM	Pluton	vTPM
Physical location	Separate chip	CSME (PCH die)	PSP (CPU die)	Dedicated IP block on CPU die	Hypervisor memory
Bus to host	LPC / SPI / I2C	None (on-die)	None (on-die)	None (on-die)	None (virtual)
TEE shared with	none (own die)	CSME	PSP (large)	none (Pluton-only)	host kernel
Side-channel exposure	Implementation-dependent	TPM-Fail patched	faulTPM unaddressed structurally	Limited public research	host-dependent
Update channel	UEFI capsule	UEFI capsule (CSME)	UEFI capsule (PSP)	Windows Update	hypervisor patch
Certifications	EAL4+, FIPS 140-2/3	EAL4+	varies	varies	n/a
OEM cost	per-chip BOM	bundled	bundled	bundled	n/a
Best-known attack	LPC/SPI sniffing in minutes	TPM-Fail timing	faulTPM full state	None public at faulTPM depth	host compromise
Algorithm agility	spec-required	spec-required	spec-required	spec-required + Rust firmware updates	spec-required
Best fit	Compliance-driven, high-assurance fleets	Existing Intel platforms	Existing AMD platforms	Default for Windows 11 client	Cloud workloads

flowchart LR subgraph TPMs["Five realizations"] dTPM["Discrete TPM
(LPC/SPI/I2C)"] PTT["Intel PTT
(CSME)"] AMD["AMD fTPM
(PSP)"] Pluton["Microsoft Pluton
(on-die, Rust, WU)"] vTPM["vTPM
(Hyper-V / Azure)"] end subgraph Surface["TCG2 command surface"] TCG["TPM2_* commands"] end dTPM --> TCG PTT --> TCG AMD --> TCG Pluton --> TCG vTPM --> TCG TCG --> BL["BitLocker VMK seal"] TCG --> MB["Measured Boot / DHA"] TCG --> CG["Credential Guard"] TCG --> WH["Windows Hello"] TCG --> VSC["Virtual smart cards"] TCG --> DPAPI["DPAPI-NG"] TCG --> KA["TPM key attestation (ADCS)"]

The deep claim of the Pluton design is not that it is a better cryptoprocessor. It is that the previous decade's lesson -- TEE memory-safety bugs are systemic, certification did not catch them, and OEM UEFI capsule patching is too slow -- argues for moving the firmware signer to Microsoft and the firmware language to Rust. That is a political choice, not just a technical one. The October 2019 Secured-core PCs initiative [@ms-secured-core-blog-2019] was the first public step; Pluton is its descendant.

If you can sniff a dTPM, time-attack an Intel PTT, glitch an AMD fTPM, and trust Microsoft to sign your Pluton firmware -- which threat are you actually defending against?

7. Theoretical limits: what a passive cryptoprocessor cannot do

A famous joke in the trusted-computing community: the TPM cannot make a compromised OS uncompromised. It can only make sure that nothing else helped.

Three impossibility-style results follow from the architecture itself, regardless of which of the five realizations you pick.

7.1 The TPM is a Root of Trust for Storage and Reporting, not Execution

The Core Root of Trust for Measurement -- the immutable code that bootstraps the measurement chain -- lives in firmware, not in the TPM. The TPM cannot detect that the wrong code measured itself; it can only refuse to release sealed material when the PCRs do not match the stored policy. If the CRTM is compromised (or a downstream measurement is forged before extension), the TPM has no way to know.

Stronger guarantees require an active root of trust: a Dynamic Root of Trust for Measurement, where the CPU enters a known good state late in the boot and re-measures from there. Intel TXT, AMD SVM-SKINIT, and Microsoft's System Guard Secure Launch [@ms-learn-system-guard] on Secured-core PCs all implement this. The TPM is a participant in DRTM; on its own, it is not sufficient.

7.2 TPM-only BitLocker has a structural lower bound

The VMK must enter RAM during Trusted Boot before the user authenticates. This is not a bug; it is the threat-model definition of "TPM-only." Therefore any attacker who intercepts the VMK at the moment of release defeats TPM-only BitLocker, regardless of TPM strength. This is what every dTPM bus-sniffing attack actually exploits -- not a weakness of the TPM, but the structural condition that the key must traverse the boot path.

Microsoft's countermeasures documentation [@ms-learn-bitlocker-countermeasures] names the mitigation in plain terms: preboot authentication. Adding TPM+PIN raises the bound to "guess the PIN against intact anti-hammering" -- but only as long as the TPM's anti-hammering counter cannot be exfiltrated. faulTPM violates that condition for AMD fTPM. On a Pluton or hardened dTPM, anti-hammering still holds, and a sufficiently random PIN closes the bound.

The complexity of guessing an $n$-digit PIN against intact anti-hammering [@ms-learn-bitlocker-countermeasures] with a per-failure delay $\Delta t$ is approximately $\frac{1}{2} \cdot 10^n \cdot \Delta t$ in the average case. For $n = 8$ and $\Delta t \geq 1\text{s}$ this is roughly $5 \times 10^7$ seconds, or about 1.6 years. For $n = 4$, it is hours.

CVE-2023-21563 [@cve-2023-21563] -- the BitLocker Security Feature Bypass that the offensive-security community calls "Bitpixie" -- is a useful reminder that breaking BitLocker does not require breaking the TPM. The NVD entry reads simply "BitLocker Security Feature Bypass Vulnerability," and the bypass operates against the boot path that consumes the unsealed VMK, not against the chip that sealed it. (NVD does not use the "Bitpixie" name; it is community-known-as.)

7.3 Once a key is unsealed, it lives in the OS's address space

A runtime-compromised OS reads any key the TPM has unsealed for it. The TPM defends against the offline attacker (disk theft, post-shutdown tamper) and the pre-OS attacker (boot-time integrity violation that fails the unseal). It does not defend against a privileged runtime attacker. This is a general impossibility, not a TPM weakness; no passive cryptoprocessor can decide whether the OS asking to unseal a key is itself trustworthy at the moment it asks.

This is why VBS, Credential Guard, and DRTM exist as separate disciplines: they answer "what protects the unsealed key once it is in RAM?" by isolating the key inside a VTL1 enclave or by re-measuring the OS after launch. The TPM is a participant; it is not the answer.

Key idea: The TPM defends against the offline attacker and the pre-OS attacker. It does not defend against a runtime-compromised OS. This is by design, and is the most a passive cryptoprocessor can do. Stronger guarantees require an active component (DRTM, VBS, hypervisor isolation) -- and none of those are the TPM.

What would an ideal TPM look like? On-die (no bus), in an isolated TEE shared with nothing else, with the host-firmware-update path replaced by an OS-channel update path, with high-assurance certification depth, with an authenticated wire protocol always on, and with native support for post-quantum primitives. No shipping TPM today satisfies all six properties. Pluton plus future PQC firmware updates is the closest existing trajectory; it is on-die, isolated, OS-channel-updated, and Rust-implemented, but it does not yet expose PQC primitives and its certification depth is still evolving.

If the TPM cannot defeat a runtime-compromised OS by design, and the best fTPM can be extracted in three hours, where is the security frontier actually moving?

8. Open problems: PQC, supply chain, and trust centralization

On August 13, 2024, NIST finalized FIPS 203 (ML-KEM) [@nist-fips-203-mlkem], FIPS 204 (ML-DSA) [@nist-fips-204-mldsa], and FIPS 205 (SLH-DSA) [@nist-fips-205-slhdsa] -- the first federal post-quantum cryptography standards. ML-DSA-87's public keys are 2,592 bytes. A typical TPM has 6 to 32 KiB of NV memory total. The math gets uncomfortable quickly.

8.1 Post-quantum migration

The NIST Post-Quantum Cryptography project page [@nist-pqc-project] describes the timeline: "In August 2024, NIST released its principal PQC standards ... Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier." That is the deadline driving every TPM roadmap, and the August 14, 2024 Federal Register notice [@federal-register-2024-fips-pqc] made it formal U.S. policy.

Three concrete obstacles. First, the TCG algorithm registry has not yet normatively added ML-KEM, ML-DSA, or SLH-DSA; a TCG PQC working group exists, but its output is in flight. The Microsoft TPM 2.0 reference code [@ms-tpm-20-ref-releases] tracks TCG: the V1.83 release notes describe it as "the first revision in sync with Trusted Computing Group 1.83," and that revision still does not expose PQC algorithm IDs. The Fraunhofer SIT Post-Quantum Cryptography for TPM [@fraunhofer-pqc-tpm] programme has prototyped PQC primitives inside reference TPM stacks, but those changes are research artefacts, not normative TCG output.

Second, the constrained NV-memory budget on a typical TPM cannot hold many simultaneous PQC keys at the larger parameter sets. Quick arithmetic against ML-DSA-87 (FIPS 204): 2,592-byte public key plus 4,896-byte private key plus protocol overhead pushes a single persistent key blob past 7.5 KiB. A 16-KiB-NV TPM can hold at most two persistent ML-DSA-87 slots before exhausting NV. The larger SLH-DSA-256s signatures (29,792 bytes per FIPS 205 Table 2) [@nist-fips-205-slhdsa] routinely exceed the typical 1-4 KiB response-buffer cap (TPM_PT_MAX_RESPONSE_SIZE in the PC Client Platform TPM Profile [@tcg-pc-client-ptp-spec]); the related TPM_PT_NV_BUFFER_MAX (the maximum NV read/write chunk) is in the same order of magnitude and complicates persistent-storage cases as well. The chip cannot return such a signature in a single command without fragmentation extensions. PQC support on commodity TPMs is not just a software upgrade; it is an NV-budget renegotiation.

Third, hybrid signing schemes (composite RSA + ML-DSA, or ECDSA + ML-DSA) are well-defined for transitional certificates. The IETF LAMPS WG draft on composite ML-DSA signatures [@ietf-lamps-pq-composite-sigs] specifies "combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448" for X.509 PKIX. The TLS hybrid key-exchange draft [@ietf-tls-hybrid-design] does the same for TLS 1.3 handshakes. Neither defines a hybrid TPM2_Sign profile, and no shipping Windows TPM exposes one.

Microsoft's Quantum Safe Security blog (August 2025) [@ms-quantum-safe-2025] describes the broader effort -- "Our PQC effort began in 2014 when we published research on post-quantum algorithms ... We participated in four submissions to the original 2017 NIST PQC call and one submission to the current call" -- but is silent on Pluton-firmware PQC support specifically.

The architectural punchline: Pluton's Windows-Update firmware delivery channel is the only realization that can plausibly add a PQC primitive across the deployed fleet without a hardware refresh. Every other realization will need new silicon to ship native PQC.

8.2 The supply-chain trust of EK certificates

The Microsoft TPM key attestation documentation [@ms-learn-tpm-key-attestation] describes the trust-chain assumption plainly: the requestor proves "to a CA that the RSA key in the certificate request is protected by either 'a' or 'the' TPM that the CA trusts." That trust is anchored on the EK certificate the chip's vendor issued at manufacture. A vendor-CA compromise therefore equals collapse of TPM-bound device identity for an entire OEM cohort.

The 2017 ROCA incident is the canonical event for why this matters. In February 2017, Matúš Nemec, Marek Sýs, Petr Švenda, Dušan Klinec, and Vashek Matyáš at Masaryk University [@crocs-muni-roca] disclosed to Infineon a flaw in its RSA key-generation library that drastically reduced the entropy of generated keys and made factoring tractable. The NVD entry for CVE-2017-15361 [@cve-2017-15361] is precise about scope: "The Infineon RSA library 1.02.013 in Infineon Trusted Platform Module (TPM) firmware ... mishandles RSA key generation, which makes it easier for attackers to defeat various cryptographic protection mechanisms via targeted attacks, aka ROCA. Examples of affected technologies include BitLocker with TPM 1.2, YubiKey 4 (before 4.3.5) PGP key generation, and the Cached User Data encryption feature in Chrome OS." The Wikipedia summary [@wikipedia-roca] reports the team's own estimate that the bug "affected around one-quarter of all current TPM devices globally."

The Estonian e-ID program -- about 750,000 cards issued since 2014 [@arstechnica-2017-roca-estonia], all using the affected Infineon chip -- had to be re-enrolled. Microsoft published advisory ADV170012 [@msrc-adv170012] on the same coordinated disclosure date. There is still no scalable revocation mechanism for individual EK certificates: vendor-level revocation breaks every device whose EKpub was issued by that vendor's CA, and ADCS-template OEM-pinning limits scope but does not solve in-scope CA compromise. Pluton centralizes one part of trust (Microsoft as firmware signer); EK certificate issuance for the silicon is unchanged, and supply-chain integrity remains a per-vendor question.

8.3 Attestation freshness in zero-trust networks

A TPM Quote proves "this device booted clean," not "this device is currently clean." Microsoft Intune's default device-compliance check-in is on the order of hours; Microsoft Entra's Continuous Access Evaluation documentation [@ms-learn-cae] specifies the upper-bound numerics: "By default, access tokens are valid for one hour ... The goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time."

A 15-minute revocation window for critical events is good. But it propagates signed policy decisions, not fresh TPM measurements. A device that was clean at boot, was compromised five minutes ago, and just made a request now will pass CAE if its existing access token is valid. Closing that window requires either much shorter token lifetimes, runtime attestation (TCG DICE, Project Cerberus), or a hypervisor-mediated re-measurement -- and none of them are the TPM.

DPAPI-NG, the CNG-layer successor to classic DPAPI that Windows uses to encrypt secrets to a set of authorization principals, is a useful test case. The DPAPI-NG documentation [@ms-learn-cng-dpapi] describes the API as "secure[ly] shar[ing] secrets (keys, passwords, key material) and messages by protecting them to a set of principals." The protection-descriptor grammar [@ms-learn-protection-descriptors] permits five descriptor keywords -- SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE -- across three logical authorization classes (AD-forest groups, web credentials, certificate-store entries). Notably absent: any literal TPM=true clause. DPAPI-NG can be backed by a TPM-bound CNG key, but the authorization is expressed in principal terms, not in TPM terms. The TPM is a key-residence property, not a policy primitive at this layer -- the right architectural choice, but it means TPM-bound DPAPI-NG inherits the freshness limits of whatever principal authorization decides who is currently authorized.

8.4 The Pluton political question

Centralizing firmware on a single Microsoft signing key is a deliberate trade-off, not an oversight. The benefit is the patch path: a Pluton firmware vulnerability becomes a Windows Update release rather than a multi-quarter OEM capsule rollout. The cost is that the chip's trust anchor is now a Microsoft signing key, in a way that even the most conservative dTPM is not. The market response in 2022 was openly mixed.

In March 2022, The Register obtained vendor statements [@register-2022-pluton] from Dell, Lenovo, and HP. Dell's reply was unusually direct: "Pluton does not align with Dell's approach to hardware security and our most secure commercial PC requirements." Lenovo deployed the chip but disabled it: "[ThinkPads] will not support Microsoft Pluton at launch ... But ThinkPads introduced in January with AMD Ryzen 6000 processors will include Pluton as it's present in those AMD chips, though the feature will be disabled by default. AMD has provided an option for users to turn the feature on and off." PCWorld followed up [@pcworld-2022-pluton] with Lenovo's articulated reasoning: "Pluton is disabled by default on 2022 Lenovo ThinkPad laptops using AMD Ryzen PRO 6000 Series processors because that's what Lenovo customers have asked for, the choice to enable or not."

Matthew Garrett -- who later contributed the upstream Linux kernel support for the Pluton TPM CRB interface in Linux 6.3 (merged February 2023, released April 2023) [@phoronix-2023-pluton-linux63] -- published the closest thing to a public engineering analysis of Pluton's controllability. His April 2022 reverse-engineering write-up [@garrett-2022-pluton-rev] of the ASUS ROG Zephyrus G14 BIOS documents two firmware-level disable mechanisms on AMD Ryzen 6000 platforms: an x86-firmware "do not communicate" toggle, and a PSP directory entry 0xB BIT36 soft-fuse that "will NOT put HSP hardware in disable state, to disable HSP hardware, you need setup PSP directory entry 0xB, BIT36 to 1." Garrett's caveat is honest: "My interpretation of this is that it doesn't directly influence Pluton, but disables all mechanisms that would allow the OS to communicate with it." It is not a multi-signer proposal. There is no public peer-reviewed proposal for multi-signer or open-source Pluton firmware.

The unresolved engineering question: whether a multi-signer model is feasible without losing the timely-update property that motivated Pluton in the first place. The answer is genuinely unknown. The political question -- whether one signing key on the world's PC fleet is the right cost for the Windows-Update patch latency it enables -- is no longer a technical argument. It is a procurement-policy and procurement-jurisdiction argument, and high-assurance fleets are deciding both ways.

The TPM was supposed to be the part of the system you didn't have to trust anyone for. Twenty-five years later, the trust question is back -- and the answer is now political.

9. A Windows practitioner's TPM reference

What does this mean for the engineer running Get-Tpm on Monday morning? Three concrete things: discovery, choosing a form factor, and avoiding the pitfalls.

9.1 Discovery

Three commands establish ground truth on any Windows 11 device. Get-Tpm returns presence, ownership, and command-availability state. Get-TpmEndorsementKeyInfo returns the EK public and certificate. tpm.msc opens the Microsoft Management Console snap-in. The TCG event log lives at C:\Windows\Logs\MeasuredBoot\*.log and contains the per-PCR measurement history for every boot. Microsoft's BitLocker page [@ms-learn-bitlocker] documents the protector model that pairs with the TPM state.

{` // Demonstrates the logic of: // Get-Tpm // (Get-BitLockerVolume -MountPoint 'C:').KeyProtector // // Mirrors the PowerShell decision tree without requiring a real TPM.

const tpm = { TpmPresent: true, TpmReady: true, ManufacturerVersion: '7.2.0.1', PhysicalPresenceVersionInfo: '1.3', };

// Sample KeyProtector list as PowerShell would return it. const protectors = [ { KeyProtectorType: 'Tpm' }, { KeyProtectorType: 'RecoveryPassword' }, // Uncomment to model TPM+PIN: // { KeyProtectorType: 'TpmPin' }, ];

function classify(tpm, protectors) { if (!tpm.TpmPresent) return 'no-tpm'; if (!tpm.TpmReady) return 'tpm-not-ready';

const types = protectors.map(p => p.KeyProtectorType); const hasPin = types.includes('TpmPin') || types.includes('TpmPinStartupKey'); const hasStartupKey = types.includes('TpmStartupKey'); const hasRecovery = types.includes('RecoveryPassword');

if (hasPin) return 'tpm-plus-pin'; if (hasStartupKey) return 'tpm-plus-startup-key'; if (types.includes('Tpm')) return 'tpm-only'; return 'no-tpm-protector'; }

const verdict = classify(tpm, protectors); console.log('TPM present:', tpm.TpmPresent); console.log('TPM ready :', tpm.TpmReady); console.log('Configuration:', verdict); if (verdict === 'tpm-only') { console.log('WARN: TPM-only is vulnerable to bus-sniffing on dTPM.'); console.log('Mitigation: enable TPM+PIN with PIN length >= 8.'); } console.log('Recovery key escrowed:', protectors.some(p => p.KeyProtectorType === 'RecoveryPassword')); `}

9.2 Choosing a TPM form when the OEM gives you a choice

A short decision tree, distilled from the SOTA analysis above:

Opportunistic theft, low-skill attacker. Default TPM-only is acceptable but not ideal. TPM+PIN with at least 8 random digits closes the bus-sniffing window on dTPM and the low-PIN-entropy window on AMD fTPM.
Determined targeted adversary. TPM+PIN is necessary but not sufficient. Add a startup-key factor or Network Unlock where appropriate (BitLocker's native OS-volume preboot authentication is TPM, TPM+PIN, and startup key, not FIDO2 or smart card), and prefer Pluton or hardened dTPM over commodity AMD fTPM for the device class.
Compliance-driven. Discrete TPM with EAL4+ / FIPS 140-2 certification is still the easiest procurement story. Verify the OEM has not enabled Pluton-as-TPM if the auditor's checklist requires a discrete chip.
Cloud workload. Azure Trusted Launch with vTPM [@ms-learn-azure-trusted-launch] is the default for Gen2 VMs and underwrites Confidential VM offerings.
Surface Copilot+, AMD Ryzen 6000+, Intel Core Ultra 200V, Snapdragon X. Pluton-as-TPM [@ms-learn-pluton] is the OEM default in many SKUs; verify the Pluton firmware is current via Windows Update.

9.3 Five common pitfalls

Note: Clearing the TPM invalidates every TPM-bound protector, so the next boot falls back to the BitLocker recovery key. Always verify recovery key escrow first -- in Microsoft Entra ID for Azure-AD-joined devices, in Active Directory for AD-joined devices, or in a printed/saved location for personal devices. If the recovery key is unescrowed and the TPM is cleared, the volume is unrecoverable.

The other four pitfalls in brief: firmware updates change PCR[0] and PCR[7], so suspend BitLocker before applying them; dual-boot Linux extends PCRs differently than Windows, so PCR-only sealing breaks under it -- escape with TPM+PIN; Windows does not enable parameter encryption on the BitLocker boot path, so the actual mitigation against dTPM bus sniffing is preboot authentication, not "TPM hardening"; and Windows Hello silently falls back to no-TPM credential storage if the TPM is unhealthy, so periodically check Get-Tpm on enrolled devices."Anti-hammering" is the persistent rate-limit counter the TPM enforces against authValue and policy-PIN failures. It survives reboots and only resets after a long lockout period.

Note: The Group Policy setting "Require additional authentication at startup" with a minimum PIN length of 8 buys you the most security against published attacks for the least operational cost. It defeats Andzakovic-style bus sniffing (the VMK is no longer the only secret on the bus) and forces an attacker on AMD fTPM to either compromise the TPM state out-of-band or guess the PIN against anti-hammering. The exception is a fully-extracted AMD fTPM where faulTPM has already obtained the unsealed material -- in that case the PIN is bypassed.

From an elevated PowerShell prompt:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

The RebootCount 1 argument auto-resumes after the next reboot, which is what you want when the firmware update reboots the device. After the update completes, run Get-BitLockerVolume -MountPoint C: and confirm ProtectionStatus is On again. If you forget, the next boot will land on the BitLocker recovery prompt because PCR[0] no longer matches the sealed policy.

The TPM does exactly what it was designed to do, no more. Which is exactly enough -- if you understand what "exactly" means.

10. FAQ and closing

A handful of questions get asked again and again about the TPM. The answers do not always match the marketing.

No. TPM keys are non-exportable and held inside the chip; the Microsoft documentation [@ms-learn-how-windows-uses-tpm] is explicit that "if a key stored in a TPM has properties that disallow exporting the key, that key truly can't leave the TPM." The Endorsement Key is a privacy concern (it uniquely identifies the chip) but it is not a Microsoft backdoor. Pluton centralizes firmware *signing*, not key access -- Microsoft signs the firmware that runs on Pluton, but the keys Pluton creates and seals stay inside Pluton. Depends on threat model. Against software attackers, fTPM is sufficient -- the no-bus property defeats the cheap LPC/SPI sniffing class. Against well-funded physical attackers, fTPM is weaker than dTPM: TPM-Fail [@tpmfail-microsite] showed timing-side-channel ECDSA key recovery on Intel PTT, and faulTPM [@jacob-2023-faultpm] showed 2-3 hour state extraction on AMD PSP. Pluton sits between the two with a smaller TEE surface but less public scrutiny. Yes -- Microsoft mandates it. The OEM mandate has been in force since July 28, 2016 [@ms-learn-oem-tpm]; the consumer mandate became visible on June 24, 2021 with the Windows 11 announcement. The defensive primitives the TPM underwrites -- BitLocker, Credential Guard, Windows Hello, Device Health Attestation [@ms-learn-azure-measured-boot] -- are real, measurable, and not realistically replaceable by software-only equivalents. Practically no for dTPM and Pluton; the EK private key never leaves the chip, and replicating it would require silicon-level extraction that no public attack has achieved. faulTPM [@jacob-2023-faultpm] proved that AMD fTPM internal state can be *extracted* in 2-3 hours of physical access; that is closer to "extracted" than "cloned" but the practical effect is the same for keys the chip held. Because ransomware operates after the OS has loaded -- by definition outside the TPM's threat model. The TPM secures keys at rest and attests boot integrity. It does not run anti-malware, sign user files, or detect runtime compromise. Microsoft's BitLocker countermeasures page [@ms-learn-bitlocker-countermeasures] is explicit that BitLocker is a data-protection feature, not an anti-malware feature; the same logic applies to the TPM that underwrites it. Pluton implements TPM 2.0 plus Microsoft-specific extensions. From Windows's perspective it *is* a TPM with a different update story (Windows Update instead of UEFI capsule) and a different trust anchor (Microsoft as firmware signer). Whether the OEM exposes Pluton "as the TPM" or alongside a discrete TPM is an OEM choice [@ms-learn-pluton-as-tpm].

Return to June 24, 2021. The PR backlash about a Trusted Platform Module made the chip visible for the first time to a consumer audience that had owned one for a decade. The technical rationale Microsoft gave was four words long; the actual rationale is the rest of this article.

A passive cryptoprocessor designed in 1999 quietly became the load-bearing pillar of half of Windows security. Twenty-five years of engineering refined a single primitive -- measure, extend, seal, quote -- into something one chip could underwrite. Twenty-five years of attacks, from a $40 FPGA on an LPC bus to a voltage glitch against the AMD PSP, argued empirically about how passive that chip can be allowed to be. The current state of the art is on the CPU die, in Rust, signed by Microsoft, patched through Windows Update -- and post-quantum migration is the next argument.

The TPM is not a checkbox. It is the point at which Windows decided integrity must be measurable. It is not a panacea -- the runtime-compromised OS still wins once the key is unsealed -- but it is a primitive, with a clean boundary. Now you know what it can prove, and what it cannot. The chip is the cheapest part of the system. The cost was twenty-five years of getting it right.

BitLocker on Windows: Architecture, Attacks, and the Limits of Full-Disk Encryption

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

**Windows 11 now encrypts your drive with BitLocker by default -- no action required.** The encryption itself (XTS-AES) is solid, but the default TPM-only configuration is vulnerable to physical attacks costing as little as \$5 in hardware. For real security, add a pre-boot PIN, verify software encryption is enforced, and know where your recovery key is stored. This article traces BitLocker's 20-year evolution from an optional enterprise feature to encryption-by-default, explains its cryptographic architecture, catalogs every known attack, and compares it to VeraCrypt, LUKS, and FileVault.

Your Laptop Is Already Encrypted

Your Windows laptop is almost certainly encrypting every sector of its drive right now -- and you probably never turned that on. Since late 2024, every clean install of Windows 11 activates BitLocker by default, silently encrypting the entire volume and uploading a recovery key to Microsoft's cloud [@computerworld-24h2]. This is the culmination of a 20-year engineering effort that began with a stolen laptop containing 26.5 million veterans' medical records.

In May 2006, an employee of the U.S. Department of Veterans Affairs took home a laptop and an external hard drive containing the personal data of 26.5 million veterans and active-duty military personnel. Both were stolen from his home. The data was not encrypted. The breach later resulted in a $20 million class-action settlement and became the defining example of why laptops need full-disk encryption [@ms-bitlocker].

That event accelerated a shift already underway inside Microsoft: from "encryption is something you turn on" to "encryption is something that's always there." Today, the 24H2 update means every new Windows 11 installation has BitLocker active with no user action [@computerworld-24h2]. On Windows Home editions, this takes the form of Device Encryption -- a streamlined subset of BitLocker without Group Policy control or configurable pre-boot PIN.

But here is the tension at the heart of this story. BitLocker encrypts everything by default, yet security researchers keep finding ways past it -- with a $5 chip, a network cable, or a can of compressed air. If your drive is encrypted, why should you care?

The answer lies in how the keys are managed. And that story starts 25 years ago.

Before BitLocker: File-Level Encryption and Its Fatal Flaw

Before BitLocker, Windows had encryption. The Encrypting File System (EFS) shipped with Windows 2000 in 1999, and it encrypted individual files beautifully [@ms-efs]. So why wasn't that enough?

A file-level encryption feature built into NTFS since Windows 2000. EFS encrypts individual files using a randomly generated File Encryption Key (FEK), which is then wrapped with the user's RSA public key certificate. Decryption is transparent while the user is logged in.

EFS worked at the NTFS layer. Each file got its own symmetric key (DESX by default in Windows 2000; AES became the default EFS cipher in Windows XP SP1 and Windows Server 2003), wrapped with the user's public key and stored in a special NTFS attribute. When you were logged in, decryption happened transparently [@ms-efs].

The problem was where it didn't go. EFS encrypts files and folders -- not volumes. The operating system itself, the page file, the hibernation file, the temp directory -- all of that remained in plaintext. An attacker who booted from a USB stick could read the Windows directory, extract cached credentials from the SAM and SECURITY registry hives, and access fragments of "encrypted" files that the OS had swapped to disk [@ms-bitlocker].

The failure mode was concrete: steal a laptop, mount the drive on another machine, and everything the OS touched is readable. EFS protected the documents you remembered to encrypt. It did nothing for the thousands of files the OS created on your behalf. Microsoft also explored a far more ambitious approach. The "Next-Generation Secure Computing Base" (NGSCB), originally codenamed Palladium, proposed a hardware-rooted secure computing environment -- a tamper-resistant "nexus" running alongside Windows. Announced in 2002 under Peter Biddle's leadership, the full vision was scaled back around 2004-2005 under a wave of industry resistance and public backlash over DRM fears. But its core idea -- a Trusted Platform Module providing hardware-rooted key storage -- survived and became BitLocker's anchor [@ngscb-wiki].

A dedicated hardware chip (or firmware module) that provides cryptographic key storage, platform integrity measurement, and sealed storage. The TPM can "seal" a secret to specific Platform Configuration Register (PCR) values, releasing it only when the boot chain matches the expected measurements. Standardized by the Trusted Computing Group (TCG), first as TPM 1.2 and later TPM 2.0.

Microsoft needed something that encrypted everything on the disk -- the OS, the swap file, the hibernation file, the temp files, all of it. But who would design the cipher, and how would the keys be protected without making the user type a 48-character password at every boot?

The Architecture: How BitLocker Actually Works

In 2006, a Dutch cryptographer named Niels Ferguson published a paper describing a new disk encryption scheme [@ferguson-2006]. Two decades later, the core architecture he designed is still running on hundreds of millions of machines -- structurally unchanged.

The Three-Layer Key Hierarchy

BitLocker's design centers on a three-layer key hierarchy that solves an otherwise painful problem: how do you let a user change their password without re-encrypting an entire 2 TB drive?

The symmetric key that directly encrypts and decrypts disk sectors. In XTS-AES-256 mode, this is effectively two 256-bit AES keys -- one for block encryption, one for the XTS "tweak" computation that ensures identical plaintext at different sector locations produces different ciphertext. A key-encrypting key that wraps the FVEK. The VMK itself is encrypted by one or more key protectors. This indirection allows changing authentication methods (adding a PIN, rotating a recovery key) without re-encrypting the entire volume -- only the VMK wrapping changes. An authentication mechanism that independently encrypts the VMK. Common protectors include TPM-only (VMK sealed to Platform Configuration Registers), TPM+PIN (adds a user-supplied PIN), and Recovery Password (a 48-digit numerical backup code). Multiple protectors can coexist on the same volume.

The indirection is the key insight. Your data is encrypted with the FVEK. The FVEK is wrapped by the VMK. The VMK is wrapped by one or more key protectors -- your TPM, your PIN, your recovery password. When you change your PIN, only the VMK wrapper changes. The FVEK stays the same. The entire volume never needs re-encryption [@ms-bitlocker].

TPM Sealing: The Hardware Root of Trust

At boot time, the TPM measures each component of the boot chain -- firmware, bootloader, boot configuration -- and records hashes in its Platform Configuration Registers (PCRs). During BitLocker setup, the TPM seals the VMK to the current PCR values. On every subsequent boot, the TPM re-measures the chain. If the measurements match, the TPM releases the VMK. If anything has changed -- a modified bootloader, a BIOS update, a different boot device -- the TPM refuses, and the user must provide a recovery key [@ms-bitlocker].

A register inside the TPM that stores a hash representing the state of a specific component of the boot chain (firmware, bootloader, OS kernel, etc.). PCR values are "extended" at each boot step -- the new measurement is hashed together with the previous value, creating a tamper-evident chain. BitLocker seals the VMK to specific PCR values so that any modification to the boot process blocks key release. sequenceDiagram participant UEFI as UEFI Firmware participant TPM as TPM Chip participant BL as Windows Boot Manager participant OS as Windows OS UEFI->>TPM: Extend PCR 0-7 (firmware measurements) BL->>TPM: Extend PCR 8-11 (bootloader measurements) BL->>TPM: Request VMK unseal alt PCR values match sealed state TPM->>BL: Release VMK (cleartext) BL->>OS: Decrypt FVEK, mount volume else PCR mismatch (tampered boot chain) TPM->>BL: Refuse unseal BL->>OS: Prompt for recovery key end

Ferguson's Elephant diffuser served BitLocker well from Vista through Windows 7, but it was a custom, non-standard construction. Government compliance frameworks (FIPS 140-2) and the emerging IEEE 1619 standard required a published, peer-reviewed cipher mode [@nist-800-38e]. Ferguson's original 2006 design used AES-128 in CBC mode with a custom "Elephant" diffuser -- a two-pass diffusion algorithm (one pass forward, one pass backward) applied to each 512-byte sector. The Elephant diffuser ensured that flipping one bit of ciphertext would scramble the entire sector of plaintext, raising the bar for sector manipulation attacks. The name was reportedly a nod to the animal's famously long memory -- a reference to diffusion spreading changes across the entire sector.

The removal of the Elephant diffuser in Windows 8 was controversial. Microsoft cited FIPS 140-2 certification requirements and alignment with standardized disk-encryption modes as the primary motivations. Windows 8 kept AES-CBC but removed the proprietary whole-sector diffuser; Windows 10 version 1511 later moved new volumes to XTS-AES. Critics pointed out that both post-Elephant designs lost the diffuser's whole-sector avalanche behavior. Microsoft chose standards compliance over a proprietary advantage -- a pragmatic decision that made BitLocker deployable in regulated environments worldwide [@ms-bitlocker].

Windows 10 version 1511 (November 2015) completed the transition by making XTS-AES-128 the default for new volumes, with XTS-AES-256 available via Group Policy [@ms-bitlocker]. XTS stands for XEX-based Tweaked-codebook mode with ciphertext Stealing, built on Rogaway's XEX (XOR-Encrypt-XOR) construction [@rogaway-2004]. The core XEX pattern works like this: each sector gets a unique "tweak" derived from its sector number, and each 16-byte block within that sector is XORed with the tweak, AES-encrypted, then XORed with the tweak again. XTS extends XEX by adding ciphertext stealing to handle sectors that are not an exact multiple of 16 bytes. The result: identical plaintext at different disk locations produces different ciphertext, and there is no IV management problem like CBC had [@nist-800-38e].

flowchart LR SN["Sector Number"] --> TW["Tweak Generation
(AES encrypt sector #
with tweak key)"] TW --> X1a["XOR with
Tweak"] TW --> X2a["XOR with
Tweak"] TW --> XNa["XOR with
Tweak"] P1["Plaintext
Block 1"] --> X1a --> AES1["AES Encrypt"] --> X1b["XOR with
Tweak"] --> C1["Ciphertext
Block 1"] P2["Plaintext
Block 2"] --> X2a --> AES2["AES Encrypt"] --> X2b["XOR with
Tweak"] --> C2["Ciphertext
Block 2"] PN["Plaintext
Block N"] --> XNa --> AESN["AES Encrypt"] --> XNb["XOR with
Tweak"] --> CN["Ciphertext
Block N"]

This architecture is elegant. The TPM releases the key automatically at boot if nothing has changed. The key hierarchy means operational changes (new PIN, new recovery key) never touch the encrypted data. The cipher mode is standardized, hardware-accelerated via AES-NI on virtually all modern CPUs [@intel-aesni], and FIPS-validated.

But what happens if an attacker gets to the hardware? Princeton researchers were about to find out.

The Cold Wake-Up Call: Attacks That Changed Everything

In 2008, a team at Princeton did something unsettling. They sprayed a laptop's RAM with compressed air, yanked the power cord, and recovered the BitLocker encryption key from the memory that should have been erased. It wasn't [@halderman-2008].

A physical attack exploiting the fact that DRAM retains its contents for seconds to minutes after power loss (a property called "data remanence"). By cooling RAM to extend retention time and quickly rebooting into an attacker-controlled OS, encryption keys can be extracted from residual memory contents. First demonstrated against BitLocker, FileVault, and dm-crypt by Halderman et al. at Princeton in 2008.

J. Alex Halderman and his team demonstrated that DRAM does not instantly lose its contents when power is removed. At room temperature, data decays over seconds. Cooled with compressed air (around -50C), retention extends to minutes. That is enough time to reboot into a USB-based attack environment, scan memory for AES key schedules, and extract the FVEK [@halderman-2008].

DRAM retains its contents for seconds to minutes after power loss... enough time to extract full encryption keys. -- Halderman et al., 2008, adapted from the paper's findings.

The cold boot attack revealed a fundamental truth about every full-disk encryption system: the keys must live in RAM while the OS is running. There is no way around this. Encrypt the keys in memory and you need a key to decrypt those keys -- turtles all the way down. The cold boot paper did not just break BitLocker; it defined the boundary of what FDE can and cannot do.

The $5 Chip That Reads Your Encryption Key

In 2019, Denis Andzakovic at Pulse Security demonstrated something even more unsettling: in BitLocker's default TPM-only configuration, the VMK travels in cleartext on the communication bus (SPI or LPC, depending on hardware) between the discrete TPM chip and the CPU [@andzakovic-2019]. A $40 NZD FPGA, clipped to the right pins, captured the VMK during boot. The drive was decrypted offline in under five minutes.

sequenceDiagram participant CPU as CPU participant SPI as SPI / LPC Bus participant TPM as Discrete TPM participant ATK as Attacker (logic analyzer) Note over CPU,TPM: Normal boot sequence CPU->>SPI: Request VMK unseal SPI->>TPM: Forward request TPM->>SPI: Return VMK (cleartext!) ATK->>SPI: Sniff VMK from bus traffic SPI->>CPU: Deliver VMK Note over ATK: Attacker now has VMK -- Drive can be decrypted offline

The SCRT security team independently reproduced this attack in 2021 [@scrt-tpm-2021], and by 2024, the community had replaced the FPGA with a $5 Raspberry Pi Pico [@tpm-sniffing-repo]. Compass Security documented successful attacks on Lenovo ThinkPad, HP EliteBook, and Microsoft Surface models -- the most common enterprise laptops [@compass-bypasses]. The $40 FPGA that Andzakovic used in 2019 has since been replaced by a $5 Raspberry Pi Pico in community tooling. The TPM-Sniffing repository on GitHub maintains a list of tested laptop models and TPM chips, with specific pinout diagrams for each.

Even adding a TPM+PIN does not fully close this gap. In October 2024, SCRT Security demonstrated that if an attacker knows (or coerces) the PIN, the VMK can still be extracted via SPI bus sniffing [@scrt-tpm-pin-2024]. The real mitigation is a firmware TPM (fTPM, integrated into the CPU) -- when the TPM is on the same die as the processor, there is no external bus to sniff.

The SSD Betrayal

In 2019, Carlo Meijer and Bernard van Gastel at Radboud University published findings that shocked the storage industry. Multiple popular SSDs from Samsung and Critical had critically flawed hardware encryption. In some cases, the data encryption key was stored in plaintext on the drive. In others, the user's password was never actually used for key derivation [@meijer-2019].

Multiple popular SSDs had critically flawed hardware encryption -- in some cases, the data encryption key was stored in plaintext or could be recovered by manipulating firmware. -- Meijer and van Gastel, 2019, summarizing their IEEE S&P findings. This was not a theoretical weakness. BitLocker's "eDrive" mode trusted SSD firmware to perform encryption. On a Samsung 850 EVO or Critical MX300 with eDrive enabled, BitLocker reported the drive as "encrypted" -- but an attacker with physical access could use JTAG debugging or firmware manipulation to read all data in plaintext. The data was never actually encrypted by the hardware [@meijer-2019]. Microsoft issued Security Advisory ADV180028 in November 2018, recommending administrators enforce software encryption, and later changed the default so BitLocker no longer trusts hardware encryption [@adv180028].

DMA and Bitpixie: The Attacks Keep Coming

Ulf Frisk's PCILeech tool (2016) turned DMA attacks into a scriptable operation. Any system with unprotected Thunderbolt, ExpressCard, or PCIe slots was vulnerable to direct memory reads while powered on or in sleep mode [@pcileech]. Björn Ruytenberg's Thunderspy research (2020) found seven vulnerabilities in Intel's Thunderbolt protocol that enabled evil-maid DMA attacks bypassing disk encryption and screen locks. Microsoft introduced Kernel DMA Protection in Windows 10 version 1803, using IOMMU to block unauthorized DMA from external Thunderbolt and PCIe devices -- closing this vector on supported hardware [@ms-kernel-dma].

And in 2023, the "bitpixie" vulnerability (CVE-2023-21563) introduced a purely software-based bypass. An attacker with physical access triggers a PXE network boot, which performs a soft reboot -- leaving the VMK in RAM. The attacker boots into a Linux environment (or, in newer variants using the WinPE approach, a custom Windows PE image that avoids Secure Boot restrictions on third-party Linux loaders), scans memory, and extracts the VMK. The entire attack takes about five minutes and requires no hardware modifications [@cve-2023-21563].

Each attack reinforced the same lesson: full-disk encryption only protects data at rest. The default TPM-only configuration was never designed to resist a determined attacker with physical access. So how did Microsoft respond?

The Evolution: Generation by Generation

What makes BitLocker's history unusual is that each generation was a direct response to a specific failure. The evolution was not planned from the start -- it was forced by attackers.

flowchart TD G0["Gen 0: EFS (2000)
File-level encryption"] -->|"OS/swap/temp left exposed"| G1["Gen 1: Vista BitLocker (2006)
AES-CBC + Elephant diffuser"] G1 -->|"OS drive only; non-standard cipher"| G2["Gen 2: Win 7 (2009)
+ BitLocker To Go"] G2 -->|"Elephant blocks FIPS/IEEE compliance"| G3["Gen 3: Win 8/8.1 (2012-2013)
No Elephant + eDrive + Device Encryption"] G3 -->|"SSD hardware encryption broken (2018)"| G4["Gen 4: Win 10 (2015-2021)
Software-first + cloud management"] G4 -->|"Still not default for consumers"| G5["Gen 5: Win 11 24H2 (2024)
Encryption by default"]

Generation 0 -- EFS (2000): File-level encryption on NTFS. Left the OS, swap, and temp files exposed. Superseded because volume-level encryption was needed [@ms-efs].

Generation 1 -- Vista (2006): Ferguson's AES-CBC + Elephant diffuser. First volume-level encryption in Windows. OS drive only. The cold boot attack (2008) revealed that FDE keys in RAM are vulnerable [@ferguson-2006, @halderman-2008].

Generation 2 -- Windows 7 (2009): Added BitLocker To Go for USB drives and data volumes. The 2006 VA breach had involved a stolen external hard drive, making removable media encryption urgent. The Elephant diffuser persisted, blocking compliance certification [@ms-bitlocker].

Generation 3 -- Windows 8/8.1 (2012-2013): Removed the Elephant diffuser while retaining AES-CBC, introduced eDrive hardware offload in Windows 8, and added consumer Device Encryption in Windows 8.1. The SSD betrayal (2018) destroyed the eDrive trust model [@ms-bitlocker, @meijer-2019].

Generation 4 -- Windows 10 (2015): XTS-AES-128 became the default for new volumes in version 1511. Software encryption was enforced after the Radboud findings. Cloud-based key escrow via Azure AD. TPM sniffing attacks (2019) showed the default TPM-only configuration was vulnerable [@adv180028, @andzakovic-2019].

Generation 5 -- Windows 11 24H2 (2024): Encryption by default on clean installs. Relaxed hardware requirements (no Modern Standby/HSTI needed). TPM 2.0 mandatory. Recovery keys escrowed to Microsoft Account or Azure AD. Hardware-accelerated encryption available in 25H2 [@techpowerup-hwaccel].

gantt title BitLocker Evolution and Attack Timeline dateFormat YYYY axisFormat %Y section Generations EFS (file-level) :g0, 2000, 2006 Vista: AES-CBC+Elephant :g1, 2006, 2009 Win 7: +BitLocker To Go :g2, 2009, 2012 Win 8/8.1: no Elephant+eDrive :g3, 2012, 2015 Win 10: Software-first :g4, 2015, 2024 Win 11 24H2: Default :g5, 2024, 2026 section Attacks Cold boot (Princeton) :milestone, 2008, 0d DMA/PCILeech :milestone, 2016, 0d SSD bypass (Radboud) :milestone, 2018, 0d TPM sniffing :milestone, 2019, 0d Thunderspy :milestone, 2020, 0d Bitpixie (CVE-2023-21563) :milestone, 2023, 0d

By 2024, BitLocker had evolved from an enterprise opt-in feature to encryption that activates without asking. But how does it compare to what Linux and macOS users have?

BitLocker vs. the Competition

BitLocker is not the only option. Every major OS now ships with full-disk encryption, and the open-source world offers capabilities that BitLocker cannot match.

Dimension	BitLocker (Win 11)	VeraCrypt	LUKS2 (dm-crypt)	FileVault 2	SEDs (TCG Opal)
Platform	Windows	Windows, macOS, Linux	Linux	macOS	Any (firmware)
Cipher	XTS-AES-128/256	XTS-AES, Serpent, Twofish, cascades	XTS-AES (default)	XTS-AES-256 (APFS)	AES-256 (vendor)
Key derivation	TPM sealing + optional PIN	PBKDF2 + PIM	Argon2id (memory-hard)	Secure Enclave	Firmware-specific
Open source	No	Yes	Yes	No	No
Audited	FIPS 140-2 certified	Quarkslab 2016; Fraunhofer/BSI 2020	Community-audited	Apple docs published	Radboud found flaws
Enterprise mgmt	Intune, GPO, SCCM	None	Scriptable	MDM (Jamf)	Vendor-specific
Plausible deniability	No	Yes (hidden volumes)	No	No	No
Performance	Minimal (sequential); up to 50% random IOPS loss	Similar	Similar	Near-zero (hardware)	Near-zero (hardware)

VeraCrypt (2013) is the open-source TrueCrypt fork, maintained by Mounir Idrassi [@veracrypt-docs]. It offers cascaded ciphers (AES-Twofish-Serpent), hidden volumes for plausible deniability, and cross-platform support. Its hidden volume feature is particularly notable: a single encrypted container holds two volumes with different passwords, and the outer volume's free space is cryptographically indistinguishable from the hidden volume's ciphertext. An adversary who compels you to reveal a password gets the decoy; the hidden volume remains undetectable. VeraCrypt was audited by Quarkslab in 2016, which found 8 critical and 3 medium-severity vulnerabilities; v1.19 fixed many high-priority issues, while OSTIF noted that some complex findings were handled with documented workarounds rather than complete fixes. It was audited by Fraunhofer SIT, commissioned by the German BSI, in 2020 [@ostif-veracrypt]. What it lacks is enterprise management -- no centralized key escrow, no MDM integration, no Group Policy. For individual privacy, it is unmatched. For a fleet of 10,000 laptops, it is impractical. VeraCrypt's hidden volumes provide plausible deniability -- you can be compelled to reveal a password, and it unlocks a decoy volume while the real data remains hidden in space that is statistically indistinguishable from random data. No other mainstream FDE tool offers this capability.

LUKS2 with dm-crypt is Linux-native full-disk encryption, maintained as part of the cryptsetup project [@cryptsetup-faq]. Its standout feature is the Argon2id key derivation function -- a memory-hard, GPU/ASIC-resistant password hash that provides superior brute-force resistance compared to BitLocker's TPM-based approach or VeraCrypt's PBKDF2 [@argon2-spec]. Why does memory-hardness matter? GPUs and ASICs can test billions of PBKDF2 hashes per second because each attempt needs little memory. Argon2id forces each attempt to allocate a configurable amount of RAM; LUKS2 calibrates the parameters to a target unlock time on the host system rather than using a fixed 1 GB default. That makes parallel brute-force attacks on GPUs prohibitively expensive. LUKS2 supports up to 32 keyslots, allowing multiple users or recovery methods per volume [@cryptsetup-faq]. It integrates with systemd-cryptenroll for TPM2 and FIDO2 token support. But it is Linux-only, and setup requires comfort with the command line.

A memory-hard key derivation function (KDF) that won the Password Hashing Competition in 2015. Argon2id combines the data-dependent memory access pattern of Argon2d with the data-independent access pattern of Argon2i, providing resistance to both GPU-based brute-force attacks and side-channel attacks. Used by LUKS2 as its default KDF, replacing the older PBKDF2.

FileVault 2 is macOS-native full-disk encryption, deeply integrated with Apple's hardware. On APFS volumes (macOS High Sierra and later), FileVault uses XTS-AES-256. On T2-equipped Intel Macs and all Apple Silicon machines, the Secure Enclave -- a dedicated security coprocessor physically isolated from the main CPU -- manages encryption keys in hardware. Unlike a discrete TPM where keys transit an external bus (the vulnerability that enables TPM sniffing), Secure Enclave keys never leave the chip. The SSD controller handles encryption in real-time using dedicated AES hardware. The result is near-zero measurable performance impact. FileVault is what happens when one company controls both the hardware and software.

Self-Encrypting Drives (SEDs) conforming to TCG Opal perform encryption in the drive's firmware with zero CPU overhead. But after the Radboud findings, trusting opaque SSD firmware for security is a gamble. The Meijer and van Gastel research affected drives from Samsung and Critical that, according to the researchers, represented roughly 60% of the consumer SSD market at the time [@meijer-2019].

Each approach makes different trade-offs between transparency, performance, enterprise management, and trust. But they all share one theoretical limitation.

The Limits: What No Full-Disk Encryption Can Do

Here is the uncomfortable truth that no vendor will put on the box: full-disk encryption cannot protect your data while your computer is running. That is not a bug. It is a fundamental impossibility.

Any full-disk encryption system must hold decryption keys in volatile memory while the OS is running. Full protection is available only when the device is powered off.

Any FDE system -- BitLocker, VeraCrypt, LUKS, FileVault -- must load the decryption key into RAM to service I/O requests. While the key is in RAM, it is vulnerable to cold boot attacks, DMA attacks, and any malware running with kernel privileges. This is not a design flaw. It is an impossibility result. You cannot encrypt and decrypt data simultaneously without holding a key somewhere accessible [@halderman-2008].

The XTS Semantic Security Gap

XTS mode has a narrower theoretical limitation. It uses a sector-derived tweak, so identical plaintext at the same block offset in different sectors does not produce identical ciphertext. The limitation is narrower diffusion: each 16-byte block is protected independently within the sector, so a targeted ciphertext modification corrupts the corresponding 16-byte plaintext block rather than avalanching across the entire sector. Phillip Rogaway's tweakable-block-cipher work explains why narrow-block disk modes have this shape [@rogaway-2004].

Wide-block modes like EME and CMC, proposed by Shai Halevi and Rogaway, encrypt an entire sector as a single block -- changing one bit of plaintext changes every bit of ciphertext across the sector [@halevi-rogaway-eme]. These modes provide stronger semantic security but at higher computational cost, and no major FDE system has adopted them.

NIST SP 800-111 recommends pre-boot authentication for full-disk encryption in government systems [@nist-sp800-111]. Organizations subject to NIST guidelines may find TPM-only mode insufficient for compliance -- both because of the bus sniffing vulnerability and because of the XTS narrow-block limitation. The practical recommendation is TPM+PIN with XTS-AES-256, which satisfies most regulatory frameworks even if it does not close the theoretical semantic security gap.

The Performance Reality

Software-based BitLocker on fast NVMe SSDs carries a real cost. TechPowerUp measured a 375% increase in CPU cycles per I/O when software BitLocker is active, with random 4K IOPS dropping by up to 50% [@techpowerup-hwaccel]. Sequential throughput impact is typically under 5% thanks to AES-NI acceleration, but the random I/O penalty matters for database workloads and developer builds.

Microsoft's hardware-accelerated BitLocker, available in Windows 11 25H2, uses CPU crypto instructions and NVMe controller integration to close this gap. Early benchmarks show random 4K IOPS doubling compared to software mode, with CPU usage dropping by over 70% -- approaching unencrypted performance [@techpowerup-hwaccel].

Metric	No BitLocker	Software BitLocker	HW-Accelerated BitLocker (25H2)
Sequential read/write	Baseline	~5% overhead	~0% overhead
Random 4K IOPS	Baseline	Up to 50% loss	~10% loss
CPU cycles per I/O	Baseline	+375%	~+30%

If the fundamental limits are known, what problems remain unsolved?

Open Problems: What Keeps Researchers Awake

BitLocker is mature, battle-tested, and now ubiquitous. Yet at least five significant problems remain open -- and some of them could invalidate the entire trust model.

Post-quantum readiness. AES-256 survives Grover's algorithm with an effective 128-bit security level -- still intractable for foreseeable quantum computers [@nist-800-38e]. But the key management layer is not quantum-safe. TPM 2.0 attestation and Azure AD key escrow use RSA-2048 or ECC P-256, both vulnerable to Shor's algorithm. NIST finalized post-quantum key encapsulation (ML-KEM) and digital signature (ML-DSA) standards in 2024 [@nist-pqc], but no shipping FDE system integrates post-quantum cryptography into its key management chain yet.

SSD firmware auditability. There is no standard mechanism to verify that a self-encrypting drive's firmware actually implements encryption correctly. The Radboud findings proved this is not hypothetical. Microsoft's policy of defaulting to software encryption works around the problem but does not solve it for hardware-only use cases [@meijer-2019].

Secure Boot trust chain revocation. The bitpixie attack persists because older, vulnerable bootloaders remain trusted by Secure Boot. Revoking old certificates via DBX updates is slow and risks bricking devices on heterogeneous hardware fleets. Microsoft's KB5025885 provides a phased revocation approach, but the transition from the 2011 Microsoft UEFI CA to the 2023 CA is incomplete [@cve-2023-21563].

Recovery key awareness. Encryption-by-default means millions of non-technical users have BitLocker active without understanding recovery key management. If a TPM is replaced, a BIOS update changes PCR values, or the motherboard is swapped, users who do not know they have a recovery key -- or where it is stored -- may permanently lose access to all their data [@elcomsoft-forensics].

Forensic and legal implications. As every Windows device becomes encrypted by default, law enforcement and digital forensics face increasing difficulty accessing data on seized devices. Courts are grappling with compelled decryption and Fifth Amendment implications. Forensic vendors maintain tools that exploit known weaknesses (like bitpixie), but these become less effective as mitigations are deployed [@elcomsoft-forensics]. Twenty years after BitLocker first shipped, the symmetric encryption itself (AES-256) is solved. The unsolved problems are all about trust -- in hardware, in firmware, in cloud key escrow, and in users' ability to manage their own recovery keys.

Practical Guide: Deploying BitLocker Correctly

Theory is useful. Configuration is what actually protects your data. Here is how to deploy BitLocker in a way that addresses the known attack surface.

Recommended Configuration

For sensitive systems, the recommended configuration is:

TPM+PIN -- Closes the TPM bus sniffing gap. The PIN adds a knowledge factor that the TPM requires before releasing the VMK. Even on discrete TPM chips, the attacker cannot extract the VMK without the PIN (though the PIN itself must be strong enough to resist brute-force) [@andzakovic-2019, @scrt-tpm-pin-2024].
XTS-AES-256 -- The maximum key length available. Configure via Group Policy: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Choose drive encryption method and cipher strength.
Software encryption mode -- Do not trust SSD hardware encryption. Force software mode via Group Policy: Configure use of hardware-based encryption for operating system drives: Disabled [@adv180028].
Verify recovery key location -- Check that your recovery key is stored somewhere you can access. For consumers: https://account.microsoft.com/devices/recoverykey. For enterprises: verify Azure AD / Entra ID escrow.

Verification Commands

{` // Simulates the logic of manage-bde -status and Get-BitLockerVolume // In production, run these PowerShell commands: // manage-bde -status C: // Get-BitLockerVolume -MountPoint C: | Select-Object *

const config = { volume: "C:", encryptionMethod: "XTS-AES-256", protectors: ["Tpm", "RecoveryPassword"], encryptionPercentage: 100, lockStatus: "Unlocked", hardwareEncryption: false };

// Check 1: Is a PIN configured? const hasPIN = config.protectors.some(p => p === "TpmPin" || p === "TpmPinStartupKey" ); console.log(hasPIN ? "OK: Pre-boot PIN is configured" : "WARNING: No pre-boot PIN -- vulnerable to TPM bus sniffing" );

// Check 2: Is encryption AES-256? const is256 = config.encryptionMethod.includes("256"); console.log(is256 ? "OK: Using AES-256" : "INFO: Using AES-128 (consider upgrading to 256)" );

// Check 3: Software encryption? console.log(!config.hardwareEncryption ? "OK: Software encryption (not trusting SSD firmware)" : "WARNING: Hardware encryption in use -- verify SSD firmware integrity" );

// Check 4: Recovery password exists? const hasRecovery = config.protectors.includes("RecoveryPassword"); console.log(hasRecovery ? "OK: Recovery password protector exists" : "WARNING: No recovery password -- data may be irrecoverable" );

// Check 5: Fully encrypted? console.log(config.encryptionPercentage === 100 ? "OK: Volume is fully encrypted" : "WARNING: Encryption is " + config.encryptionPercentage + "% complete" );

console.log("\n--- Recommendation ---"); if (!hasPIN) { console.log("Run: manage-bde -protectors -add C: -TPMAndPIN"); console.log("This adds a pre-boot PIN to mitigate bus sniffing attacks."); } `}

Common Pitfalls

Firmware updates triggering recovery mode: BIOS/UEFI updates change PCR values, causing the TPM to refuse VMK release. Always suspend BitLocker before firmware updates: manage-bde -protectors -disable C: [@ms-bitlocker-ps].
Dual-boot scenarios: BitLocker encrypts the Windows volume; Linux cannot natively read BitLocker partitions (though the dislocker tool provides limited read support [@dislocker-github]). Plan partition layouts carefully.
Hardware swaps: Replacing the motherboard or TPM chip triggers recovery mode. Ensure the recovery key is accessible before hardware changes.
Recovery key in deleted Microsoft Account: If the Microsoft Account used during setup is later deleted, the escrowed recovery key is lost. Verify the key is backed up to multiple locations.

No. Full-disk encryption protects data at rest -- meaning when the device is powered off. While the OS is running, the decryption key is in RAM and vulnerable to DMA attacks, cold boot attacks, and malware with kernel access. While in sleep mode, the key is still in RAM. The protection window is narrower than most people assume: it really only covers a powered-off device stolen by someone without your recovery key. BitLocker's source code is not publicly available, so independent code audits are not possible. However, the cryptographic design is published (Ferguson's 2006 paper), the implementation is FIPS 140-2 certified by an independent lab, and the XTS-AES cipher mode is standardized by IEEE and NIST. The recovery key escrow to Microsoft's cloud is not a "backdoor" -- it is a documented feature. If you do not want Microsoft to hold your recovery key, you can store it locally or in on-premises Active Directory instead. No -- not without independent verification. The Radboud University research (Meijer and van Gastel, 2019) proved that Samsung and Critical SSDs had critically broken hardware encryption, affecting drives that the researchers said represented roughly 60% of the consumer SSD market. Microsoft now defaults to software encryption and recommends against relying on SSD hardware encryption unless independently validated. Force software mode via Group Policy. Yes. Your Windows login password protects against *online* attacks -- someone trying to log in while the OS is running. It does nothing against *offline* attacks. An attacker who removes your drive and connects it to another machine bypasses the login screen entirely. Without encryption, your data is readable. A strong login password and full-disk encryption solve different problems. It depends on the workload. Sequential read/write performance drops by about 5% with software BitLocker, barely noticeable in daily use thanks to AES-NI hardware acceleration. Random 4K IOPS -- important for databases and development builds -- can drop by up to 50%, with CPU cycles per I/O increasing by 375%. Microsoft's hardware-accelerated BitLocker in Windows 11 25H2 closes most of this gap, bringing random IOPS to within 10% of unencrypted performance. Your data is permanently inaccessible. There is no master key, no backdoor, and no way to brute-force AES-256. Check these locations for your recovery key: (1) Microsoft Account at account.microsoft.com/devices/recoverykey, (2) Azure AD / Entra ID if your device is enterprise-managed, (3) a printed copy if you saved one during setup. If none of these have the key, the data is gone. Yes, especially on laptops with discrete TPM chips. Without a PIN, the TPM releases the encryption key automatically at every boot with no human input. An attacker with brief physical access can sniff the key from the TPM's SPI bus using a \$5 Raspberry Pi Pico. A pre-boot PIN adds a knowledge factor that the TPM requires before release. Run: `manage-bde -protectors -add C: -TPMAndPIN` to enable it.

What Comes Next

Twenty years of BitLocker history tell a consistent story: the encryption itself was never the weak link. AES has held. XTS mode is mathematically sound. Ferguson's key hierarchy design from 2006 still works.

Every real-world failure -- every headline, every conference demo, every CVE -- targeted the trust boundary around the encryption. The trust that RAM clears instantly (it does not). The trust that SSD firmware encrypts honestly (it did not). The trust that the TPM bus is not observable (it is). The trust that users understand their recovery keys (they do not).

The next chapter of this story will be written by quantum computers and post-quantum cryptography. AES-256 will survive Grover's algorithm. But the RSA and ECC that protect key exchange, TPM attestation, and cloud escrow will not survive Shor's. No shipping FDE system has integrated post-quantum key management yet [@nist-pqc]. The clock is ticking -- and the question is whether the industry will act before the deadline, or after the first quantum key recovery makes the news.

For now, the practical advice is simple: enable TPM+PIN, enforce software encryption, know where your recovery key is, and remember that BitLocker protects your data only when your machine is off.