# Match exploit-protection scope to executable names and paths, not assumed versions

> Can an exploit-protection application target distinguish versions or architectures sharing one executable name?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:16+00:00
- Modified: 2026-09-10T02:08:04+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Briefing
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Can an exploit-protection application target distinguish versions or architectures sharing one executable name?

## Potentially affected

Windows application deployments receiving per-application exploit-protection mitigations.

## DSE recommendation

Compare the executable target with every deployed version and architecture that can match it before assigning a mitigation.

## Article

## Source facts

Exploit-protection application targeting accepts an executable name or path, not a version number or architecture selector. Microsoft therefore advises unique names or paths and deployment only where the particular application version and architecture were tested. Mitigation changes take effect when the program restarts and remain until changed and restarted again. Removing the Group Policy or MDM policy that supplied an XML configuration does not automatically remove its settings. [Microsoft Learn](https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference).

## Applicability

Use this boundary when one executable identity represents several installed builds or when application placement changes during an upgrade. The targeting mechanism does not substitute for an inventory of the actual binaries within the proposed device scope.

## DSE recommendation

Compare the executable target with every deployed version and architecture that can match it before assigning a mitigation. Ask the application owner to identify side-by-side installations, renamed executables and differing installation paths. Restrict the assignment to the tested population, and make an application upgrade trigger a renewed scope review. Plan explicit restoration of the intended mitigation settings instead of assuming policy removal will undo the change.

## Verification

On representative test devices, record the executable identity, version, architecture and effective mitigation configuration. Restart the application under controlled conditions and exercise its important workflows. Check a deliberately out-of-scope installation to confirm the proposed targeting boundary. During rollback testing, inspect the resulting settings and repeat the application check after restart; successful policy removal is not the final acceptance result.

## Official references

[Microsoft Learn: Exploit protection reference](https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference). Source reviewed September 9, 2026.

## Primary reference

- Name: Exploit protection reference - Microsoft Defender for Endpoint | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Match exploit-protection scope to executable names and paths, not assumed versions,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.