What Are Shielded VMs and Why They Exist

Shielded Virtual Machines are a Windows Server 2016+ security feature that protects virtual machine data and state from access by Hyper-V administrators, backup operators, and anyone else with physical or software-level access to the virtualization fabric. In a conventional Hyper-V environment, a fabric administrator — someone with access to the Hyper-V host — can take a snapshot of a running VM, mount the VHDX directly, or examine memory to extract secrets. Shielded VMs encrypt the VM’s VHDX with BitLocker and use a secure boot chain to ensure the VM will only start on hosts that have been cryptographically attested as trustworthy.

The threat model Shielded VMs address is the insider threat at the virtualization layer: a rogue admin, a compromised management plane, or a hypervisor exploit. The VM owner (tenant) remains in full control of the VM’s contents; the fabric administrator can see that the VM exists and can allocate resources to it, but cannot inspect its data, inject code, or extract credentials from it.

On Windows Server 2022, Shielded VMs remain a first-class feature and are particularly relevant for:

Multi-tenant hosting environments where VMs belonging to different customers run on shared hardware. Regulated workloads (PCI DSS, HIPAA) that require assurance the hypervisor layer cannot read VM memory. High-security government and financial environments implementing separation of duties between the virtualization team and the security/compliance team.

Host Guardian Service Architecture

The Host Guardian Service (HGS) is the core infrastructure component that makes Shielded VMs possible. HGS is a separate Windows Server role — typically deployed on its own dedicated cluster, completely isolated from the production Hyper-V fabric — that performs two functions:

Attestation — HGS verifies that a Hyper-V host is in a known-good, trustworthy state before allowing it to run shielded VMs. HGS supports two attestation modes: TPM-trusted attestation (production-grade, uses TPM 2.0 measurements) and Host Key attestation (simplified mode for development/testing, uses pre-registered host keys).

Key Protection — HGS holds the Key Protector for each shielded VM. The Key Protector is an encrypted blob containing the BitLocker key needed to unlock the VM’s VHDX. HGS releases this key only to Hyper-V hosts that successfully pass attestation.

HGS should be deployed as a 3-node cluster on hardware not managed by the same team that manages the Hyper-V fabric. This physical and administrative separation is what creates the security boundary.

Installing the Host Guardian Service Role

Begin by installing HGS on a dedicated server that will become the first node of the HGS cluster. This server should be domain-joined to a new, separate HGS domain — not the same domain as the Hyper-V hosts.

# Install the HGS role (on the designated HGS server)
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

After reboot, initialize the HGS server. This creates the HGS-specific AD domain and configures the HGS cluster. The HgsServiceName becomes the DNS name clients use to reach HGS:

$adminCred = Get-Credential -Message "Enter HGS administrator password"

Initialize-HgsServer `
    -HgsServiceName "hgs" `
    -Http `
    -Https `
    -HttpPort 80 `
    -HttpsPort 443 `
    -TrustActiveDirectory `
    -SafeModeAdministratorPassword $adminCred.Password

The -TrustActiveDirectory flag enables AD-trusted attestation mode, which is easier to set up but less secure than TPM attestation. For production, use -TrustTpm instead:

Initialize-HgsServer `
    -HgsServiceName "hgs" `
    -Http `
    -Https `
    -TrustTpm `
    -SafeModeAdministratorPassword $adminCred.Password

Verify HGS is running:

Get-HgsServer

Configuring TPM-Trusted Attestation

TPM-trusted attestation is the production-grade mode that uses TPM 2.0 measurements from the Hyper-V host’s boot chain to prove the host is in a known-good state. HGS collects a reference measurement (the TCG log and TPM quote) from a known-good host and stores it as a baseline. Any host presenting measurements that deviate from the baseline — indicating a bootkit, modified kernel, or tampered hypervisor — will fail attestation and will not receive VM keys.

On a known-good, fully patched Hyper-V host, capture the TPM baseline:

# Run on the reference Hyper-V host (must have TPM 2.0 and Secure Boot enabled)
Get-HgsClientConfiguration

# Export the CI policy (Code Integrity policy) for the host
New-CIPolicy -Level FilePublisher -FilePath C:CIPolicy.xml -UserPEs

# Convert to binary format
ConvertFrom-CIPolicy -XmlFilePath C:CIPolicy.xml -BinaryFilePath C:SIPolicy.p7b

# Enable the CI policy
Copy-Item C:SIPolicy.p7b -Destination "C:WindowsSystem32CodeIntegritySIPolicy.p7b"

Capture the TPM attestation data from the reference host and register it with HGS:

# On the reference Hyper-V host — get the EK certificate and TPM identifier
$ekCert = Get-PlatformIdentifier -Name "ReferenceHost01"

# On HGS server — register the host
Add-HgsAttestationTpmHost -Name "HyperVHost01" -Path "\HyperVHost01c$EKCert.xml" -Force

