EDR Tuning and Exclusions Management Guide: Reducing Noise Without Creating Blind Spots

Every EDR exclusion is a place on your endpoints where the security product has been told not to look, and most estates have hundreds nobody can explain. Exclusions arrive for good reasons: a database server slows down, a line-of-business application is quarantined, a backup agent conflicts with the sensor. They stay for bad ones: no owner, no expiry and no review, until the excluded folder becomes the attacker's staging area. This guide explains the difference between tuning and excluding, the order of controls to try, what must never be excluded, how to write a narrow exclusion, and how to govern and monitor the exclusion list so it does not drift. It is for endpoint engineers, SOC leads and detection engineers, and it uses Microsoft Defender for Endpoint and Elastic Defend documentation as worked examples; the principles apply to any EDR or antivirus product.

Key takeaways

• Tune the alert before you touch the sensor. Classifying, suppressing or scoping an alert keeps telemetry; an exclusion removes protection, and some types remove visibility too.
• Know what each exclusion type blinds. A Defender antivirus path exclusion still leaves EDR telemetry, a Linux global exclusion mutes both antivirus and EDR, and an Elastic Defend trusted application stops behaviour monitoring of that process.
• Never exclude shells, script hosts, user-writable folders or whole drives. Vendor guidance lists powershell.exe, cmd.exe, C:\Users\* and C:\Windows\Temp among the items you should not exclude even if you trust them.
• Every exclusion needs an owner, evidence and an expiry date. Keep exclusions as code in one register and review them on a fixed cycle.
• Lock the list and watch it. Disable local admin merge, tamper-protect exclusions and alert on every configuration change, because adding an exclusion is a quiet way to disable a security tool (ATT&CK T1685).

Tuning versus excluding: the control ladder

Most "the EDR is too noisy" problems are alert problems, not sensor problems. Work down this ladder and stop at the first rung that solves the issue. Microsoft's false positive guidance follows the same order: classify the alert, suppress it, undo any remediation, create allow indicators, submit the file to the vendor, and define exclusions only as a last resort.

Tune the SIEM copy too: Microsoft notes that if a SIEM receives the alerts, a matching suppression rule is needed there. See the SIEM Guide.

How exclusions behave in practice

• Antivirus exclusions are not EDR exclusions (Defender): Microsoft documents that antivirus exclusions apply to scheduled scans, on-demand scans, real-time protection and PUA detection, and that excluded files can still trigger EDR alerts and behavioural detections. To exempt a file across all Defender for Endpoint features, Microsoft points to custom indicators instead.
• Process exclusions are the most sensitive type: excluding a process excludes every file it opens, and Microsoft states that process exclusions also stop network protection and attack surface reduction rules from inspecting that process.
• Linux has two very different modes: Defender for Endpoint on Linux offers antivirus exclusions, which keep EDR visibility, and global exclusions, which mute both antivirus and EDR for the path.
• Order of evaluation matters: in Microsoft's documented Windows order, an antivirus exclusion is evaluated before a block file indicator, so an exclusion can let through a file you have explicitly blocked. EDR in block mode also respects antivirus exclusions but not indicators.
• Trusted processes can be hijacked: Elastic's documentation states that trusted applications are blind spots because they are not monitored for threats, and warns that attackers can use DLL side-loading to run malicious code inside a trusted vendor's signed process (ATT&CK T1574 Hijack Execution Flow).
• Automation exclusions are different again: Defender's automation folder exclusions stop automated investigation and remediation acting on a path without stopping detection. Use them where the SOC must handle a location manually.
• Attack surface reduction exclusions: can be global or per rule. Per-rule exclusions are narrower and should be the default.

Product names and semantics change between versions. Before writing any exclusion, check the current documentation for your product and record which features it affects.

What not to exclude

These come from Microsoft's published list of exclusions to avoid, which applies to Windows, macOS and Linux and says the items should not be excluded even if trusted. The principle generalises to any product: never exclude anything an attacker can write to or run code through.

See the Living off the Land Guide and the Top 10 EDR Evasion Techniques.

Writing a narrow exclusion

