Endpoint Security · Microsoft Defender for Endpoint · MDE Policy · 8 Min Read

Microsoft Defender for Endpoint Antivirus Policy Best Practices

Default MDE settings are built for compatibility, not enterprise security. Organizations that leave defaults in place are exposed to ransomware and lateral movement. Those that indiscriminately apply "Block All" halt production. Here is the tiered architecture that delivers both.

February 2026·8 min read
⚠️The Problem with Defaults

Default Microsoft Defender settings are calibrated for maximum compatibility — not maximum security. In enterprise environments running human-operated ransomware campaigns, this creates critical blind spots that attackers exploit within hours of initial access.

🏗️The Architecture

A mission-critical SQL server cannot tolerate the same real-time scanning overhead as an HR workstation. Effective endpoint security requires a tiered policy model: Workstations, General Servers, and Mission-Critical Systems each demand distinct configurations.

📋The Compliance Angle

NIS2 Article 21 mandates "Basic Cyber Hygiene." Deploying MDE with default settings can be interpreted as negligence during a supervisory audit. These specific configurations directly demonstrate the proactive technical measures the directive requires.

🔧Day 2 Reality

Configuration is only the first step. The real challenge is maintaining security posture against a shifting threat landscape — managing false positives before the business demands you lower the security settings, and handling developer exceptions without creating policy gaps.

Why Defaults Fail Enterprise Environments

Microsoft Defender for Endpoint has displaced traditional third-party antivirus agents in the enterprise. Its telemetry depth, integration with the Microsoft security stack, and cloud-based detection capabilities make it a genuinely tier-1 security solution. However, its effectiveness is entirely dependent on its configuration.

Our consultants consistently observe the same pattern across Dutch enterprise environments: organizations deploy MDE but leave the default antivirus policies active. This "set-and-forget" approach assumes that Microsoft's defaults are designed for maximum security. They are not.

Default settings are designed for maximum compatibility. They prioritize ensuring that no legacy application breaks over stopping sophisticated threats. In the current landscape of human-operated ransomware — where attackers spend days or weeks inside a network before triggering encryption — compatibility-first configurations create the blind spots that attacks require.

The opposite problem is equally common.

We frequently audit environments where IT teams have indiscriminately applied "Block All" settings, resulting in halted production lines, blocked developer build tools, and C-level complaints about system performance. Effective endpoint security requires a balanced architecture — not a binary choice between default and maximum aggression.

The Tiered Policy Architecture

One policy cannot rule them all. We recommend a three-tier architecture that reflects the operational reality of different system types:

💻
Tier 1

Workstation Policy

End-user devices: laptops, desktops. High behavioral detection, aggressive cloud blocking, standard CPU throttling. Users tolerate occasional false positives; the security benefit outweighs the friction.

🖥️
Tier 2

Server Policy

General-purpose servers: file servers, application servers, domain controllers. Reduced CPU throttling to protect service availability. Stricter sample submission controls for data sovereignty.

Tier 3

Mission-Critical Policy

Production systems with strict SLAs: payment processing, SQL clusters, IoT management platforms. Minimal scan overhead, tightly constrained cloud timeouts, full data sovereignty on sample submission.

Key Areas to Customize

Eighteen settings in the MDE antivirus policy require deliberate review for enterprise environments. The areas that account for the majority of misconfiguration incidents we diagnose are: behavioral monitoring engine enablement, cloud protection aggressiveness, scan scheduling and CPU throttling for servers, and sample submission consent for GDPR compliance.

Configuration Matrix: 3 Critical Settings

The following shows how three of the most consequential settings differ across policy tiers. Our complete configuration matrix covers all 18 settings — contact us to receive the full reference.

SettingWorkstationsServersMission Critical
Cloud Block LevelHighHighHigh
Avg CPU Load Factor (Scheduled Scans)50%30%20%
Submit Samples ConsentSend All (Auto)Never / PromptNever Send

Cloud Block Level — NPS Advisory

Determines how aggressive MDE is with unknown files. "High" is the enterprise standard — but it will eventually block a legitimate line-of-business application. Do you have a tested workflow for analyzing and whitelisting false positives within 60 minutes? Without one, your Service Desk will pressure you to lower this setting — and your security posture with it.

Avg CPU Load Factor (Scheduled Scans) — NPS Advisory

Controls how much CPU a scheduled scan can consume. The default 50% is too high for production servers. We have diagnosed "random SQL query timeouts" that traced back to scan throttling misconfiguration. The right value depends on the peak CPU utilization pattern of each server role — not a generic best practice.

Submit Samples Consent — NPS Advisory

GDPR / Data Sovereignty check. Automatically sending file samples from servers to Microsoft can result in sensitive customer data leaving your legal jurisdiction. We have seen organizations fail GDPR audits because "Send All Samples" was active on servers processing customer PII. The fix requires knowing which servers have sensitive data flows — not just changing this setting.

Exclusive Resource

Need the Complete 18-Setting Matrix?

The three settings above are a preview. The full configuration matrix covers all 18 MDE antivirus policy settings across all three tiers — including Attack Surface Reduction rules, scheduled scan windows, network protection levels, and exclusion management guidance.

Request the Full MDE Configuration Matrix

