Kernel Mode Hardware Enforced Stack Protection

Kernel Mode Hardware Enforced Stack Protection is a Windows 11 security feature that uses CPU virtualization extensions to prevent malicious code from exploiting stack buffer overflows in kernel-mode drivers and core system components. It works by placing the kernel stack in a protected memory region where even a compromised driver cannot modify return addresses, making a common class of privilege-escalation attacks significantly harder to execute. This article explains what the feature does, how it works, how to check if it is enabled, and what to do if it causes compatibility problems.

Background: Why Kernel Stack Protection Exists

For decades, stack buffer overflows have been one of the most reliable ways for attackers to gain control of a system. When a kernel-mode driver writes past the end of a local buffer, it can overwrite the saved return address on the stack. When the function returns, the CPU jumps to that attacker-controlled address, often executing code that elevates privileges or disables security controls.

Traditional mitigations like Stack Guard (compiler-inserted canaries) and Kernel ASLR (address space layout randomization) help but have known weaknesses. Canaries can be leaked or bypassed with large overflows; ASLR can be defeated by information disclosure. In Windows 10, Microsoft added Kernel Shadow Stacks (also called Hardware-enforced Stack Protection) for user-mode processes, but the kernel itself remained vulnerable. Windows 11 extends this protection to kernel mode, using CPU features like Intel CET (Control-flow Enforcement Technology) and AMD Shadow Stack to create a separate, read-only shadow stack that the CPU itself validates against.

How Kernel Mode Hardware Enforced Stack Protection Works

The core idea is simple: maintain a second copy of the return addresses, called a shadow stack, that is inaccessible to normal software. When a function is called, the CPU pushes the return address onto both the normal stack and the shadow stack. When the function returns, the CPU pops the address from the shadow stack and compares it to the address on the normal stack. If they differ, the CPU raises a fault and the system crashes with a bugcheck (typically KERNEL_SECURITY_CHECK_FAILURE) rather than executing the attacker’s code.

In Windows 11, this is implemented in two layers:

Hardware enforcement: The CPU itself performs the stack comparison, using dedicated registers and memory pages marked as shadow stack. Software cannot write to these pages, even with kernel privileges, because the CPU enforces the protection.
Software enablement: The Windows kernel marks its own stacks as shadow-stack-compatible at boot time, and drivers must be compiled with support for the feature (using the CONTROL_FLOW_GUARD and SHADOW_STACK flags) to opt in. Most inbox drivers and many third-party drivers are already compatible.

The feature is enabled by default on supported hardware, but it can be turned off in the Windows Security app or via Group Policy if a driver is not compatible.

Checking if It Is Enabled on Your System

To see whether Kernel Mode Hardware Enforced Stack Protection is active, open the Windows Security app, go to Device security > Core isolation > Kernel-mode Hardware-enforced Stack Protection. The status will show either “On� or “Off�. If it is off, you can turn it on with the toggle, but a restart is required.

You can also check from an elevated PowerShell prompt:

Press Win + X and select Terminal (Admin).
Run Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\KernelShadowStacks" -Name Enabled.
If the value is 1, the feature is enabled; if 0, it is disabled.

Note that the feature requires a CPU with Intel CET or AMD Shadow Stack support. Most CPUs from 2020 onward have it, but older processors do not, and the toggle will be grayed out.

Compatibility Issues and How to Fix Them

The most common problem with this feature is that a third-party kernel driver—often an older antivirus, VPN, or hardware utility—does not support shadow stacks. When the feature is enabled, the driver may fail to load, causing a blue screen (BSOD) with KERNEL_SECURITY_CHECK_FAILURE or KMODE_EXCEPTION_NOT_HANDLED.

If you encounter such a crash, the first step is to identify the offending driver. Check the Event Viewer under Windows Logs > System for an error event with source BugCheck and note the driver name in the dump file. Once identified, update the driver to a version that supports shadow stacks. If no update is available, you can disable the feature temporarily:

Open Windows Security > Device security > Core isolation.
Turn off Kernel-mode Hardware-enforced Stack Protection.
Restart the PC.

Alternatively, use Group Policy (if you have Windows 11 Pro or Enterprise) to disable it: Computer Configuration > Administrative Templates > System > Device Guard > Enable Kernel-mode Hardware-enforced Stack Protection and set it to Disabled.

Performance Impact and Security Tradeoffs

Enabling this feature adds a small overhead to every kernel function call because the CPU must write to and validate the shadow stack. In practice, the performance cost is negligible—typically less than 1% in synthetic benchmarks—because the CPU does the comparison in hardware. For most users, the security benefit far outweighs the tiny slowdown.

However, there is a security tradeoff: if a driver is not compatible and you disable the feature, you lose the protection for the entire kernel, not just that driver. Attackers can target the unprotected driver to gain kernel code execution. Therefore, the recommended approach is to update the driver rather than disabling the feature globally.

It is also worth noting that this feature does not protect against all stack-based attacks—only those that overwrite return addresses. Attacks that corrupt local variables or use ROP (Return-Oriented Programming) chains without overwriting the return address may still succeed. Microsoft mitigates these with other features like Control Flow Guard (CFG) and Arbitrary Code Guard (ACG), which are also part of the core isolation suite.

Comparison with Other Windows Security Features

Kernel Mode Hardware Enforced Stack Protection is often confused with Memory Integrity (also called Hypervisor-protected Code Integrity, or HVCI). While both are part of Core Isolation, they work differently:

Memory Integrity runs the kernel in a virtualized container and prevents unsigned or vulnerable drivers from being loaded at all. It blocks the driver before it can run.
Kernel Shadow Stacks allow the driver to run but prevent it from corrupting return addresses. It catches the attack at the moment it happens.

They are complementary. Memory Integrity stops many attacks at the door, while shadow stacks catch overflows that slip through. On supported hardware, both are enabled by default, and you can turn them on or off independently.

Frequently Asked Questions

Is Kernel Mode Hardware Enforced Stack Protection the same as Hardware-enforced Stack Protection?

No. Hardware-enforced Stack Protection (without “Kernel Mode�) refers to the user-mode shadow stack feature that protects applications. Kernel Mode Hardware Enforced Stack Protection is the kernel-mode counterpart. Both use the same CPU technology but protect different execution contexts.

Why is the toggle grayed out in Windows Security?

This means your CPU does not support Intel CET or AMD Shadow Stack, or the feature is controlled by Group Policy. Most CPUs from Intel 11th Gen or AMD Zen 3 and later support it. If you have an older CPU, you cannot enable it.

Will this feature cause my games or apps to crash?

Only if you have a kernel driver that is incompatible. Most games and applications run in user mode and are unaffected. If you experience crashes, check for driver updates first, and only disable the feature as a last resort.

Can I enable it on Windows 10?

No. Kernel Mode Hardware Enforced Stack Protection is only available in Windows 11. Windows 10 has user-mode shadow stacks (for applications) but not the kernel-mode version.

Does it protect against all kernel exploits?

No. It specifically prevents return-address corruption. Other attack vectors, such as corrupting function pointers or data-only attacks, are not directly stopped. However, it raises the bar significantly, forcing attackers to use more complex techniques that are more likely to be detected.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →