Exploit Protection Mitigations: The Per-Process Hardening Nobody Configures, and the XML That Rewrites All of It

Exploit protection is the most thoroughly documented Windows security feature that almost nobody turns on. It is the in-box replacement for the Enhanced Mitigation Experience Toolkit, or EMET, which reached end of support on 31 July 2018. It ships in every Windows 10 build from 1709 onward, every Windows 11 build, and Windows Server from version 1803. It applies more than twenty separate memory-safety and code-integrity mitigations. And in most tenants the Intune profile that would deploy it has never been created.

That is a shame, because the feature is already running on your fleet. Windows configures a set of per-application mitigations at install time. Office writes more. Adobe Reader writes more. Your VPN client probably writes more. None of that shows up in a compliance report, and none of it is visible in one place. This post walks the whole surface: what each mitigation actually stops, where the state lives in the registry, which mitigations have an audit mode and on which configuration surface, and what happens to all of it the first time you deploy an XML.

The problem: twenty-two mitigations and one blunt deployment channel

Start with what the feature is. A mitigation is a runtime rule that the kernel, the memory manager, or a user-mode shim applies to a process. It does not look for malware. It makes a class of exploitation technique fail outright.

Data Execution Prevention makes injected shellcode unexecutable. Arbitrary code guard makes just-in-time code generation impossible. Do not allow child processes makes a living-off-the-land chain break at the second hop. None of those rules care what the malware is called.

Microsoft documents twenty-two mitigations on the exploit protection reference page. Here is the complete list, with the scope Microsoft assigns each one and the PowerShell keyword you use to name it.

That keyword spelling in the Validate image dependency integrity row is not a typo on my side. Microsoft's own table on the turn on exploit protection page spells it EnforceModuleDepencySigning. The matching property name in Get-ProcessMitigation output on a live Windows 11 device reads EnforceModuleDependencySigning, spelled correctly. I am reporting the observed difference rather than guessing which spelling the cmdlet parser accepts. Test it before you script against it.

Now the second half of the problem. There is exactly one supported way to push this configuration to a fleet: an XML file. Group Policy takes a path to the file. Intune takes the file itself. Both land in the same registry value.

That XML describes the whole posture in one blob. It is not a per-setting delta. Every executable named in the file has the mitigations named in that file written to its registry entry, whatever was there before.

Why it happens: two levels, one XML, and settings that do not roll back

Follow the chain from a policy assignment down to a blocked API call. It runs in this order.

1. You configure mitigations on one reference device, in the Windows Security app or with Set-ProcessMitigation.
2. You export the result. Microsoft documents that export as writing all settings, system-level and app-level, into one XML regardless of which pane you exported from.
3. You deploy that XML by Group Policy or Intune. The policy value records either the file location or the XML content itself.
4. Windows reads the XML and writes the individual registry values for you. System-level values land in the Session Manager kernel key. Per-app values land in an Image File Execution Options subkey named after the executable.
5. A process starts. The loader reads that executable's Image File Execution Options entry. If there is no entry, the system default applies.
6. The mitigation is enforced by whichever component owns it. The memory manager blocks image loads. The kernel validates indirect call targets for CFG. GDI validates font file locations. The exception dispatcher walks the SEH chain.
7. A block or an audit is written to a Security-Mitigations event channel.

Step 4 is where the surprises live. The system-level and app-level values are stored separately, and the app-level value wins outright.

Microsoft publishes a truth table for that precedence. A mitigation set in Program settings is honoured above the same mitigation in System settings, in both directions. Turning DEP off system-wide and on for one executable gives you DEP on exactly one executable, and nowhere else.

The registry surface for the whole feature is small. Three parent keys hold everything:

Those value names are not folklore. They are the exact names in the removal script Microsoft publishes on its own troubleshoot exploit protection mitigations page. The policy key and value name come straight out of ExploitGuard.admx in C:\Windows\PolicyDefinitions, which declares the key as Software\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection and the value as ExploitProtectionSettings.

What each mitigation stops, and where audit mode really exists

This is the table people want and rarely get in one place. The audit column is the part worth reading twice, because audit availability depends on which surface you configure from.