# Register the CI policy with HGS
Add-HgsAttestationCiPolicy -Name "ProductionCIPolicy" -Path "\HyperVHost01c$SIPolicy.p7b"

# Register the TCG log baseline
Add-HgsAttestationTpmPolicy -Name "ProductionBaseline" -Path "\HyperVHost01c$TcgLog.xml"

Creating a Shielded VM Template with Convert-WindowsImage

A shielded VM template is a generalized VHDX that has been prepared with Sysprep and optionally converted to use generation 2 (UEFI + Secure Boot). The template is the base disk that gets a unique copy per VM deployment, with the copy’s VHDX sealed by BitLocker.

First, create a generation 2 Windows VM template disk using the Windows VHDX conversion tool:

# Convert Windows Server 2022 ISO to VHDX template
# Requires the WindowsImageTools or manual DISM approach
$isoPath  = "D:ISOsWindowsServer2022.iso"
$vhdxPath = "C:TemplatesWS2022-Template.vhdx"

# Mount ISO and find install.wim
Mount-DiskImage -ImagePath $isoPath
$driveLetter = (Get-DiskImage -ImagePath $isoPath | Get-Volume).DriveLetter
$wimPath = "${driveLetter}:sourcesinstall.wim"

# Create VHDX and apply WIM
$vhd = New-VHD -Path $vhdxPath -SizeBytes 60GB -Dynamic
Mount-VHD -Path $vhdxPath
$vhdDisk = (Mount-VHD -Path $vhdxPath -Passthru | Get-Disk)
Initialize-Disk -Number $vhdDisk.Number -PartitionStyle GPT -PassThru |
    New-Partition -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel "OSDisk" -Confirm:$false

# Apply Windows image to VHDX (index 4 = Windows Server 2022 Datacenter)
$partition = Get-Partition -DiskNumber $vhdDisk.Number | Where-Object Type -eq Basic
Expand-WindowsImage -ApplyPath "$($partition.DriveLetter):" -ImagePath $wimPath -Index 4

# Add boot files and Dismount
bcdboot "$($partition.DriveLetter):Windows" /s $($partition.DriveLetter): /f UEFI
Dismount-VHD -Path $vhdxPath
Dismount-DiskImage -ImagePath $isoPath

Generalize the template VM before sealing it:

# Start a VM from the template VHDX, configure it, install agents, then run:
& "C:WindowsSystem32Sysprepsysprep.exe" /oobe /generalize /shutdown

Creating the Shielding Data File (.pdk)

The Shielding Data File (also called the PDK file or provisioning data key) is a package created by the VM owner (tenant) that contains the secrets needed to configure a shielded VM at deployment time. It contains:

The VM owner’s key protector (which HGS will seal the BitLocker key against), the Administrator password for the VM, optional unattend.xml for automated OOBE configuration, and optional RDP certificate to trust at first connection.

# Create shielding data file using HVPM (Hyper-V Provisioning Manager) tools
# Requires the ShieldedVMTools feature on the management machine
Install-WindowsFeature -Name RSAT-Shielded-VM-Tools

# Generate a new owner key
$ownerCert = New-SelfSignedCertificate `
    -Subject "CN=ShieldedVMOwner" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -KeyUsage KeyEncipherment,DataEncipherment `
    -Type DocumentEncryptionCert

# Get the guardian metadata from HGS
$hgsUrl = "https://hgs.corp.example.com"
$guardian = Get-HgsGuardian -Name "Corp-HGS"

# Import HGS guardian metadata if not cached
# Import-HgsGuardian -Path "C:HGSGuardian.xml" -Name "Corp-HGS"

# Create Key Protector for the VM
$kp = New-HgsKeyProtector -Owner $ownerCert -Guardian $guardian -AllowUntrustedRoot

# Create the shielding data file
$adminCred = Get-Credential -Message "Enter local admin password for shielded VM"
New-ShieldingDataFile `
    -ShieldingDataFilePath "C:PDKProductionVM.pdk" `
    -Owner $ownerCert `
    -Guardian $guardian `
    -VolumeIDQualifier (New-VolumeIDQualifier -VolumeTag "OS" -CompareTo Signature) `
    -AnswerFile "C:PDKunattend.xml" `
    -RootCertificate $ownerCert `
    -Policy Shielded

Deploying a Shielded VM on a Guarded Host

With the template VHDX and PDK file ready, deploy a shielded VM through VMM (Virtual Machine Manager) or via PowerShell on a guarded Hyper-V host. The host must successfully attest to HGS before the deployment will succeed.

Configure the Hyper-V host as a guarded host by pointing it at HGS:

# On the Hyper-V host
Set-HgsClientConfiguration `
    -AttestationServerUrl "https://hgs.corp.example.com/Attestation" `
    -KeyProtectionServerUrl "https://hgs.corp.example.com/KeyProtection"

# Verify attestation
Get-HgsClientConfiguration

The output should show IsHostGuarded: True and AttestationStatus: Passed. If attestation fails, review the HGS event log at Applications and Services LogsMicrosoftWindowsHostGuardianService.

Deploy the shielded VM using the New-ShieldedVM cmdlet or through VMM provisioning:

# Create a new shielded VM from template and PDK
New-VM -Name "ShieldedProd01" `
    -Generation 2 `
    -MemoryStartupBytes 4GB `
    -NewVHDPath "C:VMsShieldedProd01.vhdx" `
    -NewVHDSizeBytes 60GB `
    -SwitchName "Production"

