Windows 11 Pro Hyper-V does not expose a documented, supported authorization mechanism that grants a principal forced-power control over exactly one VM while denying equivalent control over the host’s other VMs.

Authorization boundaries

• Msvm_ComputerSystem.RequestStateChange is an operation, not a delegation system. It changes the state of the VM represented by a particular Msvm_ComputerSystem instance, but Microsoft’s example must run on the Hyper-V host with administrator privileges. The documented return codes include 32769 for access denied, but no per-instance ACL, security descriptor, or authorization-assignment interface is documented for the method. ^1^
• WMI permissions apply to the namespace, not to one VM instance. Granting Execute Methods on root\virtualization\v2 authorizes method execution at the namespace boundary. WMI’s namespace security descriptor does not provide a documented way to express “execute RequestStateChange only when this instance has VM GUID X.” ^2^ Namespace descriptors can be changed through WMI Control or __SystemSecurity, but they remain namespace security descriptors. ^3^
• Grant-VMConnectAccess is deliberately narrower and does not grant power-management rights. It grants access to initiate a Virtual Machine Connection session for the named VM or VM ID. It is not authorization for shutdown, turn-off, reset, or other state changes. ^4^
• Hyper-V Administrators is host-wide. Members have “complete and unrestricted access to all the features in Hyper-V,” so this group cannot satisfy a one-VM authorization requirement. ^5^
• Msvm_SecurityService is unrelated to management authorization. Its documented methods configure VM security features such as key protectors and security settings; it does not publish an ACL for principals allowed to operate a VM. ^6^ The associated settings cover TPM, shielding, state protection, migration encryption, and related properties—not management-operation permissions. ^7^

Consequently, granting a non-administrative account direct WMI/CIM power-control access cannot be constrained through a documented Hyper-V provider ACL to exactly one VM.

Forced shutdown distinction

A forced turn-off is a host-side power operation comparable to removing power and can cause guest data loss or corruption. It is distinct from the integration-service request that asks the guest OS to shut down cleanly. The host can always force a VM off, whereas friendly shutdown depends on the guest shutdown service. ^8^

That distinction does not create a separate per-VM authorization surface: both remain host management operations.

Windows Server Hyper-V

Installing the Hyper-V role on Windows Server does not by itself add a documented per-VM ACL for RequestStateChange. The same WMI v2 provider is used, and the documented method requires administrative execution in Microsoft’s examples. Therefore, moving the design from Windows 11 Pro to standalone Windows Server Hyper-V does not satisfy the requirement by itself. ^1^

System Center Virtual Machine Manager (VMM) is a separate management layer that supports role-based security composed of:

• a profile defining permitted operations;
• a scope defining the objects on which those operations apply;
• a membership list defining the principals.

VMM tenant and self-service roles can manage VMs within their assigned ownership and scope. ^9^

However, the cited VMM documentation does not establish that an individual forced-turn-off action can be delegated—and provider-enforced—to exactly one existing VM under your required threat model. That specific action/scope combination should therefore be validated against the intended VMM version before treating VMM as satisfying the control.

Architecture implication

For a strict security boundary, do not grant the principal:

• membership in Administrators or Hyper-V Administrators;
• WMI Execute Methods access to root\virtualization\v2;
• credentials or an execution token with broader Hyper-V authority.

A GUID-validating privileged broker is application-enforced delegation, not least-privilege authorization enforced by Hyper-V. If that is unacceptable, the practical hard boundary is to place the designated VM on a separate Hyper-V host or security boundary where host-wide authority cannot reach unrelated VMs. VMM is the documented Microsoft management-layer candidate if its scoped actions meet the exact forced-power requirement after validation.

References

1. RequestStateChange method of the Msvm_ComputerSystem class
2. Access to WMI Namespaces
3. Setting Namespace Security Descriptors
4. Grant-VMConnectAccess-Description
5. Active Directory security groups
6. Msvm_SecurityService class
7. Msvm_SecuritySettingData class
8. Hyper-V integration services
9. Manage roles and permissions in VMM