The replace-and-tattoo behaviour, stated precisely

You will read in a lot of places that deploying an exploit protection XML wipes everything not in the file. That is not quite what Microsoft documents, and the nuance changes how you build the file. Three documented behaviours combine into the effect people describe.

First, export is total. The docs state plainly that exporting saves all settings for both app-level and system-level mitigations, from either pane. An XML produced by exporting a reference device therefore carries that device's entire posture, including things you never deliberately set.

Second, import is not a clean slate. Microsoft's troubleshooting page opens by saying the configuration export and import process "does not remove all unwanted mitigations", then supplies a script that deletes the registry values directly. Mitigations for an executable your XML never mentions survive the import.

Third, and this is the sharp edge, a reset is expressed as explicit false overrides. Microsoft's own reset file, EP-reset.xml from the Windows Security Baselines, works by naming each application and setting attributes such as OverrideDEP="false" and OverrideEnableExportAddressFilter="false". That is how you clear a mitigation: name it and override it back to default.

Put those together and the practical rule is simple. An exported XML from a clean reference machine is full of false override attributes, which is exactly why importing one appears to erase configuration you wanted to keep. It is not a wipe. It is a very long list of explicit instructions to go back to default, aimed at every app the reference machine happened to know about.

The rest of the surface, including the parts that do not exist

Working a surface checklist honestly means saying where there is nothing to find.

System files and binaries. There is no exploit protection service binary, because enforcement lives inside components you already have. C:\Windows\System32\win32k.sys and win32kfull.sys are the kernel-mode graphics components that Disable Win32k system calls exists to fence off. ntdll.dll, kernelbase.dll and kernel32.dll are the three modules Export address filtering protects by default, and EAF plus extends that to mshtml.dll, vbscript.dll, vgx.dll, mozjs.dll, xul.dll, acrord32.dll, acrofx32.dll, acroform.api and the Flash and JScript OCX families. The PowerShell surface is Microsoft.ProcessMitigations.Commands.dll, which sits in C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ProcessMitigations on a stock Windows 11 install. The Group Policy template is C:\Windows\PolicyDefinitions\ExploitGuard.admx.

Log files. There is no text log. Nothing writes a .log file you can grep for a mitigation block. What exists is two event channels, which back onto these two files on disk:

The string to search for is the process path in the event message. A healthy audit line reads "would have been blocked". An enforce line reads "was blocked". More on that below.

Services and scheduled tasks. No service drives exploit protection, and no scheduled task under \Microsoft\Windows\ applies it. Enforcement is in the kernel and the loader, and it happens at process start. Three services are adjacent but not load-bearing: SecurityHealthService (Windows Security Service) renders the settings page, WinDefend (Microsoft Defender Antivirus Service) owns the wider Defender stack, and Sense (Windows Defender Advanced Threat Protection Service) forwards mitigation events to Defender for Endpoint. Stopping all three would not disable a single mitigation.

Defender relevance. Exploit protection is one of the attack surface reduction capabilities in Defender for Endpoint. Its events surface in advanced hunting as DeviceEvents rows whose ActionType starts with ExploitGuard, in audited and blocked pairs such as ExploitGuardAcgAudited and ExploitGuardAcgEnforced. The Intune profile lives in the Endpoint security Attack surface reduction node, not in a Settings Catalog configuration profile.

How to verify: read the whole surface before you touch it

Verification comes first here for a reason. On a device you have never configured, the per-app override list is not empty, and you need to know what is already there before an XML rewrites it.

The first command reads the system-wide defaults. Run it elevated. It returns a named field for every mitigation rather than a bitmask.

Read that output as three states, not two. ON and OFF mean somebody wrote a value. NOTSET means nobody did. The distinction matters for rollback, because only the absent case returns to a true default when you reset.

The second command reads one executable's override. Swap in the process you care about.

Third, look at the registry directly, because the cmdlet will not hand you a countable list of every configured executable. Open Registry Editor and go to the Image File Execution Options key.

Fourth, check whether a policy XML is deployed at all. This single test tells you whether the device or the policy is authoritative.

