{"id":922,"date":"2026-10-24T22:37:54","date_gmt":"2026-10-24T22:37:54","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=922"},"modified":"2026-10-24T22:37:54","modified_gmt":"2026-10-24T22:37:54","slug":"bitlocker-vps-without-tpm-key-protectors-recovery","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/bitlocker-vps-without-tpm-key-protectors-recovery\/","title":{"rendered":"BitLocker on a VPS Without a TPM: Key Protectors and Recovery Escrow"},"content":{"rendered":"

Run Get-Tpm<\/code> on most rented Windows Server instances and you get TpmPresent : False<\/code>. No firmware TPM, no vTPM, no PCR banks. BitLocker still works on that machine — but the default wizard path will fail with “This device can’t use a Trusted Platform Module”, and the recovery-key model changes from automatic unsealing to something you have to operate deliberately.<\/p>\n\n

What a vTPM gives you that a virtual disk does not<\/h2>\n\n

With a TPM, BitLocker seals the volume master key to PCR 7 (Secure Boot state) and PCR 11 (BitLocker access control), and unsealing happens in firmware, so the key never sits in a file the guest can read. Without a TPM that seal has nowhere to live, and BitLocker must fall back to a startup key on external media, a numeric password typed at boot, or network unlock.<\/p>\n\n

BitLocker without a TPM protects data at rest — a VHDX snapshot, a stolen backup, a decommissioned node — but not against a compromised hypervisor, which can read key material from guest memory. Say that plainly before enabling it.<\/p>\n\n

Check what the platform exposes before designing anything:<\/p>\n\n

Get-Tpm | Format-List TpmPresent,TpmReady,ManufacturerIdTxt\nGet-CimInstance -Namespace root\/cimv2\/security\/microsoftvolumeencryption `\n  -ClassName Win32_EncryptableVolume | Format-List DriveLetter,ProtectionStatus,ConversionStatus\nmanage-bde -status C:<\/code><\/pre>\n\n
If TpmPresent<\/code> is False but TpmReady<\/code> is True, a vTPM exists and only needs Initialize-Tpm -AllowClear -AllowPhysicalPresence<\/code>. On Hyper-V Gen 2 VMs the vTPM is a hosting-side setting that is rarely available on a rented instance.<\/p>\n\n
Startup key versus numeric password<\/h2>\n\n
Protector<\/th>add command<\/th>Where the secret lives<\/th>Unattended boot<\/th><\/tr><\/thead>
TPM<\/td>Add-BitLockerKeyProtector -TpmProtector<\/td>Firmware, sealed to PCRs<\/td>Yes<\/td><\/tr>
TPM + PIN<\/td>Add-BitLockerKeyProtector -TpmAndPinProtector<\/td>Firmware plus typed PIN<\/td>No<\/td><\/tr>
Startup key<\/td>Add-BitLockerKeyProtector -StartupKeyProtector<\/td>USB or virtual floppy (.BEK)<\/td>With medium attached<\/td><\/tr>
Numeric password<\/td>Add-BitLockerKeyProtector -PasswordProtector<\/td>Operator memory<\/td>No<\/td><\/tr>
Recovery password<\/td>Add-BitLockerKeyProtector -RecoveryPasswordProtector<\/td>AD DS \/ Entra ID \/ escrow file<\/td>Recovery only<\/td><\/tr>
Network unlock<\/td>Enable-BitLocker … -NetworkUnlock<\/td>WDS server certificate<\/td>Yes (with WDS)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n
The startup key protector writes a 32-byte key to a .BEK<\/code> file that must live on a volume BitLocker does not manage — on a VPS, a separate virtual disk or a read-only virtual floppy. Storing the .BEK<\/code> on the same VHDX as the encrypted OS is the most common mistake in this configuration.<\/p>\n\n
The numeric password is the pragmatic choice for a single rented instance, typed through the pre-boot environment. It is a low-entropy secret — never the only barrier in front of a public RDP endpoint.<\/p>\n\n
Enabling encryption on an OS volume without a TPM<\/h2>\n\n
On a TPM-less machine the setup wizard refuses. Use PowerShell instead: -SkipHardwareTest<\/code> is required for a password protector on a virtual machine, otherwise the cmdlet demands a reboot-based hardware test a VPS console cannot complete.<\/p>\n\n
# 1. Confirm the recovery password is escrowed before anything else\n$rp = (Get-BitLockerVolume -MountPoint C:).KeyProtector |\n      Where-Object KeyProtectorType -eq 'RecoveryPassword'\nif (-not $rp) { Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector }\n\n# 2. Add a numeric password protector and start full encryption\nAdd-BitLockerKeyProtector -MountPoint C: -PasswordProtector\nEnable-BitLocker -MountPoint C: -EncryptionMethod XtsAes256 `\n  -UsedSpaceOnly -SkipHardwareTest\n\n# 3. Watch conversion progress\nwhile ((Get-BitLockerVolume -MountPoint C:).VolumeStatus -ne 'FullyEncrypted') {\n  Start-Sleep 60\n  (Get-BitLockerVolume -MountPoint C:).EncryptionPercentage\n}<\/code><\/pre>\n\n
-UsedSpaceOnly<\/code> encrypts only allocated clusters and finishes in minutes on a mostly empty volume, which suits fresh deployments. On a volume that previously held sensitive data, follow up with manage-bde -wipefreespace<\/code> so free space is not left in plaintext.<\/p>\n\n
XTS-AES 256-bit is the only method worth choosing on Server 2022 and later; AES-CBC with an elephant diffuser exists for Server 2008-era compatibility. Changing the method later requires a full decrypt\/re-encrypt cycle.<\/p>\n\n
Encryption costs CPU. On the software cipher path (no TPM, and often no AES-NI passthrough on virtualised hardware) expect 15 to 30 percent throughput loss on sequential writes. A quick winsat disk -drive c<\/code> before and after encryption quantifies it for your specific host, and is worth running on any Windows Server instance<\/a> before you commit a database workload to an encrypted volume.<\/p>\n\n
Escrow: the recovery password is the whole game<\/h2>\n\n
A recovery password is 48 digits in eight groups of six. Lose it and the volume is unrecoverable — there is no backdoor. It must exist and be stored somewhere other than the server it protects:<\/p>\n\n