ES0.5 The Microsoft Ecosystem View
Figure ES0.5 — The M365 security ecosystem. MDE sits at the centre, feeding telemetry to Sentinel and receiving policy from Intune. Entra ID uses device risk signals for conditional access decisions. Defender for Cloud extends protection to servers. MDO and MDI provide email and identity attack correlation. The integrations between these components are what make XDR function — and each integration must be configured.
MDE at the centre: 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 isolation capabilities. But MDE depends on other ecosystem components to function at its full potential.
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. Without Intune (or GPO as an alternative), MDE operates with default settings. The endpoint security engineering in this course is largely about building the Intune policies that configure MDE beyond defaults.
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 vulnerabilities. Entra ID conditional access policies can use this device risk signal to block access from compromised devices — but only if the integration is configured and a CA policy references the risk signal. Without this integration, a compromised endpoint with an active high-severity MDE alert can still access M365 resources 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.
The data flow that matters: endpoint telemetry to hunting table
Understanding where endpoint data ends up is essential for writing effective queries and building detections. When the MDE sensor on an endpoint observes an event (process creation, network connection, 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 via 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 or similar 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 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 be queryable yet. Live response provides real-time access to the endpoint for time-critical situations.
You are building a custom detection rule. Should you build it in MDE Advanced Hunting or in Sentinel? The answer depends on what the rule needs to do. If the detection uses only endpoint data (DeviceEvents tables) and needs to trigger an endpoint-specific response action (isolate device, collect investigation package, restrict app execution), build it in MDE — MDE custom detections can trigger automated endpoint actions directly. If the detection needs to correlate endpoint data with identity data (SigninLogs), email data (EmailEvents), or cloud app data (CloudAppEvents), build it in Sentinel — Sentinel can join data from all workloads. If you need both endpoint correlation and endpoint response, build the detection in Sentinel and use a Logic App playbook to trigger the MDE API for the response action. Module ES8 covers this decision in depth, including the performance considerations for each approach.
The integration points this course configures
This course focuses on endpoint security engineering. It does not attempt to configure the entire M365 security ecosystem — Entra ID Security, Detection Engineering, Threat Hunting, and Security Automation each cover their respective domains in depth. But endpoint security engineering requires configuring specific integration points:
MDE → Entra ID conditional access (Module ES3). Device compliance state feeds into conditional access policies. A non-compliant device (missing BitLocker, outdated OS, AV not running) is blocked from accessing M365 resources. Device risk level from MDE alerts feeds into CA policies. A device with an active high-severity alert is blocked until the alert is resolved.
Intune → MDE (Modules ES2-ES6). Intune delivers the policies that configure MDE: onboarding profiles, ASR rules, AV settings, compliance policies, security baselines. The Intune-MDE connector ensures that onboarding configuration is applied automatically to enrolled devices.
MDE → Sentinel (Module ES14). The MDE connector streams endpoint telemetry to Sentinel for cross-workload analytics. Custom detection rules in Sentinel can use endpoint data alongside identity and email data. Playbooks triggered by Sentinel analytics rules can call MDE API actions.
MDE API → automation (Module ES14). The MDE API enables automation: auto-isolate devices based on high-confidence detections, auto-collect investigation packages, auto-block indicators across the fleet. Logic Apps and Azure Functions call the API based on triggers from Sentinel or MDE itself.
Try it: verify your ecosystem integration status
Check each integration point in your environment:
- MDE → Sentinel: Go to Sentinel → Data connectors. Is the Microsoft 365 Defender connector enabled? Are the DeviceEvents tables populated? Run
DeviceProcessEvents | take 10in Sentinel to verify. - Intune → MDE: Go to Intune (intune.microsoft.com) → Endpoint security → Microsoft Defender for Endpoint. Is the connector status “Connected”? Are security baselines and endpoint detection and response profiles assigned to device groups?
- MDE → Entra ID CA: Go to Entra admin center → Protection → Conditional access. Do any CA policies reference “Require device to be marked as compliant” or “Require Microsoft Defender for Endpoint risk level”?
- Device compliance → CA: Go to Intune → Devices → Compliance policies. Are compliance policies assigned? Do they feed into a CA policy?
For each integration that is not configured, you have identified a gap that this course addresses. The most common gap: compliance policies exist but are not linked to CA enforcement — devices are “non-compliant” according to Intune but can still access all M365 resources.
The myth: Enabling M365 E5 licensing automatically integrates all Defender products. Incidents are automatically correlated. Endpoint data flows to Sentinel. Device risk feeds conditional access. Everything works out of the box.
The reality: Defender XDR correlates alerts across workloads by default — if MDE, MDO, and MDI are all enabled, their alerts appear in the unified incident queue. This is real and useful. But the deeper integrations require explicit configuration. The Sentinel connector must be enabled and data connectors configured. Conditional access policies must be created that reference device compliance and risk level. Intune must have the MDE connector enabled and security profiles assigned. Custom detection rules that span workloads must be written. Automated response playbooks must be built. The “XDR” label means the architecture supports cross-workload correlation. It does not mean the correlation is happening. Configuration makes it happen.
Troubleshooting
“We have MDE and Sentinel but the DeviceEvents tables in Sentinel are empty.” The MDE connector in Sentinel must be explicitly enabled, and the specific data types (DeviceProcessEvents, DeviceNetworkEvents, etc.) must be selected for ingestion. Go to Sentinel → Data connectors → Microsoft 365 Defender → Open connector page → select the tables. Note that ingesting raw device events into Sentinel incurs Log Analytics ingestion costs — plan for the additional data volume.
“Our CA policies reference device compliance but users on non-compliant devices can still access email.” Check the CA policy’s grant controls. “Require device to be marked as compliant” must be selected as a grant control, not just a condition. Also verify that the policy targets the correct user groups and cloud apps. A common misconfiguration: the CA policy targets “All cloud apps” but excludes the Intune enrollment app — users cannot enrol their devices to become compliant because the enrolment app is blocked.
“MDE shows device risk as ‘high’ but Entra ID does not seem to use this signal.” Device risk from MDE is available in CA policies only if the MDE connector is configured in Entra ID. Go to Entra admin center → Protection → Conditional access → Create new policy → Conditions → Device risk. If the device risk condition is greyed out, the MDE-Entra integration is not configured. Configure it in the Microsoft Defender portal → Settings → Endpoints → Advanced features → Microsoft Intune connection.
You're reading the free modules of this course
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.