2.1 MDE Architecture and Deployment Planning

MDE Architecture and Deployment Planning

Introduction

Before you onboard your first device, you need to understand what Defender for Endpoint actually is at an architectural level — not the marketing description, but the technical architecture that determines how data flows, where decisions are made, and what fails when components are misconfigured.

Defender for Endpoint is not a single agent. It is a distributed system with three layers: the endpoint sensor that captures telemetry on each device, the cloud backend service that processes and analyzes that telemetry, and the management portal where you configure policies, investigate alerts, and take response actions. Understanding these three layers is essential because troubleshooting — which you will do regularly — requires knowing which layer is responsible for the behavior you are observing. When a device does not appear in the portal, is the problem the sensor (not installed or not running), the network (connectivity to the cloud service is blocked), or the backend (license not assigned, onboarding not processed)? Each layer has different diagnostic tools and different failure modes.

This subsection teaches you the complete MDE architecture, the deployment planning decisions you must make before onboarding devices, the licensing differences between Plan 1 and Plan 2 that determine which features are available, and the integration points with Intune, Configuration Manager, and Group Policy that control how you manage the platform at scale.

The three-layer architecture

Layer 1: The endpoint sensor. On Windows 10 and 11, the MDE sensor is built into the operating system — it is the Microsoft Defender for Endpoint service that runs as part of the Windows Security stack. It does not require a separate agent installation. On Windows Server 2016+, the sensor is also built-in but requires explicit onboarding. On Windows Server 2012 R2, macOS, and Linux, the sensor is a separate package that must be installed. On iOS and Android, the sensor runs as a mobile app (Microsoft Defender) that provides web protection and network-level threat detection.

The sensor captures comprehensive telemetry from the device. Process creation events record every executable that launches, including the parent process, command line, file hash, and the user account. Network connection events record every outbound and inbound connection with destination IP, port, and the process that initiated it. File events record creation, modification, deletion, and rename operations with file path, hash, and size. Registry events record key creation and value modification. Logon events record interactive and network logons with account and source information. AMSI events capture scripts evaluated by the Antimalware Scan Interface, including PowerShell, VBScript, and JavaScript content.

This telemetry is what populates the Device tables in Advanced Hunting: DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents, DeviceImageLoadEvents, and DeviceEvents. Every investigation query you wrote in Module 6 and every cross-product correlation in Module 1 depends on the sensor capturing complete, accurate telemetry. If the sensor is not running, not configured correctly, or blocked from communicating with the cloud service, those tables are empty for that device — and your detections are blind.

Layer 2: The cloud backend service. The sensor sends telemetry to the MDE cloud backend, which runs in Microsoft’s Azure infrastructure. The backend performs the computationally intensive analysis that would be impractical to run on each endpoint: machine learning models that classify process behaviors as malicious or benign, correlation engines that connect related events across devices, behavioral analytics that establish per-device baselines and detect deviations, and threat intelligence matching that compares observed indicators against Microsoft’s global threat intelligence.

The cloud backend is also where automated investigation and response (AIR) operates. When the backend identifies a suspicious event, it launches an automated investigation that examines related artifacts, builds an attack narrative, and determines remediation actions — all without analyst intervention. The investigation results and recommended actions are then presented in the portal for analyst review (or executed automatically, depending on your automation level configuration).

The sensor-to-cloud communication uses HTTPS to specific Microsoft endpoints. Devices must be able to reach URLs in the *.securitycenter.windows.com and *.security.microsoft.com domains. If your network blocks outbound HTTPS to these destinations (common in environments with restrictive proxy configurations), the sensor cannot send telemetry and the device appears as offline or unhealthy in the portal. Diagnosing connectivity issues is covered in subsection 2.2.

Layer 3: The management portal. The Defender XDR portal at security.microsoft.com is where you configure MDE settings, manage device inventory, investigate alerts, take response actions, and monitor the health of your deployment. From an MDE perspective, the key areas in the portal are:

