Why BitLocker Matters for CMMC
BitLocker is Microsoft's built-in full-volume encryption feature for Windows. For most defense contractors, it is the control that protects Controlled Unclassified Information (CUI) sitting on a laptop or workstation hard drive when the device is powered off, lost, or stolen. It is free, native to Windows Pro and Enterprise, and centrally manageable through Intune or Group Policy, which is why it is the default answer to "how do we encrypt CUI at rest" across the Defense Industrial Base.
Two NIST SP 800-171 requirements make that encryption a contractual obligation, not a nice-to-have. Both sit in the System and Communications Protection (SC) domain and each carries 5 SPRS points.
| Requirement | Description | SPRS Points | POA&M Eligible |
|---|---|---|---|
| SC.L2-3.13.16 | Protect the confidentiality of CUI at rest. | 5 | Conditional |
| SC.L2-3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. | 5 | Conditional |
The Media Protection (MP) domain reinforces the same point from the physical-media angle. MP.L2-3.8.1 requires you to protect system media containing CUI, and disk encryption is the standard way contractors satisfy it for laptops and removable drives. The catch buried in SC.L2-3.13.11 is the word FIPS-validated. Encrypting a drive is not enough on its own. The cryptographic module doing the encryption has to carry a valid FIPS 140-2/140-3 validation certificate, and BitLocker has to be operating in its FIPS-approved mode.
What Actually Controls BitLocker Encryption
To understand the exploits, you have to understand where the key lives. BitLocker encrypts the volume with a Full Volume Encryption Key (FVEK). The FVEK is itself encrypted by a Volume Master Key (VMK), and the VMK is sealed by one or more protectors. The protector is the thing an attacker has to defeat, and the choice of protector is the single most important security decision you make.
On most Windows devices the protector is the Trusted Platform Module (TPM), a dedicated security chip that releases the VMK automatically at boot if the measured boot state is unchanged. This is convenient: the user just turns the machine on and Windows decrypts transparently. It is also the weakness. In TPM-only mode there is no human secret in the chain. If an attacker can convince the TPM to release the VMK, or intercept it as it travels from the chip to the CPU, the disk is open. Adding a startup PIN (TPM+PIN) or a USB startup key inserts a secret the TPM does not hold, which is what breaks nearly every attack in the next section.
MP (Media Protection) — protecting the physical media the encrypted CUI lives on (3.8.1), including laptops and removable drives.
PE (Physical Protection) — every practical BitLocker attack below requires physical possession of the device. Strong physical access controls (3.10.1) and escorting/monitoring of visitors are a genuine compensating control, because an attacker who never touches the hardware cannot run any of these exploits.
That last point is why the Physical Protection domain belongs in this conversation. BitLocker's threat model is the lost or stolen device and the "evil maid" who gets a few minutes alone with a powered-off laptop. Locked offices, device check-in/check-out, asset tracking, and a clean-desk policy for CUI-bearing hardware all reduce the probability that an attacker ever gets the physical access these exploits need.
The Recent Exploits: Why TPM-Only Is No Longer Safe
A decade of research has steadily eroded the security of default BitLocker. The headline of 2025 and 2026 is that a TPM-only device, the Windows 11 default, can now be opened with a software-only attack and no soldering. The table below summarizes the attack classes that matter for a contractor protecting CUI.
| Attack | Class | What It Does | Status (2026) |
|---|---|---|---|
| bitpixie CVE-2023-21563 |
Software | Abuses the Windows Boot Manager's PXE soft-reboot path, which fails to wipe the VMK from memory. An attacker boots a signed but older, vulnerable boot manager via a downgrade and reads the key out of RAM. No disassembly, no soldering, leaves no physical trace. | Patched, but still reachable by certificate downgrade until UEFI CA 2023 enforcement. |
| YellowKey CVE-2026-45585 |
Software | Abuses trusted behavior in the Windows Recovery Environment (WinRE). An attacker stages crafted files on a USB drive or the EFI partition, reboots into WinRE, and triggers an unrestricted shell that exposes the unlocked volume. Affects Windows 11 24H2/25H2/26H1 and Server 2025 in TPM-only mode. | Active / unpatched at disclosure; mitigated by config change or TPM+PIN. |
| TPM bus sniffing | Hardware | On systems with a discrete TPM chip, the VMK travels in cleartext across the LPC or SPI bus between the TPM and CPU. A cheap logic analyzer clipped to the board captures it, demonstrated in well under a minute on some hardware. | Active; unpatchable on shipped hardware with a discrete TPM. |
| DMA / PCILeech, Thunderspy | Hardware | Direct Memory Access attacks via PCIe, M.2, or Thunderbolt read the VMK out of the RAM of a running or sleeping machine using sub-$200 hardware. | Mitigated by Kernel DMA Protection on modern hardware; active on older devices. |
| faulTPM | Hardware | Voltage-glitching attack against AMD firmware TPMs (Zen 2/3) that extracts sealed secrets. Under ~$200 in hardware but high expertise. | Active on Zen 2/3; no public attack on Zen 4+. |
| Cold boot / hibernation | Physical | Keys recovered from DRAM shortly after power-off, or pulled from hiberfil.sys with memory-forensic tools. |
Largely mitigated on modern DDR4/DDR5 hardware; manage hibernation explicitly. |
| Recovery-key / escrow extraction | Credential | The 48-digit recovery key is the master skeleton key. If it is auto-escrowed to a personal Microsoft account, an unmanaged OneDrive, or an Entra/AD tenant an attacker can reach, the disk is open with no exploit at all. | "Active by design" — this is how recovery is supposed to work, which is why key custody is a control. |
The common thread is the protector. bitpixie, YellowKey, bus sniffing, faulTPM, and the boot-chain family all target the TPM's automatic, unattended release of the VMK. Every one of them requires physical access to the device, and nearly every one of them is defeated, or made dramatically harder, by requiring a pre-boot secret the TPM does not store.
How to Secure BitLocker
You do not have to abandon BitLocker. A correctly hardened configuration closes the entire software boot-chain family and most of the hardware attacks. The measures below are ordered by impact.
1. Require pre-boot authentication (TPM+PIN)
This is the single highest-impact change. Adding a startup PIN means the VMK is never released without a secret the TPM does not hold, which defeats bitpixie, YellowKey, S3-reset attacks, and on modern hardware (Intel PTT or AMD Zen 4+) effectively the whole boot-chain family. Configure it through Group Policy or Intune:
2. Deploy the UEFI CA 2023 / KB5025885 boot-chain hardening
bitpixie and related downgrade attacks work by booting an older, still-trusted boot manager. KB5025885 revokes the vulnerable Windows Production PCA 2011 certificate and installs the new Windows UEFI CA 2023, blocking the downgrade path. The current certificates expire in 2026 and the transition becomes mandatory, so deploy and validate this now rather than during a forced cutover.
3. Turn on FIPS mode (required for SC.L2-3.13.11)
For the encryption to count as FIPS-validated, BitLocker must use FIPS-approved algorithms. Enable the policy "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" before the volume is encrypted, and confirm the device's cryptographic module appears on the CMVP validated modules list. Note that in FIPS mode the numeric recovery password protector behaves differently; plan recovery-key management accordingly and capture the configuration as SSP evidence.
4. Enable Kernel DMA Protection and Secure Boot
Kernel DMA Protection blocks the PCILeech and Thunderspy DMA attacks on supported hardware. Verify it is active by running msinfo32 and checking for "Kernel DMA Protection: On." Keep Secure Boot enabled so only signed boot components load, which underpins the integrity measurements the TPM relies on.
5. Control recovery keys and hibernation
Escrow recovery keys to a managed, access-controlled location, Intune/Entra for a managed tenant or Active Directory, never a personal Microsoft account or an unmanaged OneDrive. Restrict who can read recovery keys (Global Administrators and Cloud Device Administrators can in Entra). Disable hibernation on CUI endpoints or ensure the hibernation file is protected, since hiberfil.sys can leak the FVEK.
6. Mitigate the YellowKey WinRE path specifically
Until Trusted WIM Boot is broadly deployed, apply Microsoft's WinRE hardening for CVE-2026-45585: remove autofstx.exe from the offline BootExecute registry value in the recovery image and reseal BitLocker trust using Microsoft's provided script, or simply move to TPM+PIN, which neutralizes the attack regardless.
Alternative and Complementary Encryption Options
BitLocker is rarely the wrong choice for a Windows-centric CUI environment, but it is not the only one, and some environments need more. The options below are the ones DIB contractors actually evaluate.
| Option | What It Is | FIPS / CMMC Fit | Best For |
|---|---|---|---|
| BitLocker (TPM+PIN, FIPS mode) | Native Windows full-volume encryption with pre-boot authentication. | FIPS-validated module available; satisfies 3.13.11 / 3.13.16 when configured correctly. | The default for managed Windows fleets; lowest cost, central management via Intune/GPO. |
| VeraCrypt | Open-source full-disk and container encryption, successor to TrueCrypt. Already referenced in 1TEN's MP tooling guidance. | Strong encryption, but the standard build is not FIPS 140-validated. Use only where a validated module is not required, or pair with a validated crypto layer. | Non-Windows, air-gapped, or encrypted-container use cases; defense-in-depth on top of FDE. |
| Self-encrypting drives (TCG Opal SED) | Hardware encryption performed by the drive's own controller (Samsung, Micron, Seagate, etc.), managed with pre-boot authentication. | Choose drives with a FIPS 140-2/140-3 validated crypto module. Hardware-managed and not affected by Windows boot-chain attacks, but require their own management tooling. | High-assurance endpoints; environments standardizing on hardware encryption with PBA. |
| Commercial endpoint encryption (Sophos, Symantec/Broadcom, McAfee/Trellix, Dell) | Enterprise platforms that wrap and manage BitLocker (or their own engine) with central key escrow, reporting, and policy. | Most ship FIPS-validated modes and produce the compliance reporting assessors like. Often manage BitLocker rather than replace it. | Larger fleets needing centralized key management, audit reporting, and mixed-OS coverage. |
| macOS FileVault | Apple's native full-disk encryption using the Secure Enclave / T2 / Apple Silicon. | Apple's CoreCrypto modules carry FIPS 140 validations; enable and manage via MDM. | Mac endpoints in the CUI boundary; the BitLocker equivalent for Apple hardware. |
| Linux LUKS / dm-crypt | Native Linux full-disk encryption. | FIPS posture depends on the distribution's validated crypto (e.g., a FIPS-mode RHEL kernel module). Validate the specific module. | Linux servers and workstations holding CUI; pair with TPM/PBA where available. |
| GCC High / cloud-resident CUI | Keep CUI off the endpoint entirely in Microsoft 365 GCC High, GovCloud, or a VDI/DaaS boundary. | Service-side FIPS-validated encryption; shifts the data-at-rest control to the platform. | Reducing endpoint scope; pairs well with a VDI approach to CMMC so CUI never lands on the laptop. |
The strategic point: full-disk encryption protects data at rest on a device you still control physically. The most durable way to neutralize the BitLocker attack surface is to keep CUI off endpoints altogether, using GCC High or a VDI boundary so a lost laptop holds no CUI to recover. Where CUI must live on endpoints, hardened BitLocker (TPM+PIN, FIPS mode) or a FIPS-validated SED is the practical baseline, and physical controls are the compensating layer that keeps an attacker from ever getting the device in hand.
FAQ
It can be, but only when BitLocker is operating in FIPS-approved mode with a cryptographic module that holds a current CMVP validation. Turning BitLocker on with default settings encrypts the disk but does not automatically meet SC.L2-3.13.11, which specifically requires FIPS-validated cryptography. Enable the FIPS algorithm policy before encrypting and document the validated module as evidence.
For CUI-bearing endpoints, you should require a PIN. TPM-only mode is the configuration defeated by bitpixie, YellowKey, and TPM bus sniffing because the key is released automatically with no human secret. TPM+PIN inserts a secret the TPM does not hold, which closes the software boot-chain attacks and, on modern hardware, most of the hardware attacks too. The usability cost is one PIN entry at boot.
Both are real and both target the default TPM-only configuration, but both require physical access to the device, and both are mitigated by the same control: TPM+PIN. bitpixie also requires the device to still accept a downgraded boot manager, which the UEFI CA 2023 / KB5025885 update closes. YellowKey is fixed by Microsoft's WinRE hardening or, again, by moving to TPM+PIN. If your fleet runs TPM-only today, treat the move to TPM+PIN as a priority remediation item.
Every practical BitLocker attack, software or hardware, requires the attacker to physically possess the device. Strong physical controls under the PE domain, locked storage for CUI laptops, device check-in/check-out, visitor escorting, and asset tracking, reduce the probability that an attacker ever gets the few minutes of physical access these exploits need. Physical protection and encryption are complementary layers, not substitutes.
Be careful. VeraCrypt provides strong encryption, but the standard build is not FIPS 140-validated, which means it does not by itself satisfy SC.L2-3.13.11 where FIPS-validated cryptography is required for CUI. It is useful for non-Windows systems, encrypted containers, or as a defense-in-depth layer, but for the primary CUI-at-rest control you generally want a FIPS-validated option: hardened BitLocker, a FIPS-validated self-encrypting drive, or a managed commercial encryption platform.
Stop storing CUI on endpoints. If CUI lives only in Microsoft 365 GCC High, GovCloud, or behind a VDI/DaaS boundary, a lost or stolen laptop contains no CUI to recover and every attack in this article becomes moot for that data. Encryption at rest then becomes the platform's responsibility under its own FIPS-validated controls. Many contractors pair a reduced-scope endpoint posture with hardened BitLocker as a backstop.