This is somewhat risky/ill-advised as follows: you are allowing drivers to remain which do not meet the stringent tests Microsoft makes to ensure all drivers meet the requirements those tests check for. With Memory integrity protection, kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable. Thus you leave yourself with some drivers that don't meet these requirements. And that means some viruses who look for these drivers, will try to hide themselves in modified code pages or data pages turned into code pages where code was not checked. The good news about turning it on is that no driver now or moving forward will be able to be installed if it doesn't meet those checks. A better solution would be to identify the bad drivers and remove them but as I mentioned in the Dell Community, this requires use of a deprecated Microsoft tool and I asked Dell to reach out to me but they don't seem to care. This seems to be a problem for older Dell computers upgraded from Windows 10 to 11 using Dell-related drivers.
Now here is what ChatGPT 4.o says:
Changing the HypervisorEnforcedCodeIntegrity (HVCI) setting to 1 in the Windows registry can pose significant risks, especially if done as a hack to bypass proper enablement processes. Here are the risks and considerations associated with this approach:
System Instability and Crashes:
- Enabling HVCI without addressing incompatible or unsigned drivers can cause system crashes (blue screen of death - BSOD) or instability because incompatible drivers may not load correctly or at all.
- Critical drivers that are required for booting or hardware functionality may be blocked, leading to the inability to boot into Windows.
Incompatibility with Older or Custom Drivers:
- HVCI enforces a strict validation of drivers, ensuring they are signed and comply with Microsoft's Kernel Mode Code Signing (KMCS) policies.
- Many older or custom drivers, especially those not updated to meet modern security standards, will fail to load, rendering certain hardware or applications unusable.
No Error Information:
- If you are trying to enable Code Integrity and it fails without listing the problematic drivers, simply changing the registry may not resolve the underlying issues. It can lead to difficult debugging, as you'll lack insight into which drivers are causing the failure.
- Driver validation tools should be used to identify incompatible drivers before enabling HVCI.
Security Implications:
- If HVCI is hacked on without proper implementation, it could be incompletely enforced, leaving security vulnerabilities that could be exploited by malware or other malicious code.
- If incompatible drivers are bypassing checks, malicious actors may take advantage of this to execute unauthorized code at the kernel level.
Hardware and Firmware Incompatibilities:
- HVCI relies on virtualization-based security (VBS), which in turn depends on specific hardware features (like CPU virtualization extensions).
- If your system's firmware or hardware does not fully support VBS or HVCI, changing the registry value to force enablement may result in hardware conflicts, leading to non-functional virtualization features and even hardware failure.
Recovery Complexity:
- If the system fails to boot after enabling HVCI through the registry, recovery might involve booting into safe mode or using system recovery tools to revert the changes. This can be difficult, especially if drivers required for recovery are blocked by HVCI.
- Test Compatibility First: Use Microsoft's Device Guard and Credential Guard Readiness Tool to check compatibility before enabling HVCI.
- Update Drivers: Ensure all drivers are updated to the latest versions and compatible with Kernel Mode Code Integrity requirements.
- Use Group Policy or Settings: Where possible, use the official settings via Windows Defender Security Center or Group Policy Editor to enable HVCI, rather than directly modifying the registry.
By forcing HVCI through registry edits, you risk breaking your system in ways that might be difficult to recover from, and you may not achieve the desired security benefits if done improperly.