# BitLocker and self-encrypting drives: when hardware encryption helps

> How BitLocker uses eDrive/Opal drives, how to check the encryption status, why hardware encryption has a trust caveat, and where recovery keys live.

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

BitLocker can encrypt in two ways:

- **Software encryption** — the CPU encrypts, the drive sees plaintext. Works on any drive.
- **Hardware encryption (eDrive/Opal)** — the drive encrypts internally with its own key, and BitLocker manages that key.

Hardware encryption is faster because the drive does the work, but it moves trust to the drive's firmware. That is the trade-off, not a free win.

## Check the current state

```powershell
manage-bde -status
Get-BitLockerVolume | Select-Object MountPoint,VolumeStatus,EncryptionMethod,ProtectionStatus,KeyProtector
```

Look at the **encryption method** and the drive's reported capability:

- `XtsAes128` / `XtsAes256` — software encryption.
- `HardwareEncryption` — the drive is doing the work.
- `UsedSpaceOnly` — encrypts only allocated space; faster to enable, leaks free-space patterns.

A drive that reports hardware encryption support but is running software encryption usually means BitLocker did not trust the drive's firmware (a group policy or the OS default), or the setting was forced to software.

## Why BitLocker sometimes refuses hardware encryption

Microsoft's guidance has been cautious about self-encrypting drive firmware. If the firmware can be tricked into revealing its key, encryption is theatre.

Practical consequences:

- Some Windows builds default to software encryption even on Opal drives.
- Group Policy can force hardware or software encryption.
- Enterprise fleets may standardise on software encryption for auditability.

For a laptop with a modern CPU, software AES-XTS is fast enough that the difference is rarely worth the trust trade.

## Set it up, in the right order

1. Confirm the machine has a TPM 2.0 and Secure Boot enabled.
2. Back up the recovery key **before** enabling — to a Microsoft account, AD/Entra, or a printed file stored separately.
3. Enable BitLocker on the OS volume.
4. Decide whether to encrypt fixed data volumes automatically or manually.
5. Record what happens on firmware updates and motherboard replacement.

```powershell
# check protection and key protectors
Get-BitLockerVolume C: | Select-Object VolumeStatus,ProtectionStatus,KeyProtector
# recovery password (treat as a secret)
(Get-BitLockerVolume C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
```

## What breaks, and how to avoid it

| Situation | What happens | Prevention |
|---|---|---|
| TPM cleared or firmware reset | Boot asks for recovery key | Keep the key off the machine |
| Motherboard replaced | Recovery prompt | Suspend BitLocker before hardware service |
| Dual-boot OS changes | Recovery prompt, or the other OS cannot read the disk | Suspend before changes |
| Firmware update | Sometimes a recovery prompt | Suspend-protect, update, resume |
| Drive moved to another PC | Recovery prompt | It is working as designed |

```powershell
# before firmware/BIOS updates or hardware service
Suspend-BitLocker -MountPoint C: -RebootCount 1
```

## Performance expectations

- Software XTS-AES on a modern CPU is fast; the overhead is small for normal workloads.
- Hardware encryption offloads CPU but adds a firmware dependency.
- `UsedSpaceOnly` makes initial encryption much faster on a new install.

Do not benchmark BitLocker on a VM and quote the numbers — virtualised AES performance is not representative.

> **Danger: A lost recovery key means a lost disk**
>
> BitLocker is designed so that nobody can decrypt without a key protector. If the TPM is cleared and the recovery key is gone, the data is gone. Store the key somewhere that is not the encrypted machine.

## When not to use it

- A desktop that never leaves a locked room, where recovery-key management is the bigger risk.
- Servers where you cannot guarantee key escrow — a reboot at 3am that stops for a recovery prompt is an outage.

## Related

- [Storage Spaces](https://windows.homes/en/hardware/storage/storage-spaces/)
- [Drive health](https://windows.homes/en/hardware/storage/health-smart/)

## Lab boundary

E1. BitLocker behaviour is documented by Microsoft. The lab did not enable BitLocker with a self-encrypting drive, so no hardware-encryption performance claim is made here.

## Sources

- [Microsoft Learn — BitLocker overview](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/)
- [Microsoft Learn — BitLocker FAQ](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/faq)
- [Microsoft Learn — manage-bde](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/manage-bde)

---

Source: https://windows.homes/en/hardware/storage/bitlocker-hardware-encryption/