Finally, read the event channels. This is where audit mode pays for itself, and where you will discover that mitigations are already firing on your fleet.

That wording difference is the fastest audit-versus-enforce test there is. Enforce events say was blocked. Audit events say would have been blocked. Here is the documented event ID catalogue for the channel.

Two more channels carry exploit protection evidence, and neither is a Security-Mitigations channel. Control flow guard blocks are documented against provider WER-Diagnostics, event ID 5. Untrusted font blocks are documented against provider Win32K, event ID 260.

On the Windows 11 build 26200 device I tested, the WER provider enumerates as Microsoft-Windows-WER-Diag writing to the channel Microsoft-Windows-WER-Diag/Operational, with werfault.exe as its resource file. I am reporting that as observed on a live device, not as a documented rename. Check the name on your own build before you write a query against the short form.

The fix: audit first, one versioned XML, a reset file on the shelf

The workflow Microsoft documents has four stages, and every one of them exists because this feature breaks applications when you skip it.

Stage 1: build the configuration on one reference device

Configure on a single dedicated device, then export. Both the UI path and the cmdlet are documented.

1. Open the Windows Security app from the shield icon in the taskbar, or search Start for Security.
2. Select the App & browser control tile, then Exploit protection settings.
3. Under System settings, set each mitigation to On by default, Off by default, or Use default.
4. Under Program settings, choose Add program to customize. Use Add by program name to match any process with that name, or Choose exact file path to scope the override to one path.
5. For each mitigation on that app, pick Audit rather than on, for the first round.
6. Select Apply. Restart the app, or Windows, if you are prompted to.
7. Scroll to the bottom of the Exploit protection section and select Export settings.

The cmdlet route writes the same file. Get-ProcessMitigation -RegistryConfigFilePath C:\ExploitConfigfile.xml is documented as reading the registry configuration and saving all of it to XML. If you are migrating from EMET, ConvertTo-ProcessMitigationPolicy -EMETFilePath policy.xml -OutputFilePath result.xml converts an old EMET policy file, and may also emit a companion code integrity file named CI-result.xml.

Stage 2: deploy it with Intune

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Endpoint security, then Attack surface reduction, then Create policy.
3. Set Platform to Windows 10, Windows 11, and Windows Server.
4. Set Profile to Exploit Protection, then select Create.
5. Give it a name that carries a version, for example ASR-ExploitProtection-v3-audit, then select Next.
6. On Configuration settings, set Exploit Protection Settings to Configured, then browse to and select your XML file.
7. Add scope tags if you use them, then assign to a pilot group of 10 to 50 devices. Do not assign to All devices.
8. Review and create.

Under the covers this is the ExploitGuard configuration service provider. The OMA-URI is ./Device/Vendor/MSFT/Policy/Config/ExploitGuard/ExploitProtectionSettings, the format is a string, and the value is the XML itself. Microsoft notes that the system settings in that XML require a reboot while the application settings do not.

If you use Configuration Manager instead, the same profile exists under Endpoint Security then Attack surface reduction, and the older path is Assets and Compliance then Endpoint Protection then Windows Defender Exploit Guard.

Stage 3: or deploy it with Group Policy

1. Open the Group Policy Management Console on your management workstation, or gpedit.msc for a single device.
2. Right-click the target Group Policy Object and select Edit.
3. Navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Exploit Guard > Exploit Protection.
4. Open Use a common set of exploit protection settings.
5. Select Enabled.
6. In Options, type the location of the XML file. A local path, a UNC path, or a URL are all accepted, for example \\contoso\share\Config.xml.
7. Select OK, then deploy the GPO as you normally would.

Note the naming drift on that Group Policy path. Before Windows 10 version 2004, the node reads Windows Defender Exploit Guard rather than Microsoft Defender Exploit Guard. Both point at the same policy. The registry key underneath still says Windows Defender ExploitGuard on current Windows 11, which matters when you write detection logic.

