Daily Defender News
Aboutmerill.net
Microsoft Defender for Endpoint
Endpoint protection

Exploit Protection Reference

4 September 2026Doc update+39 / −15 lines

In brief

The page clarifies per-program registry settings, XML deployment through PowerShell, Group Policy, and MDM, policy-removal behavior, and resetting settings with the Windows Security Baselines XML. It also adds links and mitigation-specific introductory sections.

What Defender admins need to know

Administrators can more easily determine how exploit protection settings are targeted and reset. Settings deployed by XML are not automatically removed when the related Group Policy or MDM policy is no longer enforced.

Summaries are generated from the documentation change itself.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

author: limwainstein ms.author: lwainstein ms.reviewer: cjacks ms.custom: asr, msecd-doc-authoring-10141016 ms.subservice: asr ms.topic: how-to ms.collection:

  • m365-security
  • tier3
  • mde-asr ms.date: 06/16/07/03/2026 appliesto:
    • Microsoft Defender for Endpoint Plan 1
    • Microsoft Defender for Endpoint Plan 2

Exploit protection mitigations are applied per application.

Mitigations are configured via aEach program has its own registry entry for each program that you configure protections for.controls which mitigations apply. These settings are stored in the MitigationOptions registry entry for each program (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). TheyThese mitigation settings take effect when you restart the program, andprogram. They remain effectiveactive until you change them and restart the program again.program.

You can configure mitigations through an XML file by using PowerShell, Group Policy, or MDM. When you use an XML file, the system sets the registry entries for you.

Resetting exploit protection

To remove exploit protection settings, export the XML configuration from a clean Windows 10 or Windows 11 device, and deploy this new XML file. Alternately, Microsoft provides an XML file as part of the Windows Security Baselines for resetting exploit protection settings.

To reset exploit protection settings using PowerShell, run the following command to apply the reset policy from the XML file and restore mitigation settings to their defaults:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

The following XML file is the EP-reset.xml distributed with the Windows Security Baselines. This file defines per-application mitigation overrides that reset exploit protection settings to their defaults for common applications such as Microsoft Office, web browsers, and media players:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>

## Mitigation Reference

The following exploit protection mitigations each include a description, compatibility considerations, and configuration options.

## Arbitrary code guard

The following sections describe how arbitrary code guard works, its compatibility impact, and its configuration options.

### Description

Arbitrary code guard helps protect against a malicious attacker loading the code of their choice into memory through a memory safety vulnerability and being able to execute that code.

## Block low integrity images

The following sections describe how block low integrity images works, its compatibility impact, and its configuration options.

### Description

Block low integrity images prevents the application from loading files that are untrusted, typically because they've been downloaded from the internet from a sandboxed browser.

## Block remote images

The following sections describe how block remote images works, its compatibility impact, and its configuration options.

### Description

Blocking remote images helps to prevent the application from loading files that are hosted on a remote device, such as a UNC share. Blocking remote images helps protect against loading binaries into memory that are on an external device controlled by the attacker.

## Block untrusted fonts

The following sections describe how block untrusted fonts works, its compatibility impact, and its configuration options.

### Description

Block untrusted fonts mitigates the risk of a flaw in font parsing leading to the attacker being able to run code on the device. Only fonts that are installed into the windows\fonts directory will be loaded for processing by GDI.

## Code integrity guard

The following sections describe how code integrity guard works, its compatibility impact, and its configuration options.

### Description

Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. Code integrity guard includes [WHQL](/windows-hardware/drivers/install/whql-release-signature) (Windows Hardware Quality Labs) signatures, which allows WHQL-approved drivers to run within the process.

This mitigation is implemented within the memory manager, which blocks the binary from being mapped into memory. If you attempt to load a binary that isn't signed by Microsoft, the memory manger returns the error STATUS_INVALID_IMAGE_HASH. By blocking at the memory manager level, this prevents both binaries loaded by the process and binaries injected into the process.

### Compatibility considerations


## Control flow guard (CFG)

The following sections describe how control flow guard works, its compatibility impact, and its configuration options.

### Description

Control flow guard (CFG) mitigates the risk of attackers using memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker might use a buffer overflow vulnerability to overwrite memory containing a function pointer, and replace that function pointer with a pointer to executable code of their choice (which could also be injected into the program).

