Adding custom services to virtualization-based security in Windows

Hi Amelia Jones,

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

Hi Amelia Jones,

As far as I know, VBS is designed to isolate sensitive processes using the hypervisor, and features like Credential Guard and Hypervisor-Enforced Code Integrity (HVCI) are tightly integrated with the Windows kernel. At this time, VBS does not provide a supported mechanism for registering or protecting custom services in the same way it does for built-in features. The protection scope is limited to Microsoft-defined components that are deeply tied into the OS security model.

That said, you can still harden your custom services by combining other layers of protection. For example, you can enforce code integrity policies through Windows Defender Application Control (WDAC), use sandboxing or containerization for isolation, and apply strict privilege management so your service runs with the least required rights. These approaches complement VBS even though they don’t extend it directly.

If your goal is to integrate with VBS-like protections, the closest supported path is to leverage WDAC and Device Guard policies, which allow you to define trusted binaries and prevent unauthorized code execution. For highly sensitive workloads, you might also consider running your service inside a Hyper-V isolated container, which gives you a similar level of separation.

I hope this clears up the confusion. If you find this answer helpful, please consider clicking Accept Answer so others can benefit too.

Jason.

Virtualization-based security (VBS) and its components (such as Credential Guard and hypervisor-protected code integrity / memory integrity) are not extensible in the way described. There is no supported mechanism to “register” or host an arbitrary, custom service inside the VBS-isolated environment.

VBS creates a special, isolated execution environment (using the Windows hypervisor) that runs specific Microsoft-defined trustlets and services only. The documented services that use VBS include, for example:

• Credential Guard (LSA credential isolation) to protect NTLM, Kerberos, and other secrets
• Hypervisor-protected code integrity (HVCI, also called memory integrity) / Device Guard, which isolates the Code Integrity service from the Windows kernel
• Other Microsoft-defined isolated services such as vTPM in certain server scenarios

These components are tightly integrated with the OS and platform security features (Secure Boot, virtualization extensions, etc.) and are not designed as a general-purpose isolation framework for third-party or custom services.

Therefore:

• VBS cannot be extended to run a custom service inside its secure environment.
• The protection scope is limited to the built-in mechanisms and trustlets that Windows defines (Credential Guard, HVCI/memory integrity, and other documented isolated services).
• Custom services must use other hardening techniques (e.g., standard process isolation, code integrity policies, application control, least privilege, etc.), but they cannot themselves become VBS trustlets.

References:

• Virtualization-based Security (VBS)
• Enable virtualization-based protection of code integrity
• Credential Guard overview
• Control the health of Windows devices
• Trusted Launch for Azure virtual machines
• Trustworthy addition for Azure Local