Hot Take A key component in Windows 11 is getting a huge performance boost soon

[Parkinsond]

With NVMe technology getting even better, I/O operations are faster, and consequently, BitLocker struggles to keep up without taking a bigger chunk of CPU cycles. This means that there is a significant performance impact due to the bottleneck that customers notice and obviously don't appreciate.

To work around this problem, Microsoft recently announced hardware-accelerated BitLocker, which will leverage upcoming system on chip (SoC) and CPU capabilities, in addition to maintaining existing support for UFS Inline Crypto Engine technology. There are two new upcoming capabilities that hardware-accelerated BitLocker is focused on:

• Crypto offloading: BitLocker shifts bulk cryptographic operations from the main CPU to a dedicated crypto engine. This capability frees up CPU resources for other tasks and helps improve both performance and battery life.
• Hardware protected keys: BitLocker bulk encryption keys, when necessary SoC support is present, are hardware wrapped, which helps increase security by reducing their exposure to CPU and memory vulnerabilities. This is an addition to the already supported Trusted Platform Module (TPM), which protects intermediate BitLocker keys, putting us on a path to completely eliminate BitLocker keys from the CPU and memory.

https://www.neowin.net/news/a-key-component-in-windows-11-is-getting-a-huge-performance-boost-soon/

 

[Bot]

What you quoted lines up with what Microsoft has been briefing publicly: a future “hardware-accelerated BitLocker” mode that (1) offloads bulk crypto from general CPU cores to a dedicated on-die crypto engine and (2) keeps the bulk encryption keys hardware-wrapped so they’re less exposed to CPU/RAM attacks.

What’s actually “new” here (vs what BitLocker already does)

• Not the same thing as AES-NI: Today, BitLocker can already use CPU instruction acceleration (AES-NI, etc.), but it’s still running the encryption work on the general-purpose CPU cores and the keys still exist in normal system memory at runtime. The announced change is about moving bulk crypto and key handling into a protected hardware boundary.
• Not the same thing as SSD “hardware encryption” (TCG Opal/eDrive): That model relies heavily on the storage device/controller doing encryption and can come with separate manageability and trust concerns. What Microsoft is describing is platform crypto offload (SoC/CPU crypto engine) plus silicon-level key protection, and they explicitly mention keeping existing support for UFS inline crypto as well.
• TPM still matters: TPM-based protectors/measurements don’t go away; the “hardware protected keys” piece is about reducing exposure of the bulk disk encryption keys to CPU and RAM.

Timeline / availability
Microsoft has been pointing to availability on new devices starting spring 2026, and it will be dependent on OEM + silicon support (so it won’t be something you can assume will light up on existing PCs/servers just via an OS update).

Why this helps performance (especially with fast NVMe)
On very fast storage, the “encrypt/decrypt per I/O” work can become a visible CPU tax in some workloads. Offloading bulk crypto can reduce:

• CPU utilization attributed to BitLocker
• latency/throughput impact for high I/O workloads
• power draw (more relevant on mobile, but still useful for efficiency)

Practical caveats to keep in mind

• It’s hardware-conditional: expect mixed fleets (some systems support it, some don’t), which complicates standardization and benchmarking.
• Firmware/driver trust increases: moving more of the crypto path into silicon/firmware can be a net win, but it also raises the importance of timely BIOS/firmware updates and vendor transparency.
• Enterprise recovery flows still apply: even if keys are better protected, you still need solid recovery-key escrow (AD/Azure AD/Entra ID, etc.) and tested recovery procedures.

Actionable takeaway for admins right now
Treat this as a promising upcoming platform feature, but don’t plan around specific performance numbers until Microsoft/OEMs publish a compatibility matrix and you can benchmark on the exact target hardware. For current deployments, the best “safe now” approach is to keep BitLocker enabled, ensure TPM/Secure Boot are correctly configured, stay current on firmware/UEFI updates, and baseline your I/O + CPU metrics so you can quantify any improvement when 2026-class hardware arrives.