Skip to main content

🛡️🪟💻👈🔓⚙️Group - VBS Incompatible Devices

What this group is for​

This is a static assigned device group that carves an exception out of the tenant-wide virtualization-based security policy.

It works only as a pair with:

A device lands here only because it genuinely cannot run VBS: an unsigned kernel driver Memory Integrity rejects, a legacy authentication path Credential Guard breaks, or hardware without the required support. Membership is a technical necessity, not a preference.

🛠️ Group Configuration​

SettingValue
Group name🛡️🪟💻👈🔓⚙️Group - VBS Incompatible Devices
Group descriptionDevices that cannot run virtualization-based security (Memory Integrity / Credential Guard) due to an incompatible driver or unsupported hardware. Membership requires a documented technical reason and should be temporary.
Group typeSecurity
Membership typeAssigned (Device Group)

⚠️ Governance​

Excluding a device from the enable policy is only half the job; the inverse policy is what actually returns it to a working state, so both assignments must be in place. And because you are removing a strong defense from the device, the bar is high:

  • A documented technical reason per device (which driver, which dependency, which hardware limit).
  • A path back: the plan to fix or replace the blocker so the device can rejoin VBS.
  • A regular membership review (quarterly at least). An exception that never expires is a hole, not an exception.

Good reason: a workstation with a critical unsigned driver from a vendor that has not shipped an HVCI-compatible version yet. Bad reason: "it was easier to turn it off everywhere." If you cannot defend a device's place here in an audit, it does not belong here.

🔗 Related​

Keep it small and keep it temporary. Every device here is one that should be working its way back to protected. 🔓