Hyper-V Security Guide: Hosts, Shielded VMs, Guarded Fabric

Whoever administers a Hyper-V host can read, copy or change every virtual machine on it, including the domain controllers, unless the VMs are protected from the fabric itself. Hyper-V's management partition is a full Windows Server installation, so it inherits Windows attack paths (stolen admin credentials, remote management, unpatched drivers) and adds its own: VHDX files that can be mounted offline, live migration traffic that is not encrypted by default, and a Hyper-V Administrators group that is effectively host administration. This guide covers how access to Hyper-V works, how to scope its admin roles, the credentials used for live migration and remote management, what to log, the host and VM baseline, and when shielded VMs on a guarded fabric are worth the effort. It is for Windows infrastructure and security teams on Windows Server 2016 to 2025. General virtualisation principles are in the Hypervisor and Virtualisation Security Guide; this page is the Hyper-V implementation.

Key takeaways

Treat Hyper-V hosts that run domain controllers as Tier 0. Host administrators can copy a DC's VHDX and read the AD database offline, so host access must be as tightly held as Domain Admins.
Use the Hyper-V Administrators group, not local Administrators, and keep it small. Microsoft advises not granting VM administrators any rights on the host operating system.
Move live migration to Kerberos constrained delegation. Windows Server 2025 enables Credential Guard by default on domain-joined member servers, which stops CredSSP-based live migration; migration traffic itself is unencrypted, so isolate it.
Generation 2, Secure Boot and a virtual TPM are the baseline for every VM. Shielded VMs add enforcement that fabric admins cannot switch off, at the cost of console and PowerShell Direct access.
Guarded fabric needs TPM 2.0 for real assurance. TPM-trusted attestation checks measured boot and code integrity policy; host key attestation only proves a host holds a key, and admin-trusted attestation is deprecated.

How identity and access work in Hyper-V

Hyper-V has three layers of access, and each needs its own control.

Layer	Who has it	What it grants	Main control
Host operating system	Local Administrators, domain groups nested into them	Everything: VM files, virtual switches, host configuration, credentials in memory	Tiered admin accounts, privileged access workstations, LAPS for the local account
Hyper-V management	Hyper-V Administrators (or Administrators) on the host; System Center VMM or Windows Admin Center roles above it	Create, start, stop, export and reconfigure VMs; attach disks; change networking; console access	Small, named membership; remote management only
Guest operating system	Accounts inside each VM	The workload	Guest hardening; no host rights for VM administrators
Fabric trust (guarded fabric)	Host Guardian Service administrators	Which hosts may start shielded VMs and receive their keys	Separate HGS forest and admin team; TPM-trusted attestation

Remote management uses WinRM (TCP 5985 or 5986) through Hyper-V Manager, PowerShell or Windows Admin Center. Inside a domain, Kerberos handles authentication. Outside a domain, Microsoft's procedure uses CredSSP with Enable-WSManCredSSP, a TrustedHosts entry and the Group Policy setting Allow delegating fresh credentials with NTLM-only server authentication; that delegates reusable credentials to the host, so scope it to one FQDN and prefer domain-joined management.

Admin roles and privileged access

Hyper-V Administrators: a built-in local group that grants complete access to Hyper-V features without full local admin. It is still powerful: a member can export any VM, attach any VHDX to another VM and read it, or connect to the console. Grant it only to named administrators of that host or cluster.
Domain controllers on Hyper-V: a DC's VHDX contains ntds.dit, and offline access to it is the same outcome as credential theft from NTDS (ATT&CK T1003.003). Run virtual DCs on hosts managed only by Tier 0 administrators, or as shielded VMs. See the AD Domain Controller Hardening Guide.
Manage remotely, from a PAW: Microsoft recommends remote management and, where local management is unavoidable, Credential Guard on the host. Do not use the host as a workstation or install unrelated software. See the Privileged Access Workstations Guide.
Local Administrator account: manage it with Windows LAPS so that one host's password does not open every host. See the Local Administrator Password Solution (LAPS) Guide.
Management tools above the host: System Center Virtual Machine Manager, Windows Admin Center and backup products hold their own admin roles and service accounts with host-level rights. Inventory them as Tier 0 or Tier 1 according to what they manage.
Constrained delegation is a Domain Admin task: configuring Kerberos live migration requires Domain Administrators membership in Active Directory, so plan it as a change through your Tier 0 process.

Integrations, API tokens and service accounts

Live migration credentials

