BitLocker cracked via side-channel attack: what was really demonstrated
Last updated January 16, 2026
BitLocker is used by many organizations as standard encryption for Windows systems. That feels logical: It's deep in the operating system and has been around for years. Yet an independent researcher showed that BitLocker can be attacked under specific circumstances. Not through software, but through the hardware itself.
That raises questions. Not so much about BitLocker as a product, but about assumptions often made around physical access and encryption.

What exactly has been demonstrated?
The attack does not focus on breaking BitLocker's mathematical encryption. The algorithms used have not been “cracked.” What has been demonstrated is that the encryption key can be derived during a system's boot process.
This only happens when an attacker has physical access to the device. The attack uses measurable signals that a computer emits while BitLocker processes the key. In this case, a simple microcontroller was used for that purpose. Important detail: this only works with certain configurations and requires targeted preparation.
How does such a side-channel attack work?
A side-channel attack uses indirect information. Consider power consumption, electromagnetic radiation or timing differences. Those signals are not part of the encryption design, but they arise during its execution.
This demonstration measured processor power consumption during BitLocker unlocking.
Overall, it goes like this:
- First, the system is started up in a controlled state.
This is necessary to determine the time at which BitLocker processes the key. - During that process, power consumption is accurately measured.
Small fluctuations correlate with specific operations in the chip. - Those measurements are analyzed to identify patterns.
With enough repetition, information about the key can be derived from that.
This requires knowledge, time and physical access. It is not an attack you “just do”.
What does this mean for BitLocker users?
For everyday use, little changes. BitLocker remains effective against theft, loss and remote attacks. The vulnerability is in a scenario that is often underestimated: someone being able to access the device undisturbed.
This is relevant to:
- laptops left unattended
- systems without pre-boot authentication
- environments where TPM settings are left default
The bottom line is not that BitLocker is insecure, but that encryption alone is not sufficient if physical access is possible.
What specifically can you do now?
There are a few measures that greatly reduce the risk:
- Always use pre-boot authentication, such as a PIN or password.
With that, the key is released only after additional verification. - Check TPM settings and firmware updates.
Manufacturers are improving these types of attack vectors step by step. - Combine encryption with physical security.
Encryption relies on assumptions. Physical access breaks those. - Limit who can get their hands on devices, even temporarily.
Many attacks are possible only with rest and time.
These are not exotic measures, but they are often skipped in practice.
Practical advice on encryption and hardware?
Frequently Asked Questions
Is BitLocker now insecure?
No. The encryption used is not broken. The attack abuses hardware behavior under specific circumstances. For most situations, BitLocker remains solid.
Can this be done remotely?
No. Physical access to the device is required. Without it, this attack is not feasible.
Does this apply to all Windows systems?
No. The attack depends on hardware, firmware and configuration. Systems with additional authentication are much less vulnerable.
Should I switch to other encryption?
Not necessarily. Better to set up BitLocker correctly and combine it with additional measures. Encryption always works within an overall picture.
Will this get worse in the future?
Attacks on hardware are becoming more sophisticated. At the same time, manufacturers are improving their mitigations. Conscious configuration remains more important than the product chosen.