Day 2 Operations: Where Deployments Fail

Implementing the correct settings is only the first step. The true challenge is maintaining security posture against a shifting threat landscape. This is the primary reason organizations partner with us on MDE deployments rather than managing configuration alone.

🚨

Managing False Positives Before the Business Manages You

When Cloud Block Level is set to "High," the engine becomes more aggressive. It will eventually block a legitimate line-of-business application or an obscure Excel macro used by Finance. The challenge is response time: if your Service Desk cannot analyze and whitelist a false positive within 60 minutes, the business will demand you lower the security settings. We use a Submission First workflow — validating the file in a cloud sandbox before creating a global allowance indicator — that keeps response time under 30 minutes without creating permanent policy gaps.

👨‍💻

The Developer Exception Problem

The most common cause of failed MDE deployments is developer revolt. Compilers and build tools — Visual Studio, Docker, Node.js build chains — behave in ways that trigger heuristic algorithms. They look exactly like ransomware encryption to the behavioral engine: rapid file creation, process injection, memory manipulation. The answer is not a blanket developer exclusion, which creates a security gap you cannot defend during an audit. It requires process-specific exclusions with compensating controls — and the operational knowledge of which paths are safe to exclude without creating blind spots.

Compliance Context: NIS2 and GDPR

🛡️

NIS2 Directive (Article 21)

NIS2 Article 21 explicitly mandates "Basic Cyber Hygiene" including antivirus and endpoint protection. Deploying MDE with default settings may be interpreted as negligence during a supervisory audit by the Dutch RDI (Rijksinspectie Digitale Infrastructuur). Enabling behavioral monitoring, cloud protection at "High," and Attack Surface Reduction rules demonstrates the proactive technical measures the directive requires.

🔒

GDPR & Data Sovereignty

The Sample Submission setting creates a direct GDPR exposure. "Send All Samples (Auto)" may transmit customer PII-containing documents to Microsoft's global analysis infrastructure outside your legal jurisdiction. For servers processing customer data, the correct configuration is "Never Send" or "Prompt" — which requires first knowing which servers have sensitive data flows. If you cannot answer that in 30 seconds, you have a data mapping problem, not just a Defender configuration problem.

"

"We initially struggled with performance issues on IoT systems after enabling Defender for Endpoint. The New Paradigm Security team re-architected our policy hierarchy, introducing the correct exclusions, CPU throttling and adjusting scans. We achieved full compliance without any added latency."

— IT Risk Director, Global Pharma Company (NPS Customer)

How We Deploy MDE for Enterprise Clients

Our MDE practice covers the full deployment lifecycle: policy design across all three tiers, false positive workflow implementation, developer exclusion governance, and ongoing policy tuning as new applications are deployed.

We have deployed MDE across Retail, Finance, and Logistics environments in the Netherlands and Benelux. Our standard baseline has been validated against NIS2 supervisory expectations and GDPR data sovereignty requirements. If your current deployment was a "set-and-forget," a configuration audit typically reveals three to five critical gaps within the first hour.

01

MDE Configuration Audit

Review of your current antivirus policy settings against our three-tier baseline. We identify gaps in behavioral monitoring, cloud protection aggressiveness, CPU throttling, and sample submission consent — and deliver a prioritized remediation plan.

02

Tiered Policy Deployment

Design and deployment of Workstation, Server, and Mission-Critical policies via Microsoft Intune or Group Policy. Includes exclusion framework, false positive workflow documentation, and handover to your IT operations team.

03

NIS2 & GDPR Compliance Alignment

Documentation of MDE configuration as evidence for NIS2 Article 21 "Basic Cyber Hygiene" requirements. Sample submission controls aligned with your GDPR data mapping and legal jurisdiction requirements.

Is Your MDE Configuration Audit-Ready?

We offer a free 30-minute MDE configuration review: audit your current policy settings against our three-tier baseline and identify the gaps your next NIS2 supervisor will find.

Book a Free MDE Configuration Review

Configuration Is Not a One-Time Event

MDE policy configuration is not a project you complete and move on from. New applications require exclusion reviews. New server workloads require CPU throttling adjustments. New regulatory requirements — NIS2 enforcement activity, GDPR audit cycles — require evidence that your configuration choices were deliberate and documented.

The organizations that maintain strong endpoint security posture are not the ones with the largest IT teams. They are the ones with a structured policy architecture, a tested false positive workflow, and an operational understanding of which exclusions they have made and why.

If your current MDE deployment is running on defaults, or if your exclusion list has grown without a governance process, the configuration audit is where we start.

Related Service

Microsoft Defender for Endpoint Solutions

End-to-end MDE deployment: tiered policy design, false positive workflow, NIS2 compliance alignment, and ongoing policy governance for Dutch enterprise environments.

View MDE Services

Also Relevant

Microsoft Sentinel SIEM/SOAR Services

MDE endpoint telemetry feeds directly into Sentinel analytics rules. Lateral movement and ransomware staging patterns that individual policies miss are detected at the SIEM layer.

View Sentinel Services

MDE Defaults Leave Your Network Exposed

Most enterprise MDE deployments leave three to five critical configuration gaps. Our endpoint practice identifies and closes them — without halting production.