Microsoft Defender for Endpoint: Deployment, Onboarding, and Advanced Configuration
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Microsoft Defender for Endpoint is the most widely deployed EDR in enterprise environments, yet most organizations run it far below its capability ceiling. The default configuration gets you antivirus and basic behavioral detection; the advanced configuration -- Attack Surface Reduction rules in block mode, Tamper Protection, cloud-delivered protection at high levels, custom detection rules, and Sentinel integration -- is what makes MDE competitive with dedicated EDR vendors. This guide covers the full deployment path: onboarding methods for Windows, macOS, and Linux, the ASR rule audit-to-block migration process, Tamper Protection rollout, vulnerability management configuration, and the Advanced Hunting queries that turn MDE's telemetry into operational threat hunting.
Onboard Endpoints by Platform
MDE onboarding varies by platform and device management toolchain. Match the method to your existing infrastructure.
Windows onboarding via Microsoft Intune
For Entra ID-joined Windows devices managed by Intune: in the Microsoft 365 Defender portal, go to Settings > Endpoints > Onboarding and select Intune as the deployment method. MDE creates a Configuration Manager compliance policy that Intune deploys to all targeted device groups. Onboarding completes within 24 hours of policy assignment; device health data appears in the Defender portal within 1-2 hours of first sensor check-in. Intune onboarding enables Conditional Access integration: device risk score from MDE can block Entra ID resource access for high-risk devices.
Windows onboarding via Group Policy for AD-joined environments
Download the onboarding package from the Defender portal (Settings > Onboarding > Group Policy). Deploy the package via GPO to all targeted OUs: Computer Configuration > Policies > Windows Settings > Scripts (Startup) and point to the onboarding script. The MDE sensor installs silently on next reboot. For servers not in Active Directory, use the local onboarding script (run as SYSTEM) or deploy via MECM for SCCM-managed infrastructure.
macOS onboarding via Intune MDM profile
For macOS, MDE deploys as a .pkg file with required system extension and full disk access permissions. In Intune, create a macOS app of type 'Line of Business' with the MDE onboarding package and a device configuration profile granting System Extension approval (com.microsoft.wdav.epsext) and Full Disk Access. Without these MDM-granted permissions, MDE installs but cannot perform real-time protection on all file system locations. Test on a sample device before rolling out to the fleet -- macOS kernel extension policies require careful sequencing.
Linux onboarding via package manager
MDE on Linux (mdatp) installs via apt or yum from Microsoft's repository. For Ansible or Chef deployments: add the Microsoft Linux repository, install the `mdatp` package, copy the onboarding JSON blob to `/etc/opt/microsoft/mdatp/mdatp_onboard.json`, and restart the `mdatp` service. Verify onboarding: `mdatp health --field licensed` should return `true`. On containerized Linux hosts (Docker, Kubernetes nodes), install MDE on the host OS rather than inside containers -- container-level isolation limits MDE's visibility into host events.
Configure Attack Surface Reduction Rules
ASR rules are the highest-impact configuration change you can make to MDE after onboarding. Running them in audit mode first is non-negotiable.
Enable all ASR rules in audit mode via Intune
In Intune, create an Endpoint Security > Attack Surface Reduction policy. Set all 16 ASR rules to 'Audit mode.' Deploy to a test device group first, then all devices. Monitor the Microsoft 365 Defender portal under Reports > Attack Surface Reduction > Audit events for 30 days. Each audit event shows the rule, the blocked process, and the triggering file path -- the data you need to determine false positives.
Identify and allow legitimate business applications triggering audit events
Common legitimate false positives for ASR rules: (1) Office applications spawning PowerShell (rule: Block Office apps from creating child processes) -- check if this is a legitimate macro or add-in. (2) Credential manager tools triggering LSASS protection. (3) Internal security tools running obfuscated scripts. For each legitimate business application, add a per-file or per-folder exclusion to the specific ASR rule (not a global exclusion) via the ASR rule's exclusion list in Intune.
Promote high-confidence rules to block mode first
After 30 days of audit data, promote ASR rules with zero or very low false-positive rates to block mode. The safest first rules to block: 'Block abuse of exploited vulnerable signed drivers' (affects only unsigned/vulnerable drivers, near-zero false positives), 'Block executable content from email client and webmail' (no legitimate email should deliver executable content), and 'Block persistence through WMI event subscription' (no common legitimate software uses WMI subscriptions for persistence). Leave rules with legitimate business use cases in audit mode until exclusions are confirmed.
Monitor ASR blocked events as a threat signal
ASR block events are security signals, not just noise. A spike in ASR block events for 'Block credential stealing from LSASS' or 'Block process creations originating from PSExec and WMI commands' on multiple hosts in a short window indicates active credential harvesting or lateral movement. Set up an Advanced Hunting scheduled query that alerts when more than 5 unique devices trigger the LSASS protection rule within a 1-hour window.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enable Tamper Protection and Cloud Protection
Tamper Protection and cloud-delivered protection are the two configuration changes with the highest security ROI and lowest operational risk.
Enable Tamper Protection via Intune
In Intune, go to Endpoint Security > Antivirus > Create Policy > Windows Security Experience. Set 'Tamper Protection' to Enabled. Deploy to all Windows devices. For devices not managed by Intune, enable via the Microsoft 365 Defender portal under Settings > Advanced Features > Tamper Protection (applies globally to all Defender-portal-managed devices). Once enabled, local administrator attempts to disable real-time protection via Registry or PowerShell fail silently -- critical for blocking the EDR-killing phase of ransomware attacks.
Set cloud protection to High
Microsoft Defender Antivirus cloud-delivered protection sends suspicious file hashes and samples to Microsoft for cloud-side analysis when local signatures are inconclusive. Set the cloud protection level to 'High' (not 'Not configured' or 'Default') via Intune Antivirus policy: 'Cloud-delivered protection level' = High. High level is the right operational setting for enterprise environments -- it blocks more files pending cloud analysis and is more aggressive about sending samples. Monitor the threat detections view for 'Cloud protection' source detections to validate it is working.
Enable Network Protection
Network Protection extends SmartScreen protection to all network traffic (not just Edge browser): it blocks connections to known malicious domains, phishing sites, and C2 infrastructure at the kernel network driver level. Enable Network Protection in Intune: Endpoint Security > Attack Surface Reduction > Network Protection = Block. Network Protection in block mode is broadly safe -- the block list is curated by Microsoft threat intelligence and has a low false-positive rate. Enable it simultaneously with Tamper Protection for a hardened baseline.
Advanced Hunting and Sentinel Integration
MDE's raw telemetry via Advanced Hunting and Sentinel integration converts MDE from a detection platform into a threat hunting and investigation platform.
Use Advanced Hunting for proactive threat detection
Advanced Hunting in the Microsoft 365 Defender portal provides a KQL interface over 6 months of raw endpoint telemetry. Start with high-value queries: `DeviceProcessEvents | where ProcessCommandLine contains 'mimikatz' or ProcessCommandLine contains 'sekurlsa'` for credential dump detection; `DeviceNetworkEvents | where RemotePort == 4444 and Protocol == 'Tcp'` for reverse shell indicators. Schedule weekly hunting queries as detection rules that generate alerts when the query returns results.
Stream MDE events to Microsoft Sentinel
Connect MDE to Microsoft Sentinel via the Microsoft 365 Defender data connector. This streams all MDE incident, alert, and advanced hunting tables (DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents) into Sentinel's Log Analytics workspace. Once in Sentinel, build correlation rules that join MDE endpoint events with Entra ID sign-in logs and Exchange activity -- attack chains that cross the endpoint-identity boundary (compromised credentials used to bypass MDE via pass-the-hash) become detectable in Sentinel where MDE alone cannot correlate them.
Configure device risk-based Conditional Access
One of MDE's most powerful integrations is the device risk signal feed into Entra ID Conditional Access. In Entra ID, create a Conditional Access policy that requires 'Device risk level' to be Low or Medium for access to sensitive apps. Any device that MDE marks as High risk (active malware, compromised credentials detected) is immediately blocked from accessing Exchange, SharePoint, and other Entra ID-protected resources without requiring manual incident response. This automated containment reduces dwell time for device compromises measurably.
The bottom line
MDE at its default configuration is a capable antivirus; MDE with ASR rules in block mode, Tamper Protection enabled, cloud protection at High, Network Protection active, and Sentinel integration is an enterprise-grade EDR that reduces attacker dwell time and provides the telemetry needed for threat hunting. The onboarding work is straightforward -- the operational lift is in the 30-day ASR audit cycle and Sentinel detection rule development. Both investments pay for themselves the first time MDE detects a LOLBAS or credential harvesting attack that a perimeter firewall and signature AV would have missed entirely.
Frequently asked questions
What is the difference between Microsoft Defender Antivirus and Defender for Endpoint?
Microsoft Defender Antivirus (MDAV) is the signature and behavior-based antimalware component built into Windows. Defender for Endpoint (MDE) is the enterprise EDR platform layered on top: it adds the cloud-connected telemetry stream, behavioral analytics that detect tactics and techniques rather than malware signatures, device risk scoring, vulnerability management (Defender Vulnerability Management), Attack Surface Reduction rules, and the Microsoft 365 Defender portal for incident investigation. MDAV can run without MDE; MDE requires MDAV (or a supported non-Microsoft antivirus in passive mode) to function. On macOS and Linux, MDE includes its own antivirus component.
How is MDE licensed and what plan do you need?
MDE is included in: Microsoft 365 E5, Microsoft 365 E5 Security add-on (for E3 customers), Microsoft Defender for Business (SMB-focused, up to 300 users), and Microsoft Defender for Endpoint Plan 1 (basic protection without EDR) or Plan 2 (full EDR with advanced hunting). For enterprises already using Microsoft 365 E3, the E3-to-E5 Security upgrade is typically the most cost-effective path. Defender for Business P2 is nearly feature-equivalent to MDE P2 for organizations under 300 users and is significantly cheaper.
What are Attack Surface Reduction (ASR) rules and how aggressive should you be?
ASR rules are configurable behavioral blocks that prevent specific techniques commonly used by malware: blocking Office applications from creating child processes, blocking credential dumping via LSASS, blocking execution of potentially obfuscated scripts, and blocking untrusted executables from USB. Each rule operates in audit mode (log only), warn mode (block with user notification), or block mode (block silently). Start all rules in audit mode for 30 days, review the audit log for false positives, then enable block mode on rules with no legitimate false positives. Do not enable block mode across all 16 rules simultaneously without auditing.
What is Tamper Protection and should you enable it?
Tamper Protection prevents local administrator accounts and malicious processes from disabling MDE's security features: it blocks changes to real-time protection, behavior monitoring, IOAV protection, and cloud-delivered protection via Registry edits, PowerShell, WMI, or local policy. Ransomware often attempts to disable AV/EDR before executing the encryption payload -- Tamper Protection is a key pre-ransomware defense. Enable it for all production endpoints. Manage exceptions via Intune security baselines for cases where legitimate software triggers false detection.
How does MDE vulnerability management work?
MDE includes Microsoft Defender Vulnerability Management (MDVM, formerly Threat and Vulnerability Management), which inventories software installed on onboarded endpoints and correlates that inventory against CVE databases and exploitability data. MDVM provides a device-level exposure score and security recommendations ranked by impact. Unlike external vulnerability scanners that require network access, MDVM gets software inventory directly from the MDE sensor telemetry, making it faster and more accurate for installed software versions. MDVM findings integrate with Intune remediation tasks and ServiceNow for ticketing.
Can MDE be deployed without Microsoft Intune?
Yes. MDE onboarding can be done via: Microsoft Intune (recommended for Entra ID-joined devices), Group Policy (for Active Directory-joined devices), Microsoft Endpoint Configuration Manager (MECM/SCCM), a local onboarding script, or Azure Arc for servers. Intune provides the tightest integration (Conditional Access compliance based on device risk, co-management with Config Manager), but Group Policy and MECM deployments are fully functional for MDE's core EDR capabilities. The onboarding package is the same regardless of deployment method.
How do you tune alert noise in MDE?
MDE generates alerts from cloud AI models that are not perfectly calibrated for every environment. Tune noise via: (1) Suppression rules that hide recurring false-positive alerts matching specific criteria (file path, process name, command line pattern) -- available under Settings > Rules > Alert suppression. (2) Indicators of compromise (IOC) allowlists for trusted internal tools flagged by behavioral detection. (3) Review the alert's origin -- Defender Antivirus detections and EDR behavioral detections have different tuning mechanisms. Over-suppression is a risk -- track suppression rule coverage and audit quarterly.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.