Detect Hypervisor-protected Code Integrity being disabled by monitoring configuration changes, policy changes, and system events that show memory integrity was turned off or failed to start. Investigate any change made outside approved maintenance, especially if it follows privilege escalation or tampering with boot or security settings. Correlate with driver loading and subsequent execution of unsigned or suspicious code.
How HVCI loss shows up in Windows telemetry
Hypervisor-protected code integrity is not usually detected from a single event. The useful signal is a change in state: a configuration or policy update that turns memory integrity off, a boot-time failure to start it, or a security setting that no longer matches the approved baseline. Treat the issue as a posture change first, then confirm whether execution behavior also changed.
On a healthy system, you want to see consistency across policy, boot state, and code-loading behavior. If HVCI is disabled, that consistency breaks. A configuration drift, a security product tamper event, or a security-setting change may be the first clue, but the real confirmation comes when the host starts accepting drivers or code paths that should have been blocked under the protected configuration.
For Windows hardening context, align the detection logic with the system settings and guardrails described in the Windows Endpoint Hardening Guide, especially where memory integrity, tamper protection, and baseline enforcement are part of the expected state.
What to correlate when HVCI is turned off
HVCI disablement is most useful when correlated with nearby activity that explains intent or impact. A privileged change to boot settings, security policy, or code integrity settings is more suspicious when it is followed by a new driver load, a blocked driver no longer being blocked, or execution of unsigned code that would previously have been constrained.
That correlation matters because the absence of HVCI changes the trust boundary on the endpoint. If an attacker can tamper with the boot path or security settings, they may be trying to remove a protection before loading a driver, gaining kernel-level foothold, or weakening defenses that would otherwise stop unsigned or vulnerable code.
Application control is a useful companion here because the objective is often not just to notice that memory integrity was disabled, but to see whether the host also lost enforcement over what it can run. The Application Allowlisting Guide is relevant when you need to pair HVCI-state monitoring with driver and executable control logic.
From an external control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for structuring the relationship between configuration management, system integrity, logging, and unauthorized change detection.
How to investigate and respond without missing the real cause
When you detect HVCI being disabled, assume the change may be either an authorized maintenance action or an intrusion step until you verify which it is. Start by checking who made the change, when it occurred, whether it was approved, and whether the endpoint shows other signs of tampering or persistence. A single disabled setting is less informative than the sequence around it.
If patching or reconfiguration is not immediate, preserve evidence before remediation. Capture the relevant event history, current boot and code integrity configuration, loaded drivers, and any recent security setting changes. That record helps you determine whether the issue was a one-time misconfiguration, a failed policy rollout, or part of a broader compromise.
Threat-hunting context from MITRE ATT&CK Enterprise Matrix helps map this kind of behavior to privilege escalation, defense evasion, and driver-based persistence patterns that often appear when an endpoint protection control has been weakened.
Where driver provenance is part of the investigation, the integrity lens from SLSA is useful for thinking about how build and artifact trust can be checked before code reaches the endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | HVCI disablement is a configuration integrity issue on Windows. |
| SI-7 — Software, Firmware, and Information Integrity | HVCI protects code integrity and should be monitored as an integrity control. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing events that show policy and boot-state changes. | |
| Recommendation — Enforce approved secure baselines and alert on unauthorized configuration drift. Detect and respond to integrity-control weakening before suspicious code can execute. Correlate audit records to identify unauthorized security-setting changes and related execution activity. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | HVCI state should be part of secure Windows baseline enforcement. |
| Recommendation — Monitor endpoint configuration drift and restore the hardened baseline when memory integrity is altered. | ||
| MITRE ATT&CK | T1562 — Impair Defenses | Disabling HVCI is a defense-impairment action that can precede further abuse. |
| Recommendation — Hunt for defense-imairment behaviors that weaken kernel and code-integrity protections. | ||
Practitioner Guidance
What to verify: Confirm whether the HVCI state changed during an approved maintenance window and whether the device’s security baseline still matches the intended policy. If the host now allows unexpected driver behavior, treat that as a stronger indicator than the configuration change alone.
Decision rule: If HVCI was disabled without an approved change, prioritize containment and integrity review before chasing every downstream symptom. If the host also shows suspicious driver loading or unsigned execution, assume the protection change may have been used to enable follow-on activity.
What to prioritize: Review the change source, boot configuration, code integrity status, and driver load history as one chain. The practical question is not only whether memory integrity is off, but whether the system lost a control that matters for subsequent execution trust.
Practitioner takeaway: The most reliable detection is state change plus consequence, not a lone “disabled” flag. If HVCI dropped unexpectedly and the host then behaves like a less-restricted execution environment, treat the disablement as a security event until proven otherwise.
Related resources from NHI Mgmt Group
- Why should LM hash storage be disabled on Windows, and how do you detect it being re-enabled?
- How do you detect data being compressed and password protected for exfiltration on Windows?
- Hypervisor-Protected Code Integrity
- What breaks when Windows code integrity components are downgraded on an otherwise patched machine?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org