The Microsoft Ecosystem View

MDE at the center: what it provides and what it depends on

Defender for Endpoint is the endpoint security platform — it runs the sensor on the device, enforces ASR rules and AV policies, collects EDR telemetry, runs automated investigations, and provides live response and device isolation capabilities. But MDE depends on other ecosystem components to function at its full potential, and those dependencies are not configured by default.

MDE depends on Intune for policy delivery. ASR rules, AV configuration, compliance policies, security baselines, and onboarding configuration are all delivered through Intune configuration profiles or Endpoint Security policies. Without Intune, MDE operates with default settings — cloud protection at Default level, zero ASR rules, no compliance enforcement. The endpoint security engineering in this course is largely about building the Intune policies that configure MDE beyond those defaults. If your organization uses Group Policy instead of Intune, the same configurations are available through GPO — but Intune provides granular targeting, staged rollout to device groups, and compliance reporting that GPO does not match.

MDE depends on Entra ID for device identity and Conditional Access integration. MDE reports device risk level — no known risk, low, medium, high — based on active alerts and unresolved vulnerabilities. Entra ID Conditional Access policies can use this device risk signal to block access from compromised devices or require step-up authentication. But the integration only works if three things are configured: the MDE-Entra connector is enabled in the Defender portal, a Conditional Access policy references the device risk condition, and the policy targets the appropriate user groups and cloud applications. Without all three, the device risk signal exists in MDE's data but has zero enforcement impact — a compromised endpoint with active credential theft alerts can access every M365 resource normally.

MDE feeds Sentinel with endpoint telemetry for cross-workload correlation. The MDE connector in Sentinel streams alerts and raw device events into Log Analytics tables. Sentinel analytics rules can then correlate endpoint events with sign-in logs, email events, and cloud activity. A detection rule that fires when a user receives a phishing email (MDO alert) AND the same user's device creates a suspicious process (MDE telemetry) within 15 minutes is only possible when both data sources flow into Sentinel. Without the connector, MDE and Sentinel operate as independent platforms with no shared query surface.

The data flow from endpoint sensor to hunting table

Understanding where endpoint data ends up determines where you build your queries and detections. When the MDE sensor on an endpoint observes an event — a process creation, a network connection, a file write — the data follows a specific path.

The sensor captures the event locally, processes it into a structured format, and transmits it to the MDE cloud service. The cloud service processes the event through Microsoft's ML models and behavioral correlation engines, generating alerts if the event matches known attack patterns. The processed event is stored in the Advanced Hunting tables — DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents, DeviceImageLoadEvents. These tables are queryable through the security.microsoft.com portal or through the MDE API.

If the MDE connector is enabled in Sentinel, the same data streams to a Log Analytics workspace where it appears in tables with the same names. The Sentinel copy enables cross-workload queries — joining endpoint events with SigninLogs, EmailEvents, or CloudAppEvents — that are not possible in the MDE-only Advanced Hunting console. The tradeoff is cost: streaming raw device events to Sentinel incurs Log Analytics ingestion charges based on data volume. A 500-endpoint environment generates approximately 5–15 GB of device event data per day depending on endpoint activity levels. At standard Log Analytics pricing, that is a meaningful operating cost that should be planned for in the security budget. The decision of which event types to ingest into Sentinel versus query only in Advanced Hunting is one of the first architectural decisions you'll make.

The retention model is the other critical difference. Advanced Hunting retains device event data for 30 days in the standard configuration. Sentinel retains data according to your Log Analytics workspace retention policy — typically 90 days at the standard tier, extendable to 730 days or moved to long-term retention for compliance. If your IR team needs to investigate an attacker who established persistence 45 days ago, the Advanced Hunting data has already aged out. The Sentinel copy preserves the evidence. For organizations with regulatory retention requirements or a history of sophisticated intrusions with long dwell times, forwarding at least the critical event types — DeviceProcessEvents and DeviceLogonEvents — to Sentinel is an architectural necessity, not a convenience.

The latency between an event occurring on the endpoint and the event being queryable in Advanced Hunting is typically 5–15 minutes. This latency matters during active incident response — if you are hunting for an attacker who compromised an endpoint 5 minutes ago, the most recent events may not yet be queryable. Live response provides real-time terminal access to the endpoint for time-critical situations where the hunting latency is unacceptable.

Before querying fleet-wide data in Advanced Hunting, verify that the local endpoint is reporting correctly. The MDE sensor health on any individual endpoint is visible through PowerShell.

PS C:\> Get-MpComputerStatus | Select-Object AMServiceEnabled,
    AntispywareEnabled, AntivirusEnabled, RealTimeProtectionEnabled,
    OnAccessProtectionEnabled, NISEnabled, QuickScanAge, FullScanAge
AMServiceEnabled             : True
AntispywareEnabled           : True
AntivirusEnabled             : True
RealTimeProtectionEnabled    : True
OnAccessProtectionEnabled    : True
NISEnabled                   : True
QuickScanAge                 : 1
FullScanAge                  : 7

Every field should be True on a healthy endpoint. RealTimeProtectionEnabled: False means the AV engine is not scanning files as they are accessed — the prevention layer is offline. QuickScanAge shows days since the last quick scan — values above 7 indicate the scheduled scan policy is not applying. FullScanAge above 30 suggests the full scan policy is missing or the endpoint is not online during the scan window. At NE, 85 of 865 endpoints have RealTimeProtectionEnabled: False — mostly development workstations where developers disabled real-time protection for build performance and never re-enabled it. The fleet-wide KQL query below confirms this from the cloud side.

