First what is BitLocker

BitLocker is a logical volume encryption feature included with Microsoft Windows (Pro and Enterprise/Education versions) starting with Windows Vista. It is designed to protect data by providing encryption for entire volumes. On older versions of windows like vista and 7 this feature can only work with a TPM-Chip.

So Why not BitLocker

First and foremost, BitLocker is proprietary software that was never publicly audited created by a company that falls under US law hence has to obey National security letters, see the Lavabit case for an example how that can play out.

Encryption software of any kind should there for be always open source, that is not a guarantee for it being secure, as with the cases of Heartbleed and Apples GotoFail, but being open source is a necessary precondition for it to be able to be considered secure at all.

BitLocker does not really care for security

As shown by the cases below Microsoft in the past did not show the necessary due diligence when developing BitLocker, leaving users to be easily compromised. BitLocker is clearly a product for enterprises designed to be easily manageable at the expense of security. It provides a commercially accepted solution to delegate the responsibility for customer data protection to “someone else”. It is not suitable to protect sensitive personal data, or confidential trade secrets, from a skilled or resourceful adversary.

Case #1 - Self-encrypting deception

Starting with windows 8 (and server 2012) BitLocker got a feature, which is enabled by default, that allows the cryptographic operations of BitLocker encryption to be offloaded to the storage device\'s hardware.

However, Microsoft did not care to audit the various Self-Encrypting Drives (SEDs) hence leaving millions of its users with practically no security what’s o ever. As at the CCC in December of 2018 during the talk Self-encrypting deception independent security researchers have demonstrated live on stage how to bypass the hardware encryption of many SSD models using a ~20€ µC programmer/debugger. Demonstrating that for the past 6 years users of BitLocker and such drives were entirely compromised and did not even knew it. To alleviate this issue the user would have to know about it and use a Groupe Policy to disable this feature. It took Microsoft until late 2019 to change the preset and by default no longer trust SEDs.

Case #2 - TPMs can’t be trusted

By default, Microsoft BitLocker is using the Trusted Platform Module (TPM), to manage the keys, if one is present. Sound’s good until you realize that you can sniff the LPC bus and extract the volume master key, now isn’t that handy.

The issue with TPM’s gets a bit more complicated, modern PC’s often no longer come with a dedicated hardware TPM, instead this feature is being provided by the chipset. So, no exposed LPC bus to connect the sniffer to, one my think, but the reality strikes again. The TPM functionality is nowadays implemented as a firmware module in the Intel Management Engine (ME) or the AMD Platform Security Processor respectively.

And the Intel ME already showed in the past gaping security holes, there is a nice talk about that at the 33c3 and HITBSecConf2017 and of cause 36c3. There is also a Proof Of Concept on Git Hub: https://github.com/ptresearch/IntelTXE-PoC

The issue here is, like before, Microsoft putting blind trust in the hardware vendors, and is not telling it to the user. The correct approached would be to present all the options to the user and provide information about the potential risks.

Given that hardware implementations of encryption are typically yet another black box you can blindly trust, but should not, a reasonable argument is to be made that software-based implementations should by default be preferred.

Case #3 - For your expedience BitLocker can be temporarily suspend

BitLocker in Windows 10 can be configured to store the encryption keys in “the clear” this allows you among other things “Restarting the computer for maintenance without requiring user input”, “Turning off (disabling) or clearing the TPM…”, “Moving a BitLocker-protected drive to another computer…”, etc… so what this feature does is to store a encryption key in plaintext on the drive itself.

Yes, a secret key that is supposed to ensure your security is write in plaintext i.e. unencrypted to the very same disk drive it is supposed to protect, all for your expedience.

Modern SSD’s use something called wear leveling to prolong the life of your SSD, what it does is when writing to the drive the SSD intelligently remaps sectors in the background to spread the wear and tear more equally among all of them. The operating system is not aware of this operation hence on an SSD you can never definitely overwrite a sector, as your write attempt can be redirected to a less used one transparently. Not even the overwriting of the entire SSD can guarantee data to be overwritten as modern SSD’s use overprovisioning to improve performance. The overprovisioned sectors can be accessed by an attacker eider by a firmware hack or by removing the flash chips and reading them out one by one using appropriate hardware.

Now this feature is not only an option for users that don’t care, but in fact used by windows during automatically installed Feature Upgrades.

Case #4 – CVE-2022-41099: WinRE BitLocker bypass vulnerability

A notable security issue (CVE-2022-41099) was discovered in the Windows Recovery Environment (WinRE) that allowed an attacker with physical access to a device to bypass BitLocker encryption. This bypass exists because WinRE can be invoked prior to full OS boot, and when unpatched, it can be leveraged to access encrypted data without needing the BitLocker key.