Option	How it authenticates	Security notes
CredSSP (default)	Administrator must be signed in to the source host; credentials are delegated	Exposes reusable credentials on hosts; no longer works after upgrade to Windows Server 2025 because Credential Guard is on by default
Kerberos constrained delegation	Host computer accounts trusted to delegate to the destination for cifs and Microsoft Virtual System Migration Service, with "Use any authentication protocol"	No interactive sign-in needed; delegation scoped to named services and hosts; review delegation settings regularly

Set it with Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos, enable migration with Enable-VMMigration, and restrict incoming migrations to a dedicated network with Set-VMMigrationNetwork. Microsoft states that live migration traffic is not encrypted, so isolate it physically or by VLAN and consider IPsec; the SMB performance option can use SMB 3.0, and Microsoft recommends SMB 3.0 encryption for storage migration over untrusted networks.

Other machine identities

Cluster and storage accounts: failover cluster name objects and SMB file share access for VM storage use computer accounts; restrict share and NTFS permissions on VM storage to the Hyper-V hosts and cluster.
Backup service accounts: host-level backup agents can read every VHDX. Give them dedicated accounts, deny interactive logon, and protect the backup repository separately. See the Backup Security and Immutable Backup Guide.
Shielding data files: a .PDK file holds the VM administrator password, the unattend answer file, RDP certificates and domain-join credentials, encrypted so the fabric administrator can use it without reading it. Keep the tenant keys that create PDK files away from the fabric team.
Integration services: PowerShell Direct and data exchange let host admins reach into guests without the network. Shielded VMs block them; on ordinary VMs, disable integration services you do not use.

Logging and detection

Collect host logs centrally; a compromised host can clear its own.

Hyper-V channels: Microsoft-Windows-Hyper-V-VMMS-Admin (VM management service: create, delete, configuration and migration operations) and Microsoft-Windows-Hyper-V-Worker-Admin (per-VM worker process events), plus the Hyper-V high-availability channels on clusters.
Security log: logons to hosts (4624, 4625), changes to Hyper-V Administrators and Administrators membership (4732, 4733), and WinRM sessions (ATT&CK T1021.006 Windows Remote Management) from anything other than PAWs or management servers.
Behaviour to alert on: VM export or checkpoint of a domain controller or other Tier 0 VM; a VHDX attached to a VM it does not belong to; new VMs created outside the provisioning system (attackers use their own VMs to hide, T1564.006 Run Virtual Instance); disabled Secure Boot or removed vTPM; changes to virtual switch or migration network settings.
Ransomware precursors: mass VM shutdown followed by file activity on VM storage is the pattern of hypervisor-level encryption (T1486 Data Encrypted for Impact). See the Ransomware Prevention Guide.
Guarded fabric: monitor HGS attestation failures; a host that suddenly fails attestation has changed its boot chain or code integrity policy.

Metrics

Host admin count: number of accounts with Administrators or Hyper-V Administrators rights per host, trending down.
VM baseline coverage: share of VMs that are Generation 2 with Secure Boot and vTPM enabled.
Tier 0 protection: share of virtual DCs and PKI servers that are shielded or on Tier 0 only hosts.
Migration authentication: share of hosts using Kerberos for live migration on an isolated network.
Patch latency: days from Microsoft release to host deployment, including firmware and drivers.

Hardening baseline

Host

Install the minimum. Use the smallest Windows Server installation option you can manage (Server Core where tools allow), the Hyper-V role only, and no other roles or workstation software. Microsoft does not recommend production workloads on Hyper-V on Windows client.
Apply the Windows Server security baseline and keep the OS, firmware and drivers patched to the hardware vendor's guidance. See the Windows Server Hardening Guide.
Enable VBS-protected code integrity and Credential Guard on hosts, and an application control policy so only approved code runs.
Separate networks: a dedicated management NIC, a private storage network, and a dedicated live migration network restricted in Hyper-V settings.
Encrypt the host volumes with BitLocker and protect the storage where VM files live.
Configure antivirus exclusions correctly: Microsoft Defender adds automatic exclusions for Hyper-V; for other products follow Microsoft's recommended exclusions rather than excluding whole volumes.
Do not mount unknown VHDs on the host, and do not enable nested virtualisation or Discrete Device Assignment in production unless a workload requires it.

Virtual machines

Generation 2 with Secure Boot: template Microsoft Windows for Windows guests, Microsoft UEFI Certificate Authority for Linux guests, Open Source Shielded VM for shielded Linux VMs (Set-VMFirmware -EnableSecureBoot On -SecureBootTemplate).
Virtual TPM: add a key protector and enable the vTPM (Set-VMKeyProtector, Enable-VMTPM) so guests can use BitLocker and VBS. A vTPM VM moved to a new host may not start until its key protector authorises that host.
Encrypt state and migration traffic for VMs with a vTPM (Set-VMSecurity -EncryptStateAndVmMigrationTraffic $true).
Network: connect each adapter to the right virtual switch and use port-level protections such as DHCP guard and router guard on tenant-facing VMs.
Guest hardening: patch before first production boot, keep integration services current, and enable VBS in Windows guests.

Choosing a protection level

VM type	Protects against	Fabric admin keeps	Use when
Generation 2 with Secure Boot and vTPM	Boot-level malware; offline disk theft if the guest uses BitLocker	Console, PowerShell Direct, debugger, configuration changes	Every VM by default
Encryption-supported (guarded fabric)	Disk and state theft at rest and in migration	Console and management features; protections can be reconfigured	Fabric administrators are fully trusted but compliance requires encryption
Shielded	Malicious or compromised fabric administrators and host malware	Start, stop, migrate, replica, checkpoints only; COM ports and debuggers blocked; data exchange and PowerShell Direct blocked	Domain controllers, PKI, HSM front ends, hosted tenants, any VM whose admins must not be the host admins

A small organisation with a single Hyper-V cluster usually gets more from strict host access, Gen 2 plus vTPM everywhere and DCs on a separately administered host than from a full guarded fabric. A full fabric, with a three-node HGS cluster in its own forest and TPM-trusted attestation, suits hosting providers and large estates that must separate fabric and workload administration. Shielded VMs can also run locally without HGS for testing, but that does not give attestation.

Framework mapping

Framework	Reference	Applies to
NIST SP 800-53 Rev. 5	AC-2, AC-6, CM-7, SC-7, SC-8, SC-28, SC-39 Process Isolation, SI-7, AU-12	Host admin scoping, minimal host, network separation, migration and at-rest encryption, VM isolation, integrity, logging
NIST CSF 2.0	PR.AA-05, PR.PS-01, DE.CM-09	Access policy, configuration baseline, host and VM monitoring
CIS Controls v8.1	4.1 Secure Configuration Process; 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts; 12.2 Secure Network Architecture	Host baseline, admin accounts, separated management and migration networks
MITRE ATT&CK	T1003.003 NTDS; T1021.006 Windows Remote Management; T1564.006 Run Virtual Instance; T1486 Data Encrypted for Impact	Offline DC disk access, remote host administration, rogue VMs, hypervisor-level ransomware

Common misconfigurations

Domain controllers on hosts run by the server team. Anyone with Hyper-V Administrators on that host can take a copy of the DC disk, so Tier 0 extends to every host administrator, backup operator and management tool.
Hosts joined to the domain they host, with no separate admin path. When AD is down or compromised, the host credentials are too; keep a documented break-glass path and LAPS-managed local accounts.
CredSSP everywhere. Teams keep CredSSP for live migration and remote management, leaving delegated credentials on hosts, then find migrations failing after moving to Windows Server 2025.
Migration on the production network. VM memory, including secrets in guest memory, crosses the network in clear when migration is not isolated or encrypted.
Generation 1 VMs carried forward. Old VMs without Secure Boot or vTPM cannot use BitLocker with a TPM or VBS, and they stay that way unless rebuilt.
Host key attestation treated as TPM attestation. Host key mode proves only possession of a key; it does not check what booted. Use TPM-trusted attestation for high-value fabrics.

Practitioner checklist

Classify every Hyper-V host by the most sensitive VM it runs, and manage DC hosts as Tier 0.
Limit Administrators and Hyper-V Administrators to named accounts and alert on membership change.
Manage hosts remotely from PAWs; enable Credential Guard and VBS-protected code integrity on hosts.
Switch live migration to Kerberos constrained delegation on a dedicated, restricted network.
Build every new VM as Generation 2 with Secure Boot, a vTPM and encrypted state and migration traffic.
Shield DCs, PKI and other Tier 0 VMs, or isolate them on separately administered hosts.
Forward Hyper-V VMMS, Worker and Security logs to the SIEM and alert on export, disk attachment and VM creation outside provisioning.
Apply the Windows Server baseline, patch firmware and drivers, and keep host software to the Hyper-V role only.
Protect VM storage and backups with permissions limited to hosts and dedicated backup identities.

Hyper-V Security Guide: Host Hardening, Shielded VMs and Guarded Fabric