Welcome to Microsoft Q&A!

Thank you for taking the time to provide such a detailed description of your security requirement.

Based on the currently published Microsoft documentation, I could not find a supported mechanism in Windows 11 Pro Hyper-V that allows a non-administrative Windows principal to forcibly shut down exactly one designated VM while ensuring that the same principal cannot perform equivalent management operations on other VMs.

Msvm_ComputerSystem.RequestStateChange is the WMI method used to request state transitions for a Hyper-V virtual machine. Microsoft documents the supported state transitions, return values, and method behavior. The documentation also notes that the provided examples must run on the Hyper-V host with administrator privileges. However, it does not document a per-VM security descriptor or delegation mechanism that grants a Windows principal permission to invoke only this lifecycle operation against one specified VM.

Similarly, the Hyper-V WMI provider is documented as a management interface capable of managing Hyper-V services. The available Hyper-V API documentation describes the management interfaces and their purposes, but it does not establish an object-level RBAC model for assigning individual Windows principals particular lifecycle operations on individual VMs.

There is an important distinction with Grant-VMConnectAccess. This cmdlet can associate users with individual virtual machines, but its documented purpose is to grant access to connect to those VMs through Virtual Machine Connection (VMConnect). It should therefore not be interpreted as granting, restricting, or delegating Hyper-V lifecycle-management operations such as Stop, Turn Off, Reset, or RequestStateChange.

The mechanisms mentioned in your question therefore operate at different authorization boundaries. WMI namespace permissions apply to access to the management namespace, broader Hyper-V administrative permissions provide management authority, and Grant-VMConnectAccess specifically controls VMConnect access. A VM-specific GUID or VMConnect permission does not, by itself, establish the Windows-enforced per-VM lifecycle authorization boundary required by your design.

For the same reason, I would not treat Get-VMSecurity, Set-VMSecurity, or Set-VMSecurityPolicy as equivalent to a per-user VM-management ACL. These mechanisms should not be relied upon as providing granular lifecycle-management authorization for a Windows account unless Microsoft documentation explicitly defines such a security boundary.

For this type of security requirement, the safer approach is not to grant the unprivileged account direct Hyper-V management authority. A privileged Hyper-V operation could instead be placed behind an appropriately secured and trusted management service that exposes only the required operation.

However, your concern about this design is valid: if the broker itself holds broader Hyper-V privileges and merely validates the target VM GUID in application logic, that application check is not equivalent to an authorization boundary enforced by Windows or the Hyper-V provider. Therefore, if your security model explicitly requires Hyper-V itself to enforce per-principal, per-VM lifecycle authorization, I would not represent a broker solution as satisfying that requirement.

I would apply the same caution to Windows Server Hyper-V. Although Windows Server can participate in additional enterprise management solutions, the standard Hyper-V interfaces should not be assumed to provide per-principal, per-VM RequestStateChange authorization unless Microsoft documentation for the specific product or management layer explicitly documents that capability.

I understand that you are looking for a definitive answer before implementing an automated containment mechanism, and I appreciate why confirmation is important for a security-sensitive design.

Unfortunately, this is also where the scope of Microsoft Q&A becomes a limitation.

Microsoft Q&A is primarily a community-based technical forum. I can help interpret documented product behavior, explain supported configurations, suggest troubleshooting steps, and point to the relevant Microsoft documentation. However, the forum cannot validate undocumented Hyper-V authorization internals, confirm that an undocumented behavior constitutes a supported security boundary, or provide an authoritative security guarantee on behalf of the Windows/Hyper-V product engineering team.

Because the publicly available documentation does not define the per-VM authorization boundary required by your design, I am afraid I cannot provide further configuration steps or an undocumented mechanism through the forum that could safely be relied upon to meet this security requirement. Doing so would risk presenting an unsupported implementation as an established Hyper-V security guarantee.

If this authorization property is mandatory for your containment architecture, the appropriate next validation step would be to open a Microsoft Support request. Support can review the specific Windows edition, build, Hyper-V implementation, and security requirement through the appropriate support channel and determine whether there is a supported solution applicable to your environment.

Therefore, based strictly on the currently published documentation, I would not consider Windows 11 Pro Hyper-V to provide a documented and supported per-VM authorization mechanism that permits a non-administrative principal to perform forced shutdown or equivalent RequestStateChange operations on exactly one VM. For a security-sensitive solution, I would also recommend against relying on undocumented behavior as an authorization boundary.

References:

Grant-VMConnectAccess (Hyper-V) | Microsoft Learn

RequestStateChange method of the Msvm_ComputerSystem class - Win32 apps | Microsoft Learn

Hyper-V APIs | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.