# Configure Secure Boot and TPM (required for shielded VMs)
Set-VMFirmware -VMName "ShieldedProd01" `
    -SecureBootTemplate MicrosoftWindows `
    -EnableSecureBoot On

Add-VMTPM -VMName "ShieldedProd01"

# Apply shielding data
Initialize-ShieldedVM `
    -TemplateDiskPath "C:TemplatesWS2022-Template.vhdx" `
    -ShieldingDataFilePath "C:PDKProductionVM.pdk" `
    -VmName "ShieldedProd01"

BitLocker Integration in Shielded VMs

BitLocker encryption of the OS and data volumes inside a shielded VM is transparent to the VM operator. The virtual TPM (vTPM) provided by Hyper-V serves as the BitLocker key protector inside the VM. The VM’s BitLocker keys are sealed to the vTPM, which itself is protected by the Key Protector managed by HGS. This creates a chain: VM data is encrypted by BitLocker, BitLocker keys are sealed to vTPM, vTPM is unlockable only by a host that passes HGS attestation.

Verify BitLocker status inside a shielded VM:

# Run inside the shielded VM
manage-bde -status C:
manage-bde -protectors -get C:

The protector type should show TPM, confirming that the vTPM is the key protector.

Shielded VMs and Live Migration

Shielded VMs can live-migrate between guarded Hyper-V hosts, but only if the destination host passes HGS attestation. During live migration, the VM’s memory (including the decrypted BitLocker keys in the vTPM) is transferred over the network. This transfer should be protected by an SMB encryption or Kerberos-constrained delegation, and it is automatically encrypted at the VM level by Hyper-V’s secure migration protocol for shielded VMs.

If the destination host fails attestation, the live migration is refused. This is intentional: it prevents migrating a shielded VM to a compromised host that might inspect its memory mid-migration.

# Test if a target host can receive a shielded VM migration
$sourceHost = "hvhost01.corp.example.com"
$destHost   = "hvhost02.corp.example.com"

# Check HGS attestation on destination
Invoke-Command -ComputerName $destHost -ScriptBlock {
    Get-HgsClientConfiguration
}

# Initiate live migration (will fail if destHost is not guarded)
Move-VM -Name "ShieldedProd01" `
    -ComputerName $sourceHost `
    -DestinationHost $destHost `
    -DestinationStoragePath "C:VMs"

Monitoring HGS Health

HGS health is critical — if HGS becomes unavailable, guarded hosts cannot attest and shielded VMs cannot start or migrate. Monitor HGS proactively:

# Check HGS service status
Get-Service HgsSvc, HgsKeyProtSvc -ComputerName hgs01.priv.example.com

# Check attestation health endpoint
Invoke-WebRequest -Uri "https://hgs.corp.example.com/Attestation/service/healthcheck" -UseDefaultCredentials

# View recent attestation events on HGS
Get-WinEvent -ComputerName hgs01 `
    -LogName "Microsoft-Windows-HostGuardianService-Attestation/Operational" |
    Select-Object -First 20 TimeCreated, Id, Message | Format-List

# Get overview of registered TPM hosts and policies
Get-HgsAttestationTpmHost | Select-Object Name, Enabled
Get-HgsAttestationCiPolicy | Select-Object Name, Enabled
Get-HgsAttestationTpmPolicy | Select-Object Name, Enabled

Deploy HGS as a 3-node cluster with a file share witness or cloud witness to ensure it survives a single-node failure. Because HGS is in the critical path for shielded VM boot, its availability directly impacts your RTO for protected workloads.

Summary

Hyper-V Shielded VMs on Windows Server 2022 provide a cryptographically enforced boundary between VM owners and fabric administrators. By deploying Host Guardian Service with TPM-trusted attestation, creating VM templates with sealed Shielding Data Files, and ensuring all Hyper-V hosts are properly guarded, you can run sensitive workloads on shared Hyper-V infrastructure with confidence that the virtualization layer cannot be used as an attack vector against VM data — even by the administrators who manage the physical hosts.

Links

Newsletter

Contact

How to Configure Hyper-V Shielded VMs on Windows Server 2022