Exclusions tell the Defend detection engine to ignore specific files, paths, or processes so they do not generate alerts. They are the primary tuning mechanism for reducing noise from known-good software — backup agents, monitoring tools, line-of-business applications — that would otherwise trigger rules repeatedly. Use exclusions carefully and specifically; overly broad exclusions can hide real threats.
When to Use Exclusions
Create an exclusion when:
- A specific process or file path is generating repeated false positive alerts.
- You have confirmed the activity is legitimate and expected.
- You have a narrow enough scope to exclude only the specific path or process rather than a broad directory.
Do not create exclusions as a first response to noisy alerts. First mark the alerts as false positives and investigate whether a rule sensitivity adjustment in Policies is a better fit.
Adding an Exclusion
- Go to Settings → Exclusions.
- Click Add Exclusion.
- Choose the exclusion type:
- File path — exclude a specific file by its full path.
- Directory path — exclude all events from a directory. Use sparingly.
- Process name or path — exclude events generated by a specific process.
- Enter the path or process identifier.
- Set the scope (see below).
- Add a note explaining why the exclusion exists and who approved it.
- Save.
Exclusion Scope
Exclusions can be scoped to control where they apply:
| Scope | Effect |
|---|---|
| Global | Applies across all client organizations in your MSP tenant |
| Per client | Applies only to the specified client organization |
Use global scope only for exclusions that are safe and expected for every client — for example, a widely deployed monitoring agent you manage yourself. Per-client scope is safer for software that is specific to one environment.
Caution: What Exclusions Do Not Block
Exclusions suppress detection alerts for the specified item. They do not:
- Prevent events from being recorded in the event warehouse. An exclusion suppresses the alert, not the record — the activity stays in the warehouse, and any surface that reads it (an alert on another rule, a case, a device timeline) can still surface it. Threat hunts are retired on this arm (
hunt_store_retired), so they are not the surface that will. - Apply to IOC matching. If an excluded process makes a connection to a known-bad IP, a threat intelligence alert can still fire.
- Apply retroactively. Existing alerts on an excluded path are not automatically resolved.
Managing Existing Exclusions
Review exclusions periodically. An exclusion created for a specific software version may be too broad after an upgrade, or the software may have been removed from client devices. Stale exclusions accumulate blind spots.
To review:
- Go to Settings → Exclusions.
- Sort by creation date to find old exclusions.
- Check the note field — exclusions without notes are candidates for review or removal.
- Delete exclusions that are no longer needed.
FAQ
Can I exclude by hash instead of path? The exclusions interface accepts file paths and process names. For hash-based suppression, use the rule tuning options in the detection rule itself.
Will an exclusion stop alerts for both rule-based and UEBA detections? Exclusions apply at the path and process level across detection types. A process exclusion suppresses both rule-based alerts and UEBA anomalies for that process.
How specific should a path exclusion be?
As specific as possible. Excluding C:\Program Files\BackupAgent\backup.exe is appropriate. Excluding C:\Program Files\ is not — it would suppress detections for every application in that directory.