Microsoft is Giving the FBI BitLocker Keys

Microsoft gives the FBI the ability to decrypt BitLocker in response to court orders: about twenty times per year.

It’s possible for users to store those keys on a device they own, but Microsoft also recommends BitLocker users store their keys on its servers for convenience. While that means someone can access their data if they forget their password, or if repeated failed attempts to login lock the device, it also makes them vulnerable to law enforcement subpoenas and warrants.

Tags: , , , ,

Posted on February 3, 2026 at 7:05 AM • 13 Comments

Comments

Vesselin Bontchev • February 3, 2026 7:29 AM

It’s not just the FBI – Microsoft hands out these keys to any law enforcement agency of any country with a valid warrant.

And the problem is not so much that the keys are stored on Microsoft’s servers but that they aren’t encrypted there (e.g., with a key stored in the TPM of the device).

The other problem, of course, is that Microsoft is making it increasingly impossible to install Windows without a Microsoft account, in which case a ton of your personal stuff is stored on their servers anyway.

Winter • February 3, 2026 7:34 AM

MS makes things easy for users. As many (most) user will lose their passwords at least once in a lifetime, MS will have to make password recovery easy.

Again, and example of the eternal choice in cryptography:

Easy or Secure

Anyhow, as I have seen over 4 decades of MS failing to honor their promisses, always, I had no illusions of security with bitlocker to begin with.

Personally, I stick with VeraCrypt. It has my sweet point of easy vs secure.[1]

If I would ever have to use Windows full disk encryption, I would separate the running machine using bitlocker (just to weed out the script kiddies) and store my personal data in VeraCrypt (or my fancy of the week).

[1] Do not bother to explain the shortcomings of VeraCrypt to me. I don’t fight MOSSAD, GRU, nor NSA. For me, Data At Rest is secure enough, as is my personal trust of the end points. YMMV

TimH • February 3, 2026 8:35 AM

MS also defaults BL to 128 bit, not the other option 256 bit. Since CPUs have the AES-NI instruction that makes decrytion very fast, this is a deliberate weakening.

gpedit.msc: “If you disable or do not configure this policy setting, BitLocker will use the default encryption method of AES 128-bit with Diffuser”

LULZ • February 3, 2026 9:04 AM

@Q: What Does FBI Stand For?,

I’m sure you meant populating or breeding instead of “breading.”
In this blog we’re used to all kinds of typos, even by the more advanced, “well read” commenters such as Clive Robinson.

K.S • February 3, 2026 10:59 AM

I am not aware of a way to bruteforce 128-bit AES key, so unless other shenanigans (e.g., attacks on the entropy source) involved I don’t see it as a valid criticism of MS.

Rontea • February 3, 2026 12:24 PM

What’s at stake here isn’t just personal privacy—it’s the structural integrity of our democracy. When encryption keys are centrally stored and can be compelled by government order, we create a single point of failure for civil liberties. This isn’t about one FBI request in Guam; it’s about the precedent that access to private data is negotiable. Centralized key storage turns every user device into a potential surveillance node, eroding the principle of individual security that underpins trust in both technology and governance. Democracies thrive when citizens can safely communicate and store information without the constant threat of compelled exposure. Weakening that foundation in the name of convenience or compliance risks shifting the balance of power away from the people and toward unchecked institutional oversight.

FireWave • February 3, 2026 1:33 PM

The real question is why Microsoft doesn’t encrypt this data. Deriving an encryption key from the user’s password would be straightforward.

Clive Robinson • February 3, 2026 2:26 PM

@ K.S., ALL,

With regards,

“I am not aware of a way to bruteforce 128-bit AES key, so unless other shenanigans”

Whilst the algorithm is strong the implementation was brittle when you put it into “go faster stripes” of “loop unrolling”, it opened up side channels, which is something the closed community of the NSA, GCHQ and one or two other SigInt agencies knew a lot about, but few outside knew about it or cared.

I’ve reason to believe that the NSA put “the fix in” via NIST and in effect “rigged the AES competition” very much in their favour. And why MicroSoft received little or no issues writings secure code that was anythin but….

There is a clear history of this going on before the NSA was ever even thought about and goes back to Friedman and his Wife at the Riverbank laboratory and onwards.

You can see it in the design of the mechanical ciphers of Boris Hagelin that Friedman “advised”. And later encouraged Hagelin to set up Crypto AG in Zug Switzerland where we now know almost every machine had deliberately weaknesses built in.

The fix of AES was so good from the NSA perspective because it allowed the Key or Plaintext to be quickly and easily identified even well outside the computer on the network cable… Microsoft are certainly known to have “played along” by the “file formats” used for Office packages with the equivalent of “known plaintext” at the begining of the files to be sent mad cryptanalysis checking cery much easier than it might otherwise have been.

I could go on but, how much info do people need to know that MicroSoft very definitely “played along” with the NSA. And I assume they still do so.

Not really anonymous • February 3, 2026 2:47 PM

It was known before it was selected, that AES had problems with the reference algorithm leaking secrets because memory addresses were derived from secret data and the affect on timing of cache, made that data accessible to adversaries that can measure the time of AES calculations. I read comments about that while the competition was still going on.
Since that time, constant time algorithms for AES have been developed. But I bet a lot of amatuers use the original algorithm out of ignorance.

Leave a comment

Blog moderation policy

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.