The Microsoft Ecosystem View

Introduction

Defender for Endpoint does not work alone, and this section maps what it depends on and what depends on it. You will finish able to name the four integrations this course configures, say which of them breaks silently, and make the decision that comes up every time you write a detection: whether it belongs in Advanced Hunting or in Sentinel. That choice is not a preference and it is not reversible cheaply.

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 dashed lines are the interesting part, because they are the things that can be absent while everything on the diagram is present and licensed.

  MDE PROVIDES        the sensor, the telemetry, the detections,
                      the response actions, the hunting tables
  ------------------------------------------------------------------
  MDE NEEDS           Entra ID    for device identity. without it
                                  a device has no stable name and
                                  no owner
                      Intune      for configuration. MDE has no
                                  policy engine of its own; every
                                  setting in this course arrives
                                  through Intune or GPO
  ------------------------------------------------------------------
  WHICH MEANS         an MDE problem is often an Intune problem,
                      and an Intune problem presents as MDE not
                      working

That last line is worth carrying, because it decides where you look first. Almost every configuration fault in this course arrives reported as "Defender is not doing X", and in most cases Defender is doing exactly what it was told by a policy that did not arrive, applied to a group that did not contain the device, or was overwritten by a second profile. The sensor is rarely the problem.

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.

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 (SEC409 Endpoint Security Operations). 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.

INTUNE -> MDE            policy delivery
    fails LOUDLY. profiles stop applying and the console
    shows it. modules 2 to 6 depend on this one.
MDE -> CONDITIONAL ACCESS   compliance as an access decision
    fails DANGEROUSLY. a device that stops reporting
    compliance is treated as non-compliant and blocked,
    which is safe, or as unknown and allowed, which is not.
    the direction depends on your policy.
MDE -> SENTINEL          telemetry for correlation
    fails SILENTLY. the connector stops, the tables stop
    filling, and every query returns fewer rows rather
    than an error. nothing alerts.
MDE -> VULNERABILITY MGMT   exposure score
    fails QUIETLY and matters least. the number goes stale
    rather than wrong.

ONLY ONE OF THE FOUR ANNOUNCES ITSELF. Build a check for the
Sentinel connector, because a query returning nothing looks
exactly like an estate with nothing to find.

The third is the one to instrument. A broken connector produces the same output as a quiet week, and the module on monitoring builds the coverage check that distinguishes them. Until then, the honest position is that an absence of results in Sentinel proves nothing about the endpoint.

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 ES8 covers this decision with the architectural tradeoffs.

The reason those three are named here and then left alone is worth being explicit about. Each covers a different attack surface, they share a portal and an incident graph, and a single incident routinely draws evidence from all four. But configuring email protection or identity monitoring is a different discipline with different failure modes, and a course that covered all four would teach none of them to the depth where you could deploy them.

What matters at this point is knowing the boundary. When an endpoint alert turns out to have started with a phished token, the endpoint is where you saw it and not where it began, and the fix lives in a product this course does not configure.

MDO   the mail arrived. attachment, link, the phish itself.
MDI   the identity was abused. on-premises AD, Kerberos,
      lateral movement between accounts.
MDE   something ran on a machine. this course.
MDC   the workload was reached. servers, containers, cloud
      resources after the endpoint.

AN INCIDENT USUALLY STARTS IN ONE AND IS SEEN IN ANOTHER. The
endpoint is frequently where the alert appears and rarely where
the attack began, and the first question in triage is which of
the four saw it first.

Knowing that boundary is what stops an endpoint team spending a day on an alert whose cause was a phished token, and it is why this section names three products it then declines to teach.

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. SEC409 Endpoint Security Operations covers the detection placement decision in detail, including the cost model for each approach.

Which of the four is the question worth answering per rule rather than per estate.

  ONLY Device* TABLES                    -> MDE Advanced Hunting
      faster, cheaper, response actions attach directly to the
      alert. no ingestion cost.
  ------------------------------------------------------------------
  NEEDS SigninLogs, EmailEvents,         -> Sentinel
  OfficeActivity OR A NON-MICROSOFT LOG
      the correlation is the detection. MDE cannot see these
      tables at all.
  ------------------------------------------------------------------
  NEEDS BOTH CORRELATION AND A           -> Sentinel, with a
  RESPONSE ACTION ON THE DEVICE             playbook calling the
                                            MDE API

The mistake worth avoiding is building everything in Sentinel because that is where the SOC works. An endpoint-only detection built there costs ingestion, arrives later, and loses the direct response actions, and none of that is visible until somebody needs to isolate a device from an alert that cannot do it. Decide per rule, on the tables the rule reads, and the decision takes ten seconds.

Three of the four are a toggle in one screen, and the fourth is the one that matters most and is not in that screen at all.

The compliance question in step two is worth taking to whoever owns Conditional Access rather than answering alone. It is the one place in this module where an endpoint decision determines whether people can work, and the two teams frequently assume opposite defaults.