How to Configure Hyper-V Key Storage Drives and Virtual Machine Shielding in Windows 11 Using PowerShell

Protecting sensitive virtual workloads from host administrators, rogue hypervisor processes, and unauthorized offline disk inspection requires robust cryptographic separation. While modern Generation 2 virtual machines utilize virtual Trusted Platform Modules (vTPM) to enable BitLocker encryption, certain specialized configurations, legacy Generation 1 operating systems, and isolated test appliances cannot provision a hardware TPM chip. To bridge this cryptographic gap, Microsoft Hyper-V provides the Key Storage Drive (KSD). A Key Storage Drive functions as an encrypted virtual floppy or auxiliary drive that securely stores BitLocker boot keys outside the primary operating system volume. In Windows 11, administrators can configure Key Storage Drives and manage virtual machine shielding policies using PowerShell.

Understanding Hyper-V Key Storage Drives and VM Shielding

Hyper-V supports two primary encryption patterns for virtualized machines:

• Virtual TPM (vTPM): Emulates an industry-standard TPM 2.0 device attached to the virtual machine motherboard. Required for Windows 11 guests and native Generation 2 UEFI virtual machines.
• Key Storage Drive (KSD): Attaches an encrypted virtual auxiliary drive (an isolated 42 MB system-managed volume) to IDE Controller 1 on Generation 1 virtual machines, or an emulated auxiliary storage port. BitLocker stores the Volume Master Key (VMK) on this dedicated drive, allowing the guest OS to unlock and boot without prompting the user for a manual pre-boot startup PIN.
• Virtual Machine Shielding (Host Guardian Service integration): Locks down the VM configuration file, disables Live Migration plain-text transit, blocks guest console inspection via VMConnect, and enforces runtime state encryption.

Configuring Hyper-V Key Storage Drive Prerequisites

To provision Key Storage Drives, open PowerShell with Administrator privileges. Verify that the Hyper-V module is loaded and that the host machine supports virtualization security:

# Verify Hyper-V PowerShell module
Get-Module -Name Hyper-V -ListAvailable

# Verify host Virtualisation-Based Security (VBS) state
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus

Creating and Attaching a Key Storage Drive to a Virtual Machine

Shut down the target virtual machine before modifying cryptographic storage hardware. To add a Key Storage Drive, execute Add-VMKeyStorageDrive:

# Target virtual machine name
$VMName = "Secure-Legacy-VM"

# Stop the VM cleanly
Stop-VM -Name $VMName -Force -Confirm:$false

# Attach a Key Storage Drive to the VM
Add-VMKeyStorageDrive -VMName $VMName

# Verify the attached drive
Get-VMKeyStorageDrive -VMName $VMName | Format-List

For Generation 1 virtual machines, the cmdlet automatically provisions an encrypted synthetic storage interface attached to IDEController 1, ControllerLocation 0. This drive is protected by the hypervisor and remains invisible to standard user-space file explorers within the guest operating system.

Configuring VM Security Settings and Encryption Policies

Once the Key Storage Drive is attached, inspect and configure the virtual machine’s underlying security settings using Set-VMSecurity:

# Inspect current VM security attributes
Get-VMSecurity -VMName $VMName | Format-List

# Enable encryption for VM state and migration traffic
Set-VMSecurity -VMName $VMName `
    -EncryptStateAndVmMigrationTraffic $true `
    -KeyProtector (New-VMKeyProtector -LocalHost -VMName $VMName)

The -EncryptStateAndVmMigrationTraffic parameter guarantees that saved state files (.vsv, .bin), checkpoints, and memory dumps written to host storage are encrypted with keys bound to the host DPAPI or Host Guardian Service (HGS).

Enabling BitLocker Inside the Guest Operating System

Start the virtual machine:

Start-VM -Name $VMName

Log in to the guest operating system. Because Generation 1 VMs lack a physical or virtual TPM, configure the Local Group Policy inside the guest to permit BitLocker without a TPM:

1. Launch gpedit.msc inside the guest VM.
2. Navigate to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.
3. Open Require additional authentication at startup, set it to Enabled, and ensure Allow BitLocker without a compatible TPM is checked.
4. Open an elevated PowerShell prompt inside the guest and activate BitLocker:

# Run inside guest operating system
Enable-BitLocker -MountPoint "C:" -StartupKeyProtector -StartupKeyPath "A:\" -UsedSpaceOnly -SkipHardwareTest

BitLocker detects the hypervisor-provided Key Storage Drive (mapped internally to the virtual key drive path) and transparently commits the startup protector.

Removing or Migrating a Key Storage Drive

If upgrading a virtual machine from Generation 1 to Generation 2, or transitioning the workload to native vTPM architecture, decommission the Key Storage Drive:

# Decrypt BitLocker inside guest prior to removal
# Stop the VM on host
Stop-VM -Name $VMName -Force -Confirm:$false

# Remove the Key Storage Drive
Remove-VMKeyStorageDrive -VMName $VMName

# Verify removal
Get-VMKeyStorageDrive -VMName $VMName

Managing Key Storage Drives and VM security policies via PowerShell empowers administrators to maintain stringent data-at-rest encryption standards across both legacy and modern virtualized environments in Windows 11.