Settings → Endpoints → Advanced features, where you enable or disable platform capabilities like live response, automated investigation, custom network indicators, web content filtering, and attack surface reduction rule reporting. Settings → Endpoints → Onboarding, where you download onboarding packages for each deployment method and operating system. Assets → Devices, where you view the complete inventory of onboarded devices with their health state, risk level, exposure level, and last seen timestamp. The Incidents queue, where MDE alerts appear correlated with alerts from other Defender products.

Plan 1 vs Plan 2: what you get at each tier

The distinction between MDE Plan 1 and Plan 2 directly affects what your SOC can do. Many organizations start with P1 (included in M365 E3 and Business Premium) and discover limitations when they need investigation capabilities that only P2 provides.

Plan 1 (prevention-focused) includes next-generation antivirus protection (Microsoft Defender Antivirus with cloud-delivered protection, behavioral monitoring, and exploit protection), attack surface reduction capabilities (ASR rules, controlled folder access, device control, network protection, web protection), manual response actions (device isolation, restrict app execution, run antivirus scan), and centralized management through the Defender portal. Plan 1 provides the preventive layer — it stops known threats and reduces the attack surface. But it does not provide the investigation and hunting capabilities that SOC analysts need.

Plan 2 (prevention + investigation + hunting) includes everything in Plan 1 plus the full endpoint detection and response (EDR) engine, the device timeline with detailed forensic telemetry, live response sessions for remote forensic collection, automated investigation and response (AIR), threat and vulnerability management (TVM), Advanced Hunting across all Device tables, custom detection rules, attack simulators for testing, and Microsoft Threat Experts (ask-the-expert service). Plan 2 provides the investigation layer — it enables the alert triage, device timeline analysis, process tree investigation, and live response forensics that Module 1 taught and that Modules 11-15 depend on.

The practical impact: with Plan 1, when an endpoint alert fires, you can see the alert name and severity but cannot drill into the device timeline, cannot use live response to collect forensic artifacts, cannot run Advanced Hunting queries against the detailed telemetry, and cannot configure automated investigation. You can isolate the device and run an antivirus scan — but you cannot investigate what happened. For a SOC analyst, Plan 2 is not optional.

Licensing paths to Plan 2: M365 E5 includes Plan 2. M365 E3 includes Plan 1 — upgrade by purchasing the standalone Defender for Endpoint P2 add-on. M365 Business Premium includes Plan 1 — same add-on path. Standalone Defender for Endpoint P2 can be purchased without any M365 bundle for organizations that need endpoint protection but not the full M365 suite.

Deployment planning decisions

Before onboarding your first production device, you need to make five decisions that determine how MDE operates in your environment. Getting these wrong causes operational pain that is difficult to fix after deployment because changing them requires re-onboarding or policy redistribution.

Decision 1: Onboarding method. How will you deploy the MDE sensor configuration to your devices? The options are Microsoft Intune (recommended for cloud-managed devices), Microsoft Configuration Manager (SCCM/MECM, for on-premises managed environments), Group Policy (for domain-joined devices without Intune or SCCM), local script (for testing and small deployments), and VDI onboarding scripts (for virtual desktop environments). Your choice depends on your existing device management infrastructure. If you already use Intune to manage devices, use Intune for MDE onboarding — it provides the tightest integration and the simplest policy management. If you use SCCM, use the SCCM integration. Do not mix multiple onboarding methods for the same device population — it creates management complexity and troubleshooting confusion.

Decision 2: Automation level. How much autonomous remediation should AIR perform? The options range from “Full — remediate threats automatically” (AIR investigates and remediates without analyst approval) to “No automated response” (alerts only, no AIR). The recommended starting point for most organizations is “Semi — require approval for any remediation” — AIR investigates and recommends actions, but an analyst must approve before remediation executes. This gives you the investigation benefit of AIR (it analyzes the alert faster than any human analyst) while maintaining human oversight of remediation actions. After you build confidence in AIR’s recommendations over 30-60 days, you can upgrade to full automation for common, well-understood alert types.

Decision 3: Device groups. How will you organize devices for policy application and RBAC? Device groups let you apply different automation levels, assign different analyst teams, and scope visibility so that SOC analysts only see devices in their responsibility area. Common grouping strategies include by operating system (Windows workstations, Windows servers, macOS, Linux), by business unit (Engineering, Finance, Executive), by risk level (standard users, privileged users, high-value servers), or by geographic region. Your device group structure should mirror your organizational responsibility model — if a specific analyst team is responsible for server security, create a server device group and assign that team access.

