Microsoft Defender Antivirus exclusions design

Microsoft Defender Antivirus exclusions tell the AV engine to skip scanning specific paths, processes, or file types. They're sometimes necessary — some database engines, line-of-business apps, and developer tools genuinely need exclusions to function — but every exclusion is a hole in your defences. Designing them carefully matters.

Why exclusions are sometimes required

Common scenarios where exclusions are genuinely needed:

• Database servers — SQL Server, Oracle, PostgreSQL files have heavy I/O patterns that AV scanning slows dramatically.
• Backup software — products like Veeam, Acronis read all files; AV scanning during backups creates performance issues.
• Developer tools — node_modules folders, .git directories, Visual Studio temp folders generate constant churn.
• Specific line-of-business apps — some apps have file types or behaviours that produce false positives.
• Virtualisation hosts — Hyper-V VHD files, VMware files.
• Antivirus interactions — running a third-party scanner alongside Defender Antivirus requires excluding the third-party engine's files.

Microsoft publishes recommended exclusions for common scenarios (SQL Server, Exchange, Hyper-V). Use these as authoritative starting points, not internet rumours.

The three exclusion types

Defender supports three types:

Path exclusions

A specific file or folder path is skipped:

C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\
*.mdf

The most powerful and most dangerous exclusion type. Files in excluded paths get no scanning at all.

Process exclusions

Files opened by a specific process are skipped:

sqlservr.exe

When SQL Server reads or writes its data files, those operations aren't scanned. When any other process (an attacker, malware) reads the same files, those operations are scanned.

This is dramatically safer than path exclusions and the preferred approach where supported.

File-extension exclusions

Files with a specific extension are skipped:

.mdf
.ldf

Broad and dangerous — every file with that extension anywhere on the system is skipped. Rarely the right answer.

Designing exclusions safely

Best practices:

Minimum scope

Use the narrowest exclusion that works:

• Process exclusion over path exclusion if the application supports it.
• Specific folder over broad parent folder.
• Specific extension over broad extension.

The goal: skip the minimum necessary for performance / functionality, scan everything else.

Documented and justified

Every exclusion needs documentation:

• Why the exclusion is needed.
• Owner for the exclusion.
• Review date for periodic re-evaluation.
• Threat consideration — what risk this opens.

Without documentation, exclusions accumulate and rot.

Microsoft-published recommendations

For common applications, use Microsoft's published recommendations rather than community guesses:

• SQL Server: Microsoft publishes specific recommended exclusions.
• Exchange Server: same.
• Hyper-V: same.
• Active Directory: same.
• SharePoint Server: same.
• System Center products: same.

Microsoft's exclusion guidance is informed by both performance and attack-pattern analysis. It's the right starting point.

Avoid path exclusions on user-controlled paths

Never exclude paths users can write to:

• Don't exclude C:\Users\ or any subset.
• Don't exclude Downloads, Temp, or similar.
• Don't exclude OneDrive sync folders.

These create wide attack surfaces.

Process exclusions for developer tools

For developer workstations, exclude the developer's tools' processes rather than the directories they write to:

• node.exe, npm.exe, yarn.exe.
• code.exe, devenv.exe.
• git.exe.

Files those processes touch are skipped by AV; files an attacker drops in node_modules are still scanned if accessed by other processes.

What still scans

Even with exclusions in place, Defender for Endpoint's other protections continue:

• Behavioural monitoring still watches what processes do.
• Network protection still blocks malicious destinations.
• Attack Surface Reduction rules still block exclusion-bypass techniques.
• Tamper protection still prevents disabling Defender.
• EDR signals still flow into Defender XDR.

Exclusions skip AV scanning specifically; the broader Defender stack continues.

Auditing exclusions

Periodically audit:

• List all exclusions in your Intune / Group Policy / PowerShell.
• Are they still needed? Apps move, configurations change.
• Are they too broad? Tighten where possible.
• Are they documented? If not, document or remove.

For mature security operations, an annual exclusions review is standard practice. Things that started as "we need this exclusion for the migration" become permanent unless reviewed.

When in doubt, don't exclude

If you're not sure an exclusion is necessary, don't add it. Performance impact from Defender on modern hardware is usually negligible. The exclusion you add today is the back door an attacker uses next year.

For Microsoft 365 customers with Defender for Endpoint deployed, exclusions discipline is one of the small but cumulative differences between strong defence and fragile defence.