BitLocker hardening: XTS-AES 256, TPM+PIN, key escrow

BitLocker turns a lost or stolen device from a data breach into a hardware expense. Most organisations turn it on; far fewer configure it against anything more than casual theft. The difference lies in four decisions: the encryption method, how the key is released at boot, where recovery keys live, and whether the boot chain around BitLocker is itself protected.

The threat model in one table

TPM-only is a reasonable default for most office laptops. Executives, administrators, travellers and devices with sensitive data warrant TPM+PIN.

Step 1: choose the encryption settings

GPO path: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption.

Existing volumes keep their original cipher. Changing the policy only affects volumes encrypted afterwards; to move an old AES-128 volume to XTS-AES 256 you must decrypt and re-encrypt.

Step 2: configure startup authentication

Under Operating System Drives > Require additional authentication at startup:

• Enabled.
• Allow BitLocker without a compatible TPM: unchecked.
• Configure TPM startup: Allow TPM.
• Configure TPM startup PIN: Allow startup PIN with TPM (or Require for high-risk groups via a separate GPO).
• Leave startup key options as Do not allow unless you have a reason for USB keys.

Related settings:

To add a PIN to an already encrypted device:

$pin = Read-Host -AsSecureString "Startup PIN"
Add-BitLockerKeyProtector -MountPoint C: -TpmAndPinProtector -Pin $pin

Step 3: escrow recovery keys first

A device that is encrypted without an escrowed recovery key is a future data-loss incident. Under Operating System Drives > Choose how BitLocker-protected operating system drives can be recovered:

• Allow data recovery agent: optional.
• Save BitLocker recovery information to AD DS: Enabled, store recovery passwords and key packages.
• Do not enable BitLocker until recovery information is stored to AD DS: Enabled.
• Omit recovery options from the setup wizard: Enabled (users cannot choose to print or save the key to a file).

For Entra-joined devices, the Intune BitLocker profile does the equivalent and stores keys in Entra ID. For existing devices, back up the key explicitly:

$kp = (Get-BitLockerVolume -MountPoint C:).KeyProtector |
      Where-Object KeyProtectorType -eq 'RecoveryPassword'
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId    # AD DS
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId  # Entra ID

Restrict who can read recovery keys. In AD, keys are stored in msFVE-RecoveryInformation child objects of the computer; review which groups can read them, as with LAPS passwords. Configure key rotation after use (Intune supports rotating the recovery password when it has been shown to a user).

Step 4: protect the boot chain

BitLocker trusts the TPM, and the TPM trusts what it measured at boot. Make sure that chain is intact:

• UEFI with Secure Boot on every device. Check with Confirm-SecureBootUEFI (returns True).
• TPM 2.0, firmware up to date (Get-Tpm).
• PCR 7 binding: manage-bde -protectors -get C: shows the PCR validation profile; msinfo32 shows PCR7 Configuration: Bound on modern devices. This makes BitLocker rely on Secure Boot state instead of individual boot component hashes, so firmware updates cause fewer recovery prompts.
• Kernel DMA Protection (visible in msinfo32) on devices with Thunderbolt or USB4. On older hardware without it, TPM+PIN or disabling external DMA ports in firmware compensates.
• Firmware password set on devices where it's supported, so the boot order and Secure Boot can't be changed casually.
• Hibernate rather than sleep for high-risk devices: set Allow standby states (S1-S3) when sleeping (on battery) and (plugged in) to Disabled under System > Power Management > Sleep Settings, so keys are not in RAM while the lid is closed.

Step 5: verify across the fleet

On a device:

Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionMethod,
  EncryptionPercentage, ProtectionStatus, KeyProtector
manage-bde -status C:

You want ProtectionStatus: On, EncryptionMethod: XtsAes256 and protectors Tpm or TpmPin plus RecoveryPassword.

ProtectionStatus: Off with a fully encrypted volume means BitLocker is suspended (for example left over from a firmware update script with Suspend-BitLocker), and the key is stored in clear on the disk. Resume it with Resume-BitLocker -MountPoint C: and hunt for scripts that suspend without a reboot count.

Fleet-wide, report from Intune's encryption report, Configuration Manager's BitLocker management, or a compliance script collecting the values above. Alert on devices with no escrowed key and on volumes left suspended.

Useful logs: Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management records protector changes, encryption start/stop and key backups.

Automatic device encryption

On modern hardware, Windows 11 enables device encryption automatically during setup when the user signs in with a Microsoft or work account, and recent releases apply it to more devices. It uses XTS-AES 128 and TPM-only protection, and the key goes to the signed-in account. For managed devices, apply your BitLocker policy during provisioning so the managed configuration (cipher, escrow target, PIN) replaces the automatic one; otherwise you may inherit AES-128 volumes whose keys sit in a personal account.

Checklist

• XTS-AES 256 for OS and fixed drives; full encryption for reused hardware
• TPM-only for standard devices, TPM+PIN (enhanced PIN) for high-risk users
• Encryption blocked until the recovery key is escrowed
• Access to recovery keys restricted and audited
• Secure Boot on, TPM 2.0, PCR 7 bound, Kernel DMA Protection verified
• Sleep disabled in favour of hibernate for high-risk laptops
• Fleet report on protection status, cipher and key escrow; alert on suspended volumes

BitLocker's strength depends on the boot chain it sits on. The same virtualization-based security that protects the boot chain also powers Credential Guard, so both belong in the same hardware-readiness project.