• Use full paths, not bare file names: Microsoft notes that a bare name such as Filename.exe is not a reliable exclusion on Windows and that file-name exclusions on macOS and Linux can match unrelated files with the same name.
• Resolve environment variables as SYSTEM: the Defender service runs as LocalSystem, so %TEMP% resolves to C:\Windows\TEMP, and %APPDATA%, %LOCALAPPDATA% and %USERPROFILE% resolve under C:\Windows\System32\config\systemprofile, not the user's profile. An exclusion that "did not work" is often this.
• Limit wildcards: Defender allows at most six wildcards per entry and none in place of a drive letter. Each wildcard widens the hole; prefer one exact path per location.
• Do not exclude mapped drives: use the actual network path.
• Prefer contextual or conditional exclusions: a contextual exclusion narrows a path exclusion to a specific process or scan type. In products that support it, add signer and hash conditions, accepting that hash-only entries break on every update, as Elastic notes.
• One list per workload: Microsoft advises separate exclusion lists for each application or service, for example IIS separately from SQL Server, and checking the automatic Windows Server role exclusions (Active Directory Domain Services, DNS, Hyper-V, SYSVOL) before adding custom ones. Exchange, SharePoint and SQL Server need custom exclusions taken from those vendors' own guidance.
• Scope to device groups: an exclusion needed on twelve database servers should not apply to 20,000 laptops.
• Mutual exclusions between security products: when two endpoint security products coexist, each must exclude the other's binaries. Keep these in the register like any other exclusion.

Performance-driven tuning

Performance complaints are the most common source of broad exclusions, and the least evidenced. Measure before excluding.

1. Reproduce the slowdown on one affected device.
2. Record antivirus activity with the vendor's tooling. On Defender this is the performance analyzer: New-MpPerformanceRecording -RecordTo <file>.etl, then Get-MpPerformanceReport -Path <file>.etl -TopFiles 10 -TopScansPerFile 10 for the files, paths, extensions and processes taking the most scan time.
3. Check whether scans are already skipped: newer reports include a SkipReason column showing Optimization or User skipped.
4. Confirm the hot path or process is trusted, not user-writable, and owned by an application team.
5. Exclude the narrowest item (a specific data file path, not the folder that also holds executables), on the affected device group only.
6. Re-record to prove the gain. If there is no measurable improvement, remove the exclusion.

The analyzer shows where scan time goes, not whether a file is safe; that judgement stays with the engineer.

Exclusion lifecycle and governance

Treat the exclusion list as a security policy under change control (NIST SP 800-53 CM-3). Store it as code in a repository that deploys to the management plane, so every change has an author, a reviewer and a history.

1. Request: the requester states the symptom and evidence, not the exclusion they want.
2. Triage: security tries rungs 1 to 6 of the control ladder first.
3. Design: write the narrowest exclusion and list its compensating controls.
4. Pilot: apply to a test device group, confirm the fix, confirm detections still fire with a benign test.
5. Deploy: merge to the repository, deploy by policy only, never locally.
6. Review and expire: owners reconfirm each exclusion at expiry; unconfirmed entries are removed automatically. Re-check after the application is upgraded, because paths change and the old exclusion becomes an unused hole.
7. Rollback: if an exclusion removal breaks a service, restore it from the repository with a short expiry and reopen the ticket, rather than adding a broader one in a hurry.

Protecting exclusions from tampering and drift

An attacker with administrator rights who cannot disable the sensor may simply add an exclusion for their tools folder. ATT&CK v20 covers this under T1685 Disable or Modify Tools, and registry-based changes under T1112 Modify Registry. See the EDR Evasion and Defence Guide.