There is also a second, older Group Policy that people confuse with this one. Computer Configuration > Administrative Templates > System > Mitigation Options > Process Mitigation Options takes a per-executable bit field written as a string of 0, 1 and ? characters, read right to left. Microsoft documents six flags for it, covering DEP, DEP ATL thunk emulation, SEHOP, force ASLR, and bottom-up ASLR on and off. It is a different, narrower mechanism from the exploit protection XML, and using both at once is a good way to confuse yourself.

Stage 4: keep the reset file, and roll out slowly

Microsoft's own deployment guidance is a ring model. Start with 10 to 50 devices as a test group. Then user acceptance testing with IT, security and helpdesk staff. Then 1, 5, 10, 25, 50, 75 and finally 100 percent of the estate.

It also names the software classes you should never protect this way: anti-malware and intrusion detection or prevention software, debuggers, DRM-handling software such as games, and anything using anti-debugging, obfuscation or hooking technologies. Services, both system and network, are documented as out of scope. The applications worth protecting are the ones that receive or handle untrusted data.

Before the first ring, put the reset file somewhere you will find it in a hurry. Microsoft distributes EP-reset.xml with the Windows Security Baselines, and documents the import as one command: Set-ProcessMitigation -PolicyFilePath EP-reset.xml.

Proof it worked: a real read from a managed Windows 11 device

I wrote a read-only companion script, Get-ExploitProtectionState.ps1, that walks the whole surface in one pass: policy XML presence, system-level state, raw kernel values, every per-application override in Image File Execution Options, and the health of both event channels. It calls no write cmdlet and imports no XML. It lives in the Windows-11-Scripts repository.

Here is a genuine run on a managed Windows 11 Enterprise build 26200 device, with the hostname replaced. This is not illustrative output. It is what the script printed.

Read that as follows. Zero system-level settings, with both kernel values absent, means the machine is on pure Windows defaults, which is the normal and correct starting point. Sixty-nine per-application overrides means the feature is very much alive at app level without anyone deploying anything. Five hundred and twenty-four events on the kernel-mode channel means mitigations are firing daily.

Grouping those 524 events by ID on the same device produced 322 of ID 12, 95 of ID 25, 52 of ID 3, 47 of ID 10, 7 of ID 1, and 1 of ID 36. Four of those are in the documented table: 12 is a code integrity guard block, 3 is a child process audit, 10 is a win32k call block, and 1 is an arbitrary code guard audit.

IDs 25 and 36 are not in the table. Their message text identifies them as a shadow stack return address mismatch and a blocked NtFsControlFile system call, which map to Hardware-enforced stack protection and to the DisableFsctlSystemCalls field visible in Get-ProcessMitigation output.

The practical takeaway from that run is the one nobody expects. This device has no exploit protection policy, and it is still blocking things every day, including a code integrity guard block that fires 322 times a week against PowerShell loading a native image. If you deploy an XML that names powershell.exe, you inherit responsibility for that behaviour whether you meant to or not.

Two community deep-dives corroborate the deployment side of this and are worth reading alongside the Microsoft pages. I fetched both and confirmed they load and are on topic.

References

1. Exploit protection reference - every mitigation, its compatibility notes and configuration options, the Image File Execution Options MitigationOptions key, and the EP-reset.xml contents.
2. Turn on exploit protection to help mitigate against attacks - the system-versus-app scope table, the PowerShell keyword table, the Group Policy path, the Intune profile, and the safe deployment rings.
3. Apply mitigations to help prevent attacks through vulnerabilities - the event ID table, the advanced hunting ActionTypes, and the EMET comparison.
4. Import, export, and deploy exploit protection configurations - export and import behaviour, and the Group Policy distribution steps.
5. See how exploit protection works in a demo - audit mode, the mitigations on by default, the deprecated Program settings mitigations, and the application compatibility list.
6. Troubleshoot exploit protection mitigations - the registry value names, the Session Manager kernel values, and the removal script.
7. ExploitGuard Policy CSP - the ExploitProtectionSettings OMA-URI, the Group Policy mapping, the registry key name, and an audit-mode XML example.
8. Override Process Mitigation Options - the separate System, Mitigation Options Group Policy and its documented bit flags.
9. ProcessMitigations module - Get-ProcessMitigation, Set-ProcessMitigation and ConvertTo-ProcessMitigationPolicy.