Design shielded-VM key recovery before protecting the fabric from its admins

Bottom line: Hyper-V shielded VMs are designed to protect a VM from a compromised fabric and fabric administrator. Host Guardian Service (HGS) attests guarded hosts and releases protected keys to approved healthy hosts. The same boundary that blocks unauthorized inspection can also block recovery if HGS, guardian keys, owner keys, and the disaster-recovery fabric are not designed and tested.

Source fact: what Microsoft documents

Microsoft’s guarded fabric and shielded VM overview describes a guarded fabric as HGS, one or more guarded Hyper-V hosts, and shielded VMs. HGS provides attestation and key-protection services so a shielded VM can start or live-migrate only on a host that is authorized and has successfully attested.

Microsoft distinguishes regular, encryption-supported, and shielded virtual machines. Shielded VMs are generation 2 VMs with a virtual TPM and BitLocker protection and restrict fabric-administrator capabilities, including PowerShell Direct and specified integration components. The source is internally inconsistent on console access: its narrative says shielded VMs never permit a VM console connection, while its current comparison table says console and HID are enabled on hosts beginning with Windows Server version 1803 and disabled on earlier hosts. Shielding data contains sensitive provisioning information and a key protector identifying authorized guardian fabrics. Microsoft’s tenant planning guide separately describes owner keys as a last-resort recovery mechanism and supports authorizing primary and disaster-recovery fabrics.

What the source does not establish

Shielding does not secure an unpatched guest, prevent misuse by a valid guest administrator, guarantee HGS availability, or replace backup and application recovery. Encryption-supported VMs do not provide the same fabric-admin boundary as fully shielded VMs. Possession of a recovery key can weaken separation if it is poorly controlled, while loss of required keys can make a protected VM unavailable.

Applicability questions

• Is the threat model a malicious or compromised fabric administrator, host malware, stolen VHDX, or an at-rest requirement only?
• Which workloads can operate within the documented console, PowerShell Direct, and integration-component restrictions for the deployed host version?
• Who administers HGS, guarded hosts, guest OS, owner keys, and recovery, and are those roles separated?
• Which primary and DR fabrics must be authorized, and how are guardian keys protected and restored?
• Can backup, replication, monitoring, support, and incident response operate within the shielded boundary?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Write the threat model and choose shielded versus encryption-supported VMs deliberately; do not treat the terms as equivalent.
2. Separate HGS administration from fabric administration and protect owner and guardian keys under dual-controlled recovery procedures.
3. Build the primary and DR authorization model before production shielding. Preserve offline recovery material according to an approved key-management standard.
4. Pilot workload deployment, patching, backup, monitoring, guest administration, host attestation failure, HGS outage, migration, and DR start.
5. Exercise recovery without granting fabric administrators an undocumented bypass.

Verification and evidence

• Preserve HGS topology, attestation mode, guardian authorization, shielding-data provenance, role separation, and approvals.
• Record successful and denied VM starts on approved, unhealthy, and unauthorized hosts in a safe test.
• Demonstrate owner-key custody and recovery through an approved exercise without exposing key material in the report.
• Verify application function, backup, restore, and DR from the guest and client perspective.

Official references

• Guarded Fabric and Shielded VMs overview — Microsoft
• Shielded VM planning guide for tenants — Microsoft