Understanding Virtualization-Based Security
By CtrlOne Team ·
Virtualization-based security, often shortened to VBS, uses the hardware hypervisor to create isolated regions of memory that even a compromised kernel cannot freely tamper with. It underpins several modern Windows protections and represents a genuine step up in the trust model. Yet like most powerful features, VBS depends on hardware support and on policy settings being configured correctly and left in place. This article explains what virtualization-based security actually provides, what it requires to work, why its settings drift, and how governed, versioned configuration keeps VBS-related controls enabled and provable across a fleet.
What VBS actually provides
Virtualization-based security uses the hypervisor to carve out isolated memory that is protected from the normal operating system, including much of the kernel. Sensitive operations can run in that isolated space, out of reach of ordinary code.
The value is a stronger trust boundary. Even if an attacker gains significant control of the OS, the isolated region raises the cost of reaching the secrets and mechanisms it protects.
What it depends on
VBS is not free-standing. It relies on hardware virtualization support, appropriate firmware settings, and driver compatibility, along with the policy settings that enable the protections built on top of it.
This dependency chain is why a feature can be 'supported' on paper yet not actually running. Each prerequisite has to be in place and stay in place for the protection to hold.
- Hardware virtualization and firmware support.
- Compatible drivers that do not block isolation.
- Policy settings that enable the protections.
- The settings remaining enforced over time.
Why VBS settings drift
Because VBS-related protections are enabled through policy and registry configuration, they drift like any other setting. Compatibility troubleshooting, updates, or local changes can leave a device with the protection disabled.
The result is uneven coverage across a fleet, where some machines run with the protection and others quietly do not. Verifying the applied state on each endpoint is the only reliable way to know.
Rolling out without breaking things
VBS-related features can interact with older drivers and specialised software, so a careful rollout matters. Staging changes and being able to reverse them cleanly avoids turning a hardening effort into an outage.
Versioned configuration makes this practical. If a compatibility problem appears, rolling back to a known-good state is a controlled step rather than a scramble.
How CtrlOne governs VBS-related configuration
CtrlOne expresses the policy settings that enable VBS-based protections as named toggles, pushes them to enrolled devices, versions every change, and re-asserts the intended state when a device drifts. When a protection is switched off, the device is corrected back to its known-good configuration.
CtrlOne is a configuration and governance platform, not an antivirus or EDR, and it does not itself provide the hypervisor isolation. It keeps the configuration that enables these protections honest, reducing attack surface so detection tools have less to watch.
- Named toggles for VBS-related policy settings.
- Staged rollout with clean, versioned rollback.
- Drift correction so protections stay enabled.
Proving coverage
Uneven VBS coverage is exactly the kind of gap an audit or incident review exposes. Being able to show which devices had the protection enabled, and when, turns a worrying unknown into a clear record.
Point-in-time snapshots and exportable compliance evidence packs demonstrate the configured state across the fleet, which supports your audit and makes coverage claims verifiable rather than aspirational.
Frequently asked questions
What does virtualization-based security protect against?
It uses the hypervisor to isolate sensitive memory from the normal OS, so even a heavily compromised kernel has a harder time reaching what the isolated region protects. It raises the cost of attack rather than guaranteeing immunity.
Why might VBS be supported but not running?
It depends on hardware, firmware, driver compatibility, and policy settings. If any prerequisite is missing or a setting has drifted off, the protection may not actually be active.
Does CtrlOne provide VBS itself?
No. VBS isolation comes from Windows and the hardware hypervisor. CtrlOne governs the policy settings that enable the protections and keeps them enforced and provable.
How do I avoid breaking things when enabling VBS features?
Stage the rollout and use versioned configuration so you can roll back cleanly if an older driver or specialised application turns out to be incompatible.
Keep VBS protections enabled
See how CtrlOne governs VBS-related settings across the fleet, rolls back cleanly, and proves coverage.