{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "slug": "dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions", "url": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/" }, "title": "Match exploit-protection scope to executable names and paths, not assumed versions", "summary": "Can an exploit-protection application target distinguish versions or architectures sharing one executable name?", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:24:16+00:00", "modified_at": "2026-09-10T02:08:04+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 248, "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.", "primary_source": { "name": "Exploit protection reference - Microsoft Defender for Endpoint | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

Microsoft Learn: Exploit protection reference. Source reviewed September 9, 2026.

", "content_text": "Source facts\nExploit-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.\nApplicability\nUse 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.\nDSE recommendation\nCompare 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.\nVerification\nOn 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.\nOfficial references\nMicrosoft Learn: Exploit protection reference. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nExploit-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).\n\n## Applicability\n\nUse 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.\n\n## DSE recommendation\n\nCompare 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.\n\n## Verification\n\nOn 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.\n\n## Official references\n\n[Microsoft Learn: Exploit protection reference](https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference). Source reviewed September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "url": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Match exploit-protection scope to executable names and paths, not assumed versions", "item": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "url": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/", "headline": "Match exploit-protection scope to executable names and paths, not assumed versions", "description": "Can an exploit-protection application target distinguish versions or architectures sharing one executable name?", "abstract": "Can an exploit-protection application target distinguish versions or architectures sharing one executable name?", "articleBody": "Source facts\nExploit-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.\nApplicability\nUse 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.\nDSE recommendation\nCompare 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.\nVerification\nOn 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.\nOfficial references\nMicrosoft Learn: Exploit protection reference. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:24:16+00:00", "dateModified": "2026-09-10T02:08:04+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-460-match-exploit-protection-scope-to-executable-names-and-paths-not-assumed-versions/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Match exploit-protection scope to executable names and paths, not assumed versions" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Briefing", "Information priority" ], "genre": "Briefing", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 248, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Exploit protection reference - Microsoft Defender for Endpoint | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference" } } ] } }