The recovery USB tricks (Utilman and Sticky Keys) work because the OS volume is plaintext. Enable BitLocker and that whole class of physical-access attack stops. The downside: now you have to keep the recovery key safe, and a corrupted boot config can lock you out for real.

Worth it. Do it on every server with a non-trivial threat model. Don't skip it on Server because "it's in a datacenter" — datacenters get audited, drives get RMA'd, racks get visited.

TL;DR — encrypt C:\ with TPM unlock:

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 `
  -UsedSpaceOnly -TpmProtector
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
manage-bde -protectors -get C:  # ← copy the recovery key OUT OF BAND now
Resume-BitLocker -MountPoint "C:"

Reboot, encryption runs in the background, the box stays usable.

Server-specific quirks

BitLocker on Windows Server is the same engine as on Windows 11, but a few things differ:

  • Feature install required. On Windows 11, BitLocker is built in. On Server, it's an optional feature you have to install first.
  • No GUI nag. Server doesn't pop the BitLocker setup wizard at first login. You enable explicitly.
  • VMs need a virtual TPM. Hyper-V Gen 2, VMware with vTPM enabled, Proxmox with --tpmstate0 configured. Without a vTPM, you can BitLocker but unlock requires manual recovery password entry every boot — useless for headless.
  • Server Core works fine. Same PowerShell, no GUI either way.

Pre-flight

Confirm a TPM is present and ready:

Get-Tpm

You want TpmPresent: True and TpmReady: True. If TpmEnabled: False, enable it in BIOS/UEFI first, then reboot.

If TpmReady: False but Present: True, run:

Initialize-Tpm -AllowClear -AllowPhysicalPresence

Some setups need a reboot after.

For VMs: confirm the hypervisor exposes a vTPM. On Hyper-V:

Get-VMSecurity -VMName MyServer | Select TpmEnabled

True required.

Install BitLocker feature

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart

-Restart reboots when finished. Schedule accordingly.

Enable encryption

After the reboot:

Enable-BitLocker -MountPoint "C:" `
  -EncryptionMethod XtsAes256 `
  -UsedSpaceOnly `
  -TpmProtector

Field-by-field:

  • XtsAes256 — modern cipher, no reason to use anything else on a 2018+ box.
  • -UsedSpaceOnly — encrypts only blocks currently in use. Fast (minutes vs hours). New writes auto-encrypt. Slightly less paranoid than full-volume encryption (deleted-but-not-overwritten data on the disk before BitLocker existed isn't covered), but on a fresh server it's identical.
  • -TpmProtector — unlock automatically on boot if the TPM, boot config, and disk all match what was provisioned. This is what makes a headless server usable.

Add a recovery password — DO NOT SKIP

Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

This generates a 48-digit recovery key. Now print it:

manage-bde -protectors -get C:

You'll see something like:

Numerical Password:
  ID: {12345678-1234-1234-1234-123456789012}
  Password:
    123456-234567-345678-456789-567890-678901-789012-890123

Copy it somewhere physical access to this box can't reach. A password manager (1Password, Bitwarden), a printout in a safe, both. Not on the same box. Not in an email folder accessible from this box.

If you lose this and TPM unlock fails (BIOS update, TPM clear, motherboard swap), the encrypted disk is unrecoverable. The recovery key is the entire ladder back in.

Resume — encryption starts

After enabling, BitLocker is in a "suspended" state until you confirm:

Resume-BitLocker -MountPoint "C:"

Or check status:

Get-BitLockerVolume -MountPoint "C:"

ProtectionStatus: On means it's actively protecting. EncryptionPercentage ticks up; the box stays fully usable during encryption.

What if TPM unlock fails

Most common causes, in rough order:

  1. BIOS/UEFI update. TPM measurements changed; BitLocker doesn't trust the new boot config.
  2. TPM clear (someone reset CMOS / cleared TPM via BIOS).
  3. Disk moved to different hardware. New TPM, no match.
  4. Boot config changed (e.g. you booted from a recovery USB and Windows updated boot files).

You see this at boot — instead of unlocking, you get a prompt:

BitLocker recovery
Enter the recovery key
Recovery key ID: 12345678-1234-...

Match the ID to your saved key, type the 48 digits. Boot proceeds.

After getting back in, re-arm the TPM protector:

manage-bde -protectors -delete C: -type TPM
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:

This re-bakes the current boot config into the TPM protector. Next reboot is automatic again.

Suspending for maintenance

Before a BIOS update or major hardware change:

Suspend-BitLocker -MountPoint "C:"

This temporarily disables TPM unlock — the disk stays encrypted, but boots without checking TPM measurements. Do the BIOS update, reboot, confirm Windows comes up, then:

Resume-BitLocker -MountPoint "C:"

Skip this and you'll be typing 48-digit recovery keys after every BIOS update.

What this combines with

BitLocker is the wall. The hardening posts are the locks. Both, on every server.

Gotchas

  • Don't enable on a server you can't physically access. If TPM unlock fails, you need recovery key entry at the console. Remote KVM works; pure SSH doesn't (boot prompt is pre-OS).
  • Some hosters disable vTPM by default. Check before provisioning. Hetzner Cloud, OVH, AWS EC2 — vTPM availability varies. If no vTPM, you can still encrypt but lose automatic unlock.
  • TPM lockout. If the recovery password is entered wrong N times, the TPM locks for hours. Don't fat-finger it. Copy-paste from your password manager.
  • Server rebuilds: re-enroll the TPM. Restoring a backup or VM-cloning copies the encrypted disk but not the TPM state. The clone needs its own BitLocker setup — the recovery key from the original gets you in, but you should re-provision protectors from scratch.
  • Boot from recovery media to manage from outside Windows: in WinPE, manage-bde -unlock C: -RecoveryPassword 123456-... decrypts the volume for that session. Useful for offline repair without losing encryption.

Performance

XtsAes256 on a 2018+ Xeon costs about 1-3% disk throughput. AES-NI hardware acceleration makes it nearly free. For database servers I've measured zero observable impact on read-heavy workloads, ~2% on heavy writes. Worth every percentage point for the threat reduction.

If you're sensitive — measure before and after with your actual workload. Don't optimize on rumors.

Related posts