Microsoft issued patches to address this vulnerability, but deploying them correctly requires manual updates to the WinRE image or the use of update scripts; automated patching mechanisms often do not update WinRE by default, leaving many systems exposed if administrators or users do not take extra steps.

This scenario underscores a systemic reliability and deployment problem in BitLocker’s security posture: a serious bypass vulnerability existed that could be exploited without advanced tooling, yet remediation was non-trivial to apply for many users. In contrast, open-source full-disk encryption tools do not rely on a secondary recovery environment tied to OS-specific boot mechanisms, reducing the surface for similar bypass exploits.

Case #5 – CVE-2023-21563 (Bitpixie) leveraged to extract BitLocker master key

Another serious issue involving BitLocker encryption is the Bitpixie vulnerability (CVE-2023-21563), which has been demonstrated and documented in security research. Under certain conditions—specifically where pre-boot authentication isn’t enforced—attackers can read the BitLocker master key directly from system memory and use it to decrypt stored data within minutes.

This issue was publicly discussed following presentations at security conferences and later explored in proof-of-concept exploits showing how BitLocker can be undermined via software alone, without requiring complex hardware modifications.

The existence of a practical method to extract encryption keys in this way highlights a significant practical weakness in BitLocker’s real-world resistance to sophisticated attacks.

BitLocker uploades your recovery keys to the cloud without asking

If you are using windows 10 with a Microsoft account windows will “save” your BitLocker recovery keys in your Microsoft account. This is done automatically and without an option to opt out, as described here now granted if you care about your privacy you shouldn’t use a Microsoft account at all, but the mere existence of this option is a huge red flag and a threat in itself.

Who guarantees that windows wont “miss interpreted” an unconfigured policy or setting, or just the absence of a configured account and trigger the cloud backup of your most precious secret key “accidently”?

Microsoft is already maintaining some sort of “shadow accounts” for machines which are not using a Microsoft account linked to the activation data and maintaining the app history as reported on by the borncity blog.

Cloud-stored recovery keys and dovernment access

In early 2026 it became publicly known that Microsoft has provided BitLocker recovery keys to the FBI when served with a valid legal order, allowing law enforcement to decrypt BitLocker-protected systems. The reported cases relied on the fact that BitLocker recovery keys had been automatically uploaded to Microsoft’s cloud infrastructure and were therefore accessible to Microsoft itself. (Windows Central, ComputerBase (DE))

This is not a vulnerability in the cryptographic algorithms themselves, but a systemic design decision: BitLocker integrates key escrow into a third-party cloud service that operates under U.S. jurisdiction. If a recovery key is stored with Microsoft, it can be disclosed under lawful compulsion without the user being technically able to prevent it at the time of access.

From a security and privacy perspective, this fundamentally changes the threat model. Full-disk encryption is expected to ensure that only the key holder can decrypt the data. BitLocker’s default behavior breaks this assumption by introducing an additional trusted party that holds a usable copy of the key. Whether this behavior is triggered intentionally (by signing in with a Microsoft account) or unintentionally (through misconfiguration or future policy changes), the mere existence of this mechanism constitutes a significant risk.

Open-source encryption solutions do not implement cloud-based key escrow and do not rely on external service providers for key storage. As a result, there is no third party that can be compelled to hand over decryption keys, making this class of lawful access technically impossible rather than merely policy-restricted.

But what about windows

One may ask: If I don’t trust MSFT with making BitLocker secure or even assume they may have added a backdoor, isn’t everything lost anyways for every tool that runs under MSFT Windows anyways?

Windows itself could indeed just extract any cryptographic keys from 3rd party tools from Memory and send it to Redmond, but this is highly unlikely to be implemented. A backdoor by a large company must be implemented such that it being intentional can always be plausibly denied, it must look like a programming error.

Therefor an obvious backdoor in Windows, like intentionally sending keys from a 3rd party encryption tool to MSFT, is highly unlikely as this could be found out, especially if it happens on every windows system and, could not be plausibly denied by MSFT.

One deniable channel of attack could be to intentionally crash the system with an update, grab the kernel crash dump and arrange things for it to likely include the sought for keys. But than if you value your privacy you should have disabled error reporting and probably system crash dump creation altogether anyways. Also, MSFT is not in the business of crashing their user’s PC’s on purpose it is extremely unlikely that would role something like that out to all their users. And if you are interesting enough for a targeted effort, you should indeed switch to a self-compiled Linux ASAP.