Decision 4: Advanced features enablement. Which platform capabilities will you enable? Key features that require explicit enablement include live response (disabled by default — must be enabled before any analyst can initiate a live response session), advanced live response (allows running unsigned scripts — additional risk, requires separate enablement), custom network indicators (allows blocking specific IPs, URLs, and domains at the endpoint level), web content filtering (blocks access to categories of websites), automated investigation (enable or disable the AIR engine), and Microsoft Defender for Identity integration (enables identity data enrichment in endpoint alerts). Review each feature, understand the security and operational implications, and enable deliberately rather than enabling everything at once.

Decision 5: Sample sharing and data retention. MDE can submit suspicious files to Microsoft’s cloud for deep analysis (detonation). This improves detection fidelity but means file samples leave your environment. For organizations with strict data handling requirements (government, defense, financial services), review the sample sharing policy with your compliance team before enabling. Data retention for MDE telemetry defaults to 180 days. If you need longer retention for compliance or forensic purposes, forward the data to a Sentinel workspace with extended retention configured (covered in Module 7).

Integration with device management platforms

MDE does not operate in isolation — it integrates with your device management platform to enable compliance-based conditional access, a powerful control that blocks compromised devices from accessing corporate resources.

Intune integration is the deepest and most automated. When Intune and MDE are connected (Settings → Endpoints → Advanced features → Microsoft Intune connection), MDE sends device risk levels to Intune. Intune compliance policies can then include a “device must be at or below a specified risk level” condition. Conditional Access policies in Entra ID can block access to corporate resources (email, SharePoint, Teams) for devices that fail compliance — meaning a device flagged as “high risk” by MDE is automatically blocked from accessing corporate data until the threat is remediated. This creates a closed-loop protection system: MDE detects the threat, Intune marks the device as non-compliant, Conditional Access blocks access, the analyst remediates the threat, MDE recalculates the risk level, Intune marks the device as compliant, and access is restored. All of this can happen without any analyst intervention if AIR is configured for full automation.

Configuration Manager integration provides similar capabilities for on-premises managed devices that are co-managed with Intune. The co-management scenario requires both SCCM and Intune to be configured, with the endpoint protection workload directed to Intune. This is the recommended approach for organizations transitioning from on-premises to cloud management.

Group Policy integration is the least automated option but necessary for environments that do not use Intune or SCCM. GPO can deploy the onboarding package and configure ASR rules, but it does not provide the compliance-to-conditional-access integration that Intune enables. Organizations using GPO for MDE should plan a migration path to Intune for the full protection loop.

MDE in the Defender XDR ecosystem

MDE does not exist alone. Its value multiplies when integrated with other Defender products because each product contributes signals that improve the others.

MDE sends device risk signals to Entra ID Protection, which incorporates them into conditional access evaluations. A user signing in from a device flagged as compromised by MDE faces additional authentication requirements or is blocked entirely — even if their credentials are valid.

MDE telemetry feeds into the Defender XDR correlation engine, which connects endpoint alerts with email alerts (Defender for Office 365), identity alerts (Defender for Identity and Entra ID Protection), and cloud app alerts (Defender for Cloud Apps). The cross-product correlation queries you wrote in Module 1.8 depend on MDE providing the DeviceProcessEvents, DeviceNetworkEvents, and DeviceFileEvents data that represent the endpoint layer of the attack chain.

MDE data can be forwarded to Microsoft Sentinel for long-term retention (beyond the 180-day default), custom analytics rules that combine endpoint data with third-party data sources, and SOAR playbooks that automate response actions triggered by Sentinel incidents. The Defender XDR data connector in Sentinel (configured in Module 0.5) is what enables this data flow.

MDE integrates with Defender for Identity by sharing device context in identity alerts. When Defender for Identity detects lateral movement (pass-the-hash, pass-the-ticket), the alert enrichment includes the MDE device risk level and any active endpoint alerts for the source device — giving the analyst immediate context about whether the source device was already compromised.

Knowledge check