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

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.

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. Source reviewed September 9, 2026.