• Disable local admin merge: by default Defender merges locally defined exclusions with those from Group Policy, Configuration Manager or Intune. The Group Policy setting Configure local administrator merge behavior for lists (Intune: Disable local admin merge) makes only managed lists apply. Microsoft notes that the value that disables merging differs between administrative template versions, so test it.
• Tamper-protect exclusions: Defender protects exclusions only when the device runs platform 4.18.2211.5 or later, local admin merge is disabled, and the device and its exclusions are managed by Intune only or Configuration Manager only (co-managed devices do not qualify). The read-only registry value HKLM\SOFTWARE\Microsoft\Windows Defender\Features\TPExclusions = 1 confirms protection is active.
• Alert on configuration changes: Defender event ID 5007 records old and new configuration values, and event 5013 records a change blocked by tamper protection. Forward both to the SIEM and alert when a new exclusion appears outside a change window.
• Reconcile effective against intended: periodically export the effective exclusions from devices (on Windows, Get-MpPreference returns ExclusionPath, ExclusionExtension and ExclusionProcess) and diff them against the register. Any difference is drift or tampering.
• Restrict who can edit policy: the console role that edits exclusions is a privileged role. Require phishing-resistant MFA and just-in-time elevation. See the Endpoint Privilege Management Guide.

Where identity fits

Many exclusion requests are really identity questions. Backup agents, vulnerability scanners and deployment tools run under service accounts that perform privileged actions all day, and joint CISA, NSA and FBI guidance notes that this legitimate volume can bury analysts if it is not categorised. The answer is to tag those accounts and tune detections on account plus host plus behaviour, not to exclude the tool's process or folder. If the service account is compromised, a process exclusion turns its credentials into an unmonitored execution path. See the Local Administrator Password Solution (LAPS) Guide for local admin accounts and the EDR Guide for console access.

Measuring tuning quality

• Total exclusions by type and scope: with process, global and trusted application entries reported separately. The trend should be flat or falling.
• Register coverage: percentage of effective exclusions on devices that match a register entry with owner and expiry. Target 100 per cent.
• Expired exclusions still deployed: target zero.
• False positive rate per rule: from alert classification; the top ten rules by false positives go to the tuning backlog each month.
• Suppression rule hit counts: rules that never fire are stale; rules that fire thousands of times may be hiding something.
• Detection validation after tuning: share of scheduled benign attack simulations that still produce the expected alert on excluded paths and tuned rules.

Framework mapping

Common failure patterns

• Vendor install guide copied wholesale: a third-party application's documentation lists its whole program folder and a scripting runtime; the list is pasted in globally and never questioned.
• Temporary exclusion made permanent: added during an outage with no expiry, still present three years and two application versions later.
• Exclusion as alert fix: a noisy behavioural alert on a deployment tool is "fixed" by excluding the tool's process, which also removes network protection and attack surface reduction inspection for everything it launches.
• Environment variable surprise: %TEMP% was meant to exclude a user's temp folder but resolved to C:\Windows\Temp, so the wrong location was excluded and the complaint remained, prompting a broader exclusion.
• Local exclusions nobody sees: local admin merge left enabled, so administrators and malware add exclusions that never appear in the central policy.
• Broad suppression rules: a suppression keyed only on a file name or a single command-line fragment silences a later real attack using the same binary.

Practitioner checklist

• Export every effective exclusion from a sample of devices per group and reconcile against a single register.
• Remove or narrow any exclusion of drives, user folders, temp folders, shells, script hosts or Office processes.
• Adopt the control ladder: classify, fix the rule, suppress, submit, indicator, and only then exclude.
• Require owner, evidence, features affected, compensating controls and expiry for every exclusion.
• Manage exclusions as code and deploy them by policy only, scoped to device groups.
• Disable local admin merge and confirm exclusions are tamper protected.
• Alert on configuration change events and on any exclusion not in the register.
• Use performance recordings to justify performance exclusions and re-measure after applying them.
• Review the exclusion list and the noisiest rules monthly, and after every major application upgrade.

Standards and references

• Microsoft Learn: Exclusions to avoid in Microsoft Defender Antivirus
• Microsoft Learn: Exclusions and indicators in Microsoft Defender for Endpoint
• Microsoft Learn: Address false positives and negatives in Microsoft Defender for Endpoint
• Microsoft Learn: Manage tamper protection using Intune
• Elastic: Trusted applications in Elastic Defend
• CISA, NSA, FBI and partners: Identifying and Mitigating Living Off the Land Techniques
• MITRE ATT&CK: Disable or Modify Tools (T1685)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: EDR Guide · EDR Evasion and Defence Guide · Microsoft Defender for Endpoint Guide · SOC Guide · Endpoint Security Guide