// Verify Sentinel data flow — check DeviceProcessEvents ingestion lag
DeviceProcessEvents
| where Timestamp > ago(1h)
| summarize
    EventCount = count(),
    LatestEvent = max(Timestamp),
    OldestEvent = min(Timestamp),
    UniqueDevices = dcount(DeviceName)
// If EventCount is 0 and this runs in Sentinel, the MDE connector
// is not streaming data. Run the same query in Advanced Hunting
// (security.microsoft.com) to confirm MDE has the data.

Run this query in both Sentinel and Advanced Hunting. If Sentinel returns zero events but Advanced Hunting returns data, the MDE connector is not configured or the DeviceProcessEvents table is not selected for ingestion. If both return zero, the MDE sensor may not be reporting — check the device onboarding status in the Defender portal.

The integration points this course configures

This course focuses on endpoint security engineering. It does not configure the entire M365 security ecosystem — the EI, DE, and SA courses cover identity security, detection engineering, and security automation respectively. But endpoint security engineering requires configuring specific integration points that cross product boundaries.

MDE → Entra ID Conditional Access (Module ES3). Device compliance state feeds into CA policies. A non-compliant device — missing BitLocker, outdated OS, AV not running — is blocked from accessing M365 resources until the compliance issue is remediated. Device risk level from active MDE alerts feeds separately into CA policies. A device with an active high-severity alert is blocked regardless of compliance status. These are two distinct CA conditions that complement each other: compliance measures configuration health, device risk measures active threat status.

Intune → MDE (Modules ES2 through ES6). Intune delivers the policies that configure MDE: onboarding profiles that deploy the MDE sensor, ASR rule policies that specify which rules are in block versus audit mode, AV configuration profiles that set cloud protection levels and AMSI behavior, compliance policies that define the minimum security requirements, and security baselines that apply Microsoft's recommended configuration. The Intune-MDE connector ensures that onboarding is automatic for newly enrolled devices — no manual deployment step required.

MDE → Sentinel (Module ES14). The MDE connector streams endpoint telemetry to Sentinel for cross-workload analytics. Custom detection rules in Sentinel can correlate endpoint data with identity and email signals. Playbooks triggered by Sentinel analytics rules can call MDE API actions — isolating a device, collecting an investigation package, or blocking an indicator across the fleet based on a cross-workload detection. This integration turns endpoint response from a manual portal action into an automated workflow triggered by correlated intelligence.

The broader XDR ecosystem: MDO, MDI, and Defender for Cloud

Three additional Defender products contribute directly to endpoint security by providing signals that MDE alone cannot see.

Defender for Office 365 correlates email threats with endpoint compromise. When a user clicks a phishing link in an email, MDO logs the click event with the sender, URL, and recipient. When the resulting payload executes on the endpoint, MDE logs the process creation with the parent process chain and command line. Defender XDR correlates both events into a single incident — "User received phishing email, clicked link, endpoint executed malicious payload" — visible as one correlated chain rather than two disconnected alerts in two consoles. This email-to-endpoint correlation is particularly valuable for the initial access phase of the attack chain from Section 0.2, where the phishing email is the entry point but the endpoint is where the damage occurs.

Defender for Identity correlates Active Directory attacks with endpoint activity. When an attacker performs Kerberoasting from a compromised endpoint, MDI detects the anomalous Kerberos ticket request pattern from the domain controller's perspective while MDE detects the suspicious process on the source endpoint. The unified incident in Defender XDR shows both the endpoint view (the process that requested the tickets) and the identity view (the service accounts targeted for hash extraction). Without MDI, you see the endpoint behavior but miss the directory-level context that reveals the attacker's objective.

Defender for Cloud extends MDE to server workloads. For Windows and Linux servers running in Azure or connected via Azure Arc, Defender for Cloud provides Server Protection plans (Defender for Servers P1 and P2) that include MDE's sensor plus additional server-specific protections including file integrity monitoring, just-in-time VM access, and adaptive application controls. At NE, the 12 Windows servers and 8 Linux servers need endpoint security coverage. The decision between MDE standalone configuration and Defender for Cloud enrollment depends on whether the servers run in Azure (Defender for Cloud is the natural fit) or on-premises (MDE standalone with Arc connection). Module ES13 covers this decision with the architectural tradeoffs.

Where to build detections: MDE Advanced Hunting vs Sentinel

When you write a custom detection rule, the first decision is where it runs. This choice determines what data the rule can access, what response actions it can trigger, and how much it costs.

Build in MDE Advanced Hunting when the detection uses only endpoint data — DeviceProcessEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceNetworkEvents — and needs to trigger endpoint-specific response actions like device isolation, investigation package collection, or application restriction. MDE custom detections run against 30 days of data with no additional ingestion cost beyond the E5 license. They execute every 1–24 hours depending on the configured frequency and can automatically generate incidents with mapped entities.

Build in Sentinel when the detection needs to correlate endpoint data with identity data (SigninLogs), email data (EmailEvents), or cloud app data (CloudAppEvents). A detection that fires when a user signs in from a new IP (identity signal) AND the same user's device creates a suspicious scheduled task (endpoint signal) within 30 minutes requires both data sources in the same query surface — which only Sentinel provides. The tradeoff: Sentinel detections incur Log Analytics query costs and require the MDE connector to be streaming device events, which adds ingestion costs.

If you need both cross-workload correlation AND endpoint response actions, build the detection in Sentinel and use a Logic App playbook to call the MDE API for the response action. The playbook bridges the gap between Sentinel's analytics and MDE's enforcement capabilities. Module ES8 covers the detection placement decision in detail, including the cost model for each approach.