Exploit protection is the built-in Windows feature that applies exploit mitigations to the operating system and to individual programs, making it harder for an attacker to turn a software bug into running code. It enforces techniques such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) and Control Flow Guard (CFG), either system-wide or per executable.
Within Windows security, exploit protection is the successor to the discontinued Enhanced Mitigation Experience Toolkit (EMET). It was introduced in Windows 10 version 1709 as part of Windows Defender Exploit Guard and is managed today from the Windows Security app, PowerShell, Group Policy or Microsoft Intune. It works independently of the antivirus engine, so it remains active even when a third-party antivirus product is installed.
How exploit protection blocks attacks
Exploit protection does not look for malware signatures. It changes the rules of the process environment so that the standard steps of a memory corruption exploit fail. A typical exploit needs to know where code lives in memory, write a payload somewhere, and redirect execution to it; each mitigation breaks one of these steps.
- Randomization hides memory addresses, so the attacker cannot predict where useful code or data is located.
- Execution restrictions prevent data regions such as the stack and heap from running as code.
- Control flow validation checks that indirect calls and returns go to legitimate targets.
- Attack surface restrictions stop a process from loading remote images, untrusted fonts or child processes it never needs.
When a mitigation is violated, Windows terminates the process or, in audit mode, logs the event without blocking. Violations are recorded in the event logs under Security-Mitigations, which gives administrators evidence of attempted exploitation or of an incompatible application.
System-level mitigations and their defaults
System settings apply to every process unless a program-specific override exists. Most are enabled by default on current Windows versions, while a few stronger options are disabled because they can break older software.
| Mitigation | What it prevents | Default |
|---|---|---|
| Control Flow Guard (CFG) | Indirect calls to unexpected addresses | On |
| Data Execution Prevention (DEP) | Running code from data pages | On |
| Force randomization for images | Loading modules at predictable addresses (mandatory ASLR) | Off |
| Bottom-up ASLR | Predictable memory allocation locations | On |
| High-entropy ASLR | Brute forcing of 64-bit address layouts | On |
| Validate exception chains (SEHOP) | Overwriting structured exception handlers | On |
| Validate heap integrity | Exploiting corrupted heap structures | On |
Mandatory ASLR is off by default for a good reason: forcing relocation of images that were not compiled for it can cause crashes in legacy applications. Enabling it system-wide is a high-value but high-risk change that should be tested first.
Program-specific mitigations
Program settings let administrators apply stricter mitigations to individual executables, typically internet-facing software such as browsers, document readers, email clients and media players. Many of these options inherited their design from EMET.
| Mitigation | Purpose | Audit mode |
|---|---|---|
| Arbitrary code guard (ACG) | Blocks creating or modifying executable code at runtime | Yes |
| Code integrity guard | Allows only Microsoft-signed images to load | Yes |
| Do not allow child processes | Stops a process from launching other programs | Yes |
| Block remote images | Prevents loading DLLs from network paths | Yes |
| Block untrusted fonts | Prevents loading fonts from outside the system folder | Yes |
| Export address filtering (EAF) | Detects shellcode resolving API addresses | Yes |
| Hardware-enforced stack protection | Uses CPU shadow stacks against return-oriented programming | Yes |
| Disable Win32k system calls | Removes a large kernel attack surface | Yes |
Some of these options, such as ACG and Win32k system call filtering, are already used internally by modern browsers for their sandboxed processes. Applying them manually to a complex application without testing is a common source of crashes, because just-in-time compilers and plugins often need runtime code generation.
How it compares with other Windows protections
Exploit protection addresses a specific stage of an attack: the moment a vulnerability is triggered. Other Windows security features cover different stages, and they are designed to work together rather than replace one another.
| Feature | Stage of attack addressed | Approach |
|---|---|---|
| Exploit protection | Exploitation of a vulnerability | Memory and process hardening |
| Microsoft Defender Antivirus | Malicious files and behavior | Signatures, heuristics, cloud analysis |
| Attack surface reduction rules | Abuse of legitimate tools and documents | Behavior-based blocking rules |
| Memory integrity | Kernel code tampering | Virtualization-based code integrity |
| Smart App Control | Running unknown or untrusted applications | Reputation and signature checks |
| Controlled folder access | Ransomware encrypting files | Folder write protection |
A practical distinction is that exploit protection helps against unknown vulnerabilities, including zero-day flaws, because it targets techniques rather than specific malware. It does not, however, stop an attack that uses a legitimate feature without memory corruption, such as a malicious macro.
Configuration and deployment
On a single device, exploit protection is configured in Windows Security under App and browser control. In managed environments, the settings are exported to an XML configuration file and distributed centrally, so that every machine receives the same tested policy.
- PowerShell:
Get-ProcessMitigationshows the active settings andSet-ProcessMitigationchanges them, including importing an XML policy file. - Group Policy: the setting Use a common set of exploit protection settings points devices to a shared XML file.
- Microsoft Intune and Configuration Manager: endpoint security profiles deploy the same XML at scale.
- Audit first: run new mitigations in audit mode, review Security-Mitigations events, then enforce.
The most frequent mistakes are enabling mandatory ASLR or code integrity guard globally without testing, forgetting that a program override can weaken a system default, and leaving no record of why an exception was granted for a legacy application.
Put simply
Many attacks work by tricking a program into running instructions it was never meant to run. Exploit protection makes that much harder. It shuffles where things are stored in memory and refuses to run code from places that should only hold data.
Imagine a burglar who has studied a building’s floor plan. Exploit protection rearranges the rooms every time and locks the doors that should never be used. The key takeaway is that it blocks the tricks attackers use, even when the specific weakness is still unknown.
In practice
An IT administrator at a law firm with 150 Windows 11 laptops wants extra protection for the PDF reader and the email client, the two programs that open files from outside the firm. She enables code integrity guard, block remote images and do not allow child processes for both executables in audit mode.
After two weeks, the event logs show that an add-in for the PDF reader loads an unsigned DLL, so she keeps code integrity guard in audit for that program and enforces the other two mitigations. She exports the policy as XML and deploys it through Intune. A few months later, a phishing attachment tries to launch a script from the PDF reader, and the child process is blocked before any payload runs.