Hyper-V AF_HYPERV permissions and service isolation for VMMS-managed VMs

Hello Fengchun,

Thank you for posting your question on Microsoft Windows Forum!

Based on the currently published Microsoft documentation, AF_HYPERV (Hyper-V Sockets) is documented as a communication mechanism between the host and virtual machines, but Microsoft does not currently document a complete authorization and security model for VMMS-managed Hyper-V virtual machines that covers per-account permissions, Service-ID isolation, or transport-level VM identity guarantees. Therefore, these behaviors should not be treated as supported security boundaries unless explicitly documented by Microsoft.

1. Receiver Permissions

Microsoft documents:

• Registering Hyper-V socket services.
• Using VM IDs and Service IDs for communication.
• Standard AF_HYPERV socket operations such as bind, listen, connect, and accept.

However, I could not find public documentation describing:

• A supported per-user authorization model for AF_HYPERV listeners.
• A mechanism to grant a non-administrative account permission to bind to only one VM/Service-ID pair.
• Whether Hyper-V Administrator membership is required once a service is already registered.

Because this behavior is not documented, I would avoid relying on undocumented permissions as part of a security design.

2. Single-Service-ID Isolation

At present, Microsoft documentation allows:

• Registering custom Guest Communication Services.
• Enabling or disabling services for specific VMs.

However, I could not find documentation describing a host-enforced policy that would:

Allow exactly one guest-to-host Service ID while denying all other custom Service IDs before they reach the receiving application.

For security-sensitive scenarios, I would recommend implementing application-level authentication and authorization rather than relying solely on Service-ID selection.

3. Built-in Hyper-V Services

Built-in services such as:

• PowerShell Direct
• Key-Value Pair Exchange (KVP)
• Guest Service Interface
• Heartbeat
• Time Synchronization
• Backup Integration

are documented as Hyper-V Integration Services and are managed separately through Hyper-V configuration interfaces.

Based on the published documentation, these services should not automatically be assumed to follow the same policy model as custom AF_HYPERV Guest Communication Services.

4. Originating VM Identity

Microsoft documents AF_HYPERV addressing through:

• VM ID
• Service ID

However, I could not find public documentation that formally defines:

• Anti-spoofing guarantees.
• Identity trust boundaries.
• VM identity behavior after cloning, import/export, or recreation.
• A supported API contract for treating the transport-reported VM identity as a security principal.

For that reason, I would recommend treating transport-level VM identity as informational unless it is combined with application-level authentication.

VMMS vs HCS

You are correct not to assume that:

BindSecurityDescriptor

ConnectSecurityDescriptor

from HCS-managed environments apply to VMMS-managed Hyper-V virtual machines.

Microsoft publicly documents these settings for HCS-managed compute systems, but I could not find documentation describing a supported mapping of those controls to traditional VMMS-managed Hyper-V VMs.

My Recommendation

Because your design depends on security guarantees rather than simple connectivity, and because the public documentation does not fully define these authorization and isolation behaviors, I would recommend opening a Microsoft Support case if the AF_HYPERV transport itself is intended to be a security boundary.

Useful references:

• Make your own Hyper-V integration services

Hyper-V Integration Services

Hyper-V APIs

Host Compute Service Overview

I hope this answer has brought you useful information. If so, please click on Accept Answer and consider upvoting it. Doing so helps other community members identify useful solutions to similar issues.

Welcome to Microsoft Q&A!

Thank you for the detailed question and for clearly distinguishing VMMS-managed Hyper-V virtual machines from HCS-managed compute systems.

Based on the currently public available Microsoft documentation, Hyper-V socket services for VMMS-managed virtual machines can be registered, enabled, and addressed by using a VM ID and Service ID. However, the published documentation does not currently describe:

• A complete per-account authorization model for AF_HYPERV receivers.
• A documented mechanism to restrict a VMMS-managed VM to a single allowed Service ID while denying all others.
• A supported method to query or verify transport-level authorization policies for Service IDs.
• A formal security contract defining peer VM identity validation or anti-spoofing guarantees for accepted AF_HYPERV connections.

As a result, these behaviors should not be assumed to be supported security boundaries unless explicitly documented by Microsoft for the specific Hyper-V and Windows version being used.

1. Receiver Permissions

For a standard VM managed through Hyper-V Manager, Hyper-V PowerShell, or the root\virtualization\v2 WMI provider, the documented Hyper-V socket model includes:

• Registering a Service ID under the host's GuestCommunicationServices registry location.
• Enabling or disabling that service for a specific virtual machine through supported Hyper-V management interfaces.
• Addressing endpoints by using a VM ID and Service ID.
• Using standard AF_HYPERV socket operations such as bind, listen, connect, and accept.

Service ID registration requires administrative privileges and enables communication between the host and virtual machines.

However, the published documentation does not describe a supported per-account authorization model for VMMS-managed VMs. Specifically, Microsoft does not currently document:

• The exact privileges, rights, or group memberships required by a process that binds or accepts AF_HYPERV connections.
• A supported mechanism to grant a non-administrative account permission to bind to only a specific VM ID and Service ID pair.
• Whether the ACL on the GuestCommunicationServices registry key represents the security boundary enforced by the AF_HYPERV transport.
• A supported method for viewing or validating the effective bind/connect permissions applied to a Service ID.