## Data Execution Prevention (DEP)

The following sections describe how Data Execution Prevention works, its compatibility impact, and its configuration options.

### Description

Data execution prevention (DEP) prevents memory that wasn't explicitly allocated as executable from being executed. DEP helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code.

### Configuration options

**Enable ATL Thunk emulation** - This option controls ATL Thunk emulation. ATL, the ActiveX Template Library, is designed to be as small and fast as possible. To reduce binary size, it uses a technique called *thunking*. Thunking is often linked to 32-bit and 16-bit interaction, but ATL has no 16-bit parts. Instead, to save space, ATL stores machine code in memory that isn't word-aligned. This creates a smaller binary. ATL then runs that code directly. ATL versions compiled with Visual Studio 7.1 or earlier (Visual Studio 2003) don't mark this memory as executable. Thunk emulation fixes that issue. Apps with a binary extension model (such as Internet Explorer 11) need ATL Thunk emulation enabled.

## Disable extension points

The following sections describe how the disable extension points mitigation works, its compatibility impact, and its configuration options.

### Description

The Disable extension points mitigation disables various extension points for an application, which might be used to establish persistence or elevate privileges of malicious content.

## Disable Win32k system calls

The following sections describe how the disable Win32k system calls mitigation works, its compatibility impact, and its configuration options.

### Description

Win32k.sys provides a broad attack surface for an attacker. As a kernel-mode component, it's frequently targeted as an escape vector for applications that are sandboxed. This mitigation prevents calls into win32k.sys by blocking a thread from converting itself into a GUI thread, which is then given access to invoke Win32k functions. A thread is non-GUI when created, but converted on first call to win32k.sys, or through an API call to [IsGuiThread](/windows/win32/api/winuser/nf-winuser-isguithread).

## Don't allow child processes

The following sections describe how the don't allow child processes mitigation works, its compatibility impact, and its configuration options.

### Description

The Don't allow child processes mitigation prevents an application from creating new child applications. A common technique used by adversaries is to initiate a trusted process on the device with malicious input (a "living off the land" attack), which often requires launching another application on the device. If there are no legitimate reasons why an application would launch a child process, this mitigation mitigates that potential attack vector. The mitigation is applied by setting a property on the process token, which blocks creating a token for the child process with the error message STATUS_CHILD_PROCESS_BLOCKED.

## Export address filtering

The following sections describe how export address filtering works, its compatibility impact, and its configuration options.

### Description

Export address filtering (EAF) mitigates the risk of malicious code looking at the export address table of all loaded modules to find modules that contain useful APIs for their attack. This is a common tactic used by shellcode. In order to mitigate the risk of such an attack, this mitigation protects three commonly attacked modules:

## Force randomization for images (Mandatory ASLR)

The following sections describe how Mandatory ASLR works, its compatibility impact, and its configuration options.

### Description

Address Space Layout Randomization (ASLR) mitigates the risk of an attacker using their knowledge of the memory layout of the system in order to execute code that is already present in process memory and already marked as executable. This can mitigate the risk of an attacker using techniques such as return-to-libc attacks, where the adversary sets the context and then modifies the return address to execute existing code with context that suits the adversary's purpose.

### Description

Hardware-enforced stack protection offers robust protection against ROP exploits. It works by keeping a record of the intended execution flow of a program. To support smooth adoption and app compatibility, Windows offers this protection as an opt-in model. Developers can enable it at their own pace.

### Compatibility considerations


### Description

Randomize memory allocations (Bottom-up ASLR) adds entropy to relocations, so their location is randomized and therefore less predictable. This mitigation requires [Mandatory ASLR](#force-randomization-for-images-mandatory-aslr) to take effect.

The size of the 32-bit address space places practical constraints on the entropy that can be added, and therefore 64-bit applications make it more difficult for an attacker to guess a location in memory.

### Compatibility considerations

Most apps that work with Mandatory ASLR (rebasing) also work with Bottom-up ASLR. Some apps might have pointer-truncation issues if they save local pointers in 32-bit variables. These apps expect a base address below 4 GB, so they won't work with the high entropy option. You can disable high entropy if needed.

### Configuration options