Encrypting a virtual disk protects data at rest. It does not, by itself, stop a compromised virtualization administrator from starting the VM and inspecting its memory or virtual devices. Hyper-V shielded VMs address a different threat: the virtualization fabric itself. The design depends on a virtual TPM, an approved host, and a key protector that authorizes where the VM can run.
The components that must agree
Microsoft describes a shielded VM as a generation 2 VM with a virtual TPM, BitLocker encryption, and a restriction that it run only on healthy, approved hosts. A guarded fabric combines the Host Guardian Service, guarded Hyper-V hosts, and the shielded VMs. HGS provides attestation and key protection.
Attestation decides whether a host is trustworthy enough to receive keys. Key protection releases the keys needed to start or live migrate the VM. A key protector defines the fabric authorized to run it. If a host is replaced, rebuilt, or moved to another fabric, the protector may need to be updated before the VM can start.
This makes the key protector an operational object. It is not a one-time encryption toggle. The team that owns the VM and the team that owns the fabric need a shared process for adding authorized hosts, retiring old ones, and validating recovery.
TPM attestation is stronger, but it is not automatic
HGS supports TPM-trusted attestation and host key attestation. TPM-trusted mode uses the host's TPM identity, measured boot sequence, and code integrity policy. It requires TPM 2.0 and appropriate UEFI and Secure Boot support. Host key attestation is available when that hardware assurance is not present, but it provides a different level of assurance.
An organization should document the selected mode and the reason. A migration plan that changes hardware must include the attestation impact. Moving from host key mode to TPM mode is a fabric change, not a silent improvement.
Build a recovery drill
Record the key protector configuration, HGS trust material, VM generation, vTPM state, backup process, and responsible custodians. Test the full path: attest a host, release the key, start the VM, migrate it to another authorized host, and recover it after a planned failure. Confirm that an unauthorized host is rejected and that the error is visible to operations.
Protect HGS administrator access as a high-value control. The service releases decryption keys, so a broad administrative role can undermine the boundary even when every VM is correctly configured. Separate fabric administration from VM ownership where possible and audit changes to attestation policy and key protector metadata.
Do not describe disk encryption alone as shielding. The security claim depends on the host trust decision, the key release path, the VM policy, and the recovery process working together. Include all four in assurance reviews.