As a result, the available documentation does not provide sufficient information to conclude that a receiver can operate without Hyper-V administrative privileges or other virtualization-related permissions. While it may be possible for an application's runtime process to run with fewer privileges than the component responsible for service registration or VM configuration, the supported permission model for that scenario is not currently documented.

2. Single-Service-ID Isolation

The documented VMMS model supports registering custom services and enabling or disabling services for individual VMs, which can help reduce the exposed communication surface.

That said, I was unable to find documentation describing a host-enforced policy equivalent to:

"Allow only this specific guest-to-host Service ID and reject all other optional or custom Service IDs before they reach an application."

Similarly, the public Hyper-V PowerShell and WMI interfaces do not appear to provide a way to query a comprehensive transport-level authorization policy for AF_HYPERV Service IDs.

While administrators can inspect registered GuestCommunicationServices entries and integration service settings, Microsoft public documentation does not currently describe those settings as an authoritative view of AF_HYPERV authorization policy.

For designs that require strict isolation, it is a good practice for the receiving application to validate the expected Service ID and originating VM identity and to implement appropriate application-level authentication and authorization controls. However, those controls should be viewed as defense-in-depth measures rather than evidence of a documented transport-level enforcement policy.

3. Built-in and Special Endpoints

Several guest-to-host communication features are implemented as Hyper-V Integration Services, including:

• Key-Value Pair Exchange (KVP)
• Guest Service Interface
• PowerShell Direct
• Heartbeat
• Shutdown
• Time Synchronization
• VSS Backup Integration

Many of these services can be individually enabled or disabled using Hyper-V Manager, Enable-VMIntegrationService, or Disable-VMIntegrationService.

Some important distinctions include:

• KVP is provided by the Hyper-V Data Exchange Service.
• Guest file copy functionality is provided through the Guest Service Interface, which is disabled by default for Windows guests.
• PowerShell Direct relies on the Hyper-V PowerShell Direct Service in the guest.
• Other integration services have their own dedicated host and guest components.
• Enhanced Session Mode provides VMConnect enhancements and device redirection. Public AF_HYPERV documentation does not identify it as a custom GuestCommunicationServices Service ID managed through the standard custom-service registration model.

Based on the published documentation, disabling a custom AF_HYPERV Service ID should not be assumed to disable or govern these built-in integration services. Where required, those features should be reviewed and managed through their own supported configuration interfaces.

4. Peer VM Identity

The documented Hyper-V socket address structure contains:

• The AF_HYPERV address family
• A VM ID
• A Service ID

This defines how Hyper-V socket endpoints are addressed. However, the current public documentation does not provide a complete security contract describing how a receiving application should treat the identity of a connected peer.

In particular, Microsoft does not currently document:

• Which supported APIs should be used to obtain an authenticated originating VM identity after a connection is accepted.
• Whether the returned VM identity is guaranteed to be assigned exclusively by the Hyper-V transport.
• The specific anti-spoofing guarantees provided against a compromised or malicious guest.
• How that identity behaves across scenarios such as VM export/import, cloning, recreation, or VM ID reuse.

For that reason, I would be cautious about treating the transport-reported VM identity as a standalone security principal without additional guidance from Microsoft. For security-sensitive scenarios, it is generally advisable to combine transport-level information with application-level authentication, authorization, and credential management mechanisms.

5. VMMS Compared with HCS

The Host Compute Service (HCS) schema documents properties such as BindSecurityDescriptor and ConnectSecurityDescriptor for computer systems created and managed through the HCS lifecycle and JSON configuration model.

By contrast, persistent virtual machines managed through Hyper-V Manager, Hyper-V PowerShell, or the Hyper-V WMI provider use the VMMS management model. The documented VMMS interfaces do not expose equivalent properties, and current public Microsoft documentation does not describe a supported mapping between HCS security descriptors and existing VMMS-managed virtual machines.

Therefore, HCS-specific socket security settings should not be assumed to apply to VMMS-managed VMs unless Microsoft provides explicit documentation describing that relationship.

6. Version Applicability

The public Hyper-V socket API became available beginning with Windows 10 Anniversary Update, and current documentation lists Windows 10 and Windows 11 as supported host operating systems.

Because your design depends on authorization and identity guarantees that are not fully described in the available documentation, it would be important to record the exact Windows 11 edition, build number, SDK version, guest operating system, and VM configuration version being evaluated.

As moderators and support contributors, I can only share information that is publicly documented or published through supported Microsoft channels. If your design depends on these behaviors as security boundaries, I would recommend opening a Microsoft Support case. Because the current documentation does not fully address these authorization and identity guarantees, a support case is the best way to obtain authoritative, version-specific guidance from the Hyper-V engineering team and confirm that your design aligns with supported product behavior

References:

Make your own integration services | Microsoft Learn

Hyper-V Integration Services | Microsoft Learn

Manage Hyper-V Integration Services | Microsoft Learn

Host Compute System Overview | Microsoft Learn

Hyper-V APIs | Microsoft Learn

JSON Schema Reference | Microsoft Learn

Troubleshoot Hyper-V Installation, Configuration, and Operational Failures - Windows Server | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.