The Microsoft Ecosystem View

Introduction

Defender for Endpoint does not work alone, and almost everything it can do for you depends on something outside it being configured rather than merely licensed.

This section maps what it needs, what needs it, and the four connections this course actually configures. It also settles a decision that has changed recently enough that most written guidance about it is now wrong: where a detection rule belongs when you have both a Defender tenant and a Sentinel workspace.

You will finish able to name the four integrations, say which of them fails without telling you, and read the lookback table that decides whether a rule you write can see far enough back to find what it is looking for.

Defender for Endpoint provides the sensor on the device, the telemetry it produces, the analytics that run over it, and the response actions you take from the portal. That is a complete detection and response capability and it is not a complete endpoint security capability, because two of the five layers in ES0.3 belong to products beside it.

Configuration is the first borrowed thing. MDE reads a device's state and reports it; it does not push policy. Every ASR rule, every exclusion, every baseline and every compliance requirement in this course is delivered by Intune, and an estate with MDE and no device management can see everything and change nothing. That split is why the deployment sequence in ES0.7 starts with management rather than with the sensor.

// Which workloads are actually contributing entities to your incidents
AlertEvidence
| where Timestamp > ago(30d)
| join kind=inner (SecurityAlert | project AlertId=SystemAlertId, ProductName)
            on $left.AlertId == $right.AlertId
| summarize Entities = dcount(EntityType), Alerts = dcount(AlertId)
            by ProductName
| sort by Alerts desc

A workload missing from that result is a workload contributing nothing to correlation, which is a different finding from it being quiet. Run it before assuming the join is working, because an absent product name looks the same as a peaceful month.

Identity is the second. MDE calculates a device risk level and publishes it, and the thing that acts on risk is Conditional Access, which lives in Entra ID. The sensor cannot block a sign-in. It can say the device is compromised, loudly and accurately, to a system that will do nothing about it unless somebody wrote the policy.

Read the two columns on the right against the first. Entitlement is uniform because it came in a bundle; configuration is not, because each row is a separate piece of work owned by a different person. The two rows reading no are the two that need somebody outside the endpoint team, which is not a coincidence.

Both borrowings share a shape worth naming now, because it recurs in every module after this one. MDE is a signal producer, and a signal has no effect until something consumes it. The sensor is very good at the producing half and has no opinion at all about the consuming half, which means the quality of your endpoint security is bounded by configurations that live in other people's portals.

That also settles a licensing question people arrive with. Defender for Endpoint Plan 2 does not include Intune, and an E5 bundle that includes both does not configure either. The bundle buys entitlement; every arrow on the figure below is a piece of work somebody has to do, and the gap between what an organization is entitled to and what it has configured is the single largest finding in most endpoint reviews.

Arrow four is the scenario at the top of this section, and the reason it deserves its own figure is that the failure has no symptom. There is no error, no unhealthy device and no gap in a report, because from MDE's side the job finished successfully.

A process starts on a device. The sensor captures it, batches it, and sends it to the service, where it is enriched, evaluated by the analytics, and written into the hunting tables. Under normal conditions the row is queryable within minutes, which is fast enough to hunt on and slow enough that a rule running every five minutes will sometimes miss what it is looking for.

Knowing where the delay sits matters when a hunt comes back empty. An empty result has three quite different causes and they need separating before you conclude anything: the event did not happen, the event happened on a device that is not reporting, or the event happened and has not landed yet. The third is the one people rule out last and it is the cheapest to check.

Two of the six hops are worth knowing individually because they behave differently under load. Batching on the device means events leave in groups rather than one at a time, so a burst of activity arrives as a burst rather than smoothly, and a rule with a narrow window can straddle the gap between two batches. Enrichment on the service side is what adds the fields your queries actually filter on, such as the initiating process chain, and it is the reason a raw event and a queryable row are not the same object.

The practical form of all this is a habit rather than a theory. When a hunt returns nothing, check the device is reporting before you rewrite the query. Most of the time you have written a correct query against a machine that has been off for a fortnight.

PS C:\> Get-MpComputerStatus | Select-Object AMServiceEnabled,
            RealTimeProtectionEnabled, IsTamperProtected

AMServiceEnabled          : True
RealTimeProtectionEnabled : True
IsTamperProtected         : False

PS C:\> Get-Service Sense | Select-Object Status, StartType

Status  StartType
------  ---------
Running Automatic

Sense is the sensor service and the first thing to check on a device that has gone quiet. Note the third line of the first reading as well: tamper protection off means the settings above it can be changed by anything running with sufficient privilege, so a healthy reading is only as trustworthy as the protection around it.

// Which devices have stopped reporting, and how long ago
DeviceInfo
| summarize LastSeen = max(Timestamp) by DeviceName
| extend QuietFor = datetime_diff('hour', now(), LastSeen)
| where QuietFor > 24
| sort by QuietFor desc

Run that before you trust any fleet-wide figure. A device that stopped reporting three weeks ago is absent from every hunting result and from every coverage percentage, so it improves your numbers by being invisible, which is the same arithmetic that made the metrics in ES0.4 misleading.

The device risk to Conditional Access chain has four steps and each is somebody's job. MDE has to be connected to Intune so compliance can consider its signal. A compliance policy has to include the device risk requirement. Conditional Access has to have a policy that requires a compliant device. And that policy has to be on rather than in report-only.

Any one of those missing produces the scenario, and only the first two are visible in an endpoint console. The last two live in a different portal, usually owned by a different team, and the handover between them is where estates lose the chain. It is worth being blunt that this is an organizational seam rather than a technical difficulty: the configuration takes an afternoon and the agreement about who owns it takes considerably longer.

Two things make the seam wider than it needs to be. The first is that the failure is invisible from both sides: the endpoint team sees a risk level published correctly and the identity team sees a tenant with no error in it. Neither is looking at a broken thing. The second is that the check requires somebody with read access in both portals, and in most organizations that person exists but has never been asked to run it.

The fix is a standing question rather than a project, and it is worth adding to whatever review already happens. Name one policy in your tenant that acts on device risk. If nobody can, the endpoint's most valuable output goes nowhere, and that is true no matter how good the detection engineering above it becomes.

Here is Northgate's version of that chain, exported for review. It was built by people who knew what they were doing, and several things in it that look wrong are correct. Mark what you would raise before reading the questions.

The report-only finding is the one worth carrying out of this section, because report-only is not a broken state. It is the correct place for a new policy and it becomes a fault the moment nobody scheduled the review that takes it out. Every organization has policies in report-only that were meant to be enabled a fortnight later, and the only way to tell them from ones that belong there is to ask what date the review was set for.

Defender for Office 365 covers mail and collaboration, Defender for Identity covers on-premises Active Directory, and Defender for Cloud covers servers and cloud workloads. None is this course, and all three matter to it, because a single intrusion routinely crosses two or three of them and the correlation that joins them only works over the workloads that were connected.

The practical consequence is about who owns which phase rather than which product is best. A phishing email is Office 365's phase. The macro that runs on the laptop is yours. The domain credential the operator then uses is Defender for Identity's. The server they reach is Defender for Cloud's. One operator, four owners, and the handover points are where an incident gets dropped rather than escalated.

One incident, and the entities that made it one incident

  INC-2026-0310-003    severity high    4 alerts, 3 workloads

  entities             account   d.thompson@ne.com     O365, MDE, MDI
                       device    NE-THOMPSON-LT        MDE
                       device    NE-WILLIAMS-LT        MDE
                       file      Quarterly_Review...   O365, MDE
                       ip        185.234.89.112        MDE

  workloads connected  Office 365, Endpoint, Identity
  workloads absent     Cloud

The server phase raised its own alert, on a different day,
with no entity in common.

Read the entity column rather than the alert count. The account appears in three workloads and that repetition is the whole mechanism: correlation is not a product deciding two things are related, it is the same string arriving from two places. The server alert is absent from this incident not because it was less severe but because nothing in it matched anything here.

Read the last row rather than the products. Correlation is not a fifth product, it is a property of the four being joined by shared entities, and a workload nobody onboarded does not weaken the join, it removes an entity from it. That is why an estate with excellent endpoint coverage and no mail connector experiences a phishing-led intrusion as two unrelated alerts on different days.

It is worth saying plainly what this course does and does not claim about that. ARC402 makes the endpoint phase defensible and gives you the readings to prove it. It does not make you responsible for the other three, and an endpoint engineer who tries to cover all four ends up shallow everywhere. What the section asks of you is narrower and more useful: know which phase is yours, know which signals you publish outward, and be able to say which of the other workloads are connected, because that answer changes what your own alerts mean.

The handover points deserve one concrete note. An incident that arrives already correlated is a different object from four alerts a person joined by hand, and the difference is usually whether shared entities existed. An account name spelled one way in one workload and another way in a second does not join, and that is a data-quality problem that produces what looks like a coverage problem.

For years the decision was a table lookup. A rule touching only endpoint tables became a custom detection in the Defender portal; a rule needing firewall, proxy or anything else in the workspace became a Sentinel analytics rule; and a rule needing both meant paying to ingest the endpoint data into Sentinel as well. That is the version most blogs, most runbooks and most people's habits still contain.

It is no longer the decision. Custom detection is now the default wizard when you create a rule from advanced hunting, and a custom detection can query Defender tables and Sentinel tables together without ingesting one into the other. Creating an analytics rule is a button inside the custom detection wizard rather than a separate path, for the cases that still need one.

What follows from the change is worth more than the change itself. The cost argument that used to decide this is gone, so the decision is now about what a rule needs rather than about where its data lives. Several endpoint-specific functions became available to rules spanning both sides, and native response actions can be attached to a custom detection so that a rule firing can act rather than only alert. That last part moves detection engineering next to the automation decisions in ES7 rather than leaving it a separate discipline.

There is a second-order effect worth planning for. Because the wizard now defaults to custom detections, a tenant that has been running for a few years accumulates two populations of rules with different histories, different owners and different behavior, and the newer ones are easier to create. Counting rules across both is how organizations end up reporting a coverage figure nobody can reproduce, which is the same failure ES0.4 described one level up.

None of this makes the older path wrong. Analytics rules still exist for the cases that need them and the wizard still offers the route. What changed is the default and the cost, and a decision made on the old cost model is now being made on a fact that is no longer true.

The general form of that is worth carrying beyond this one change. A runbook records a decision and not the reasoning behind it, so when the constraint that drove the decision disappears, nothing in the runbook notices. Anything in yours that exists to work around a cost or a limitation is worth dating, because the workaround outlives the problem by years and looks like policy while it does.

A custom detection has a frequency, and where the rule touches Defender XDR data the lookback period is fixed by that frequency rather than chosen. This catches people, because the two feel independent and are not.

Read the two lines underneath. Rarity detections need the long window, so they are daily rules and they will find things hours after the fact. Rules meant to catch something while it is happening run hourly and cannot reason about anything older than four hours, so a query written as "first time this device has ever done X" will silently become "first time in four hours" and fire constantly. The frequency is not a scheduling preference; it decides what the rule is capable of asking.

The second constraint is sharper because it produces a rule that looks deployed. If a Defender table is not streaming into the workspace but Sentinel recognizes it as a standard table, an analytics rule written against it saves successfully and then never runs correctly, because there is no data on that side to run against. The rule appears in the list, shows no errors, and finds nothing forever.

That state is worth recognizing precisely because it survives every check people usually run. It saves. It appears in the rule list. It has no error indicator. A coverage count that reads the list rather than the run history counts it as a detection, and every report built on that count is wrong by however many of these an estate has accumulated.

Both traps in this section share a cause, which is that a rule has two states people conflate: deployed and effective. Everything an interface shows you by default is about the first. The lookback constraint decides whether an effective rule can see far enough, the streaming constraint decides whether it runs at all, and neither appears next to the rule name.

One more trap belongs with these, and it lands on estates that keep detections in source control. When Microsoft renames a table or a column, the change is applied automatically to queries saved inside Defender and not to queries held anywhere else. A repository is anywhere else. The table your pipeline deploys keeps the old name, the deployment succeeds, and the rule breaks quietly the first time it runs after the rename.

Everything in this section reduces to four questions, and the order matters because each one makes the next cheaper to answer. Establish whether the sensor is reporting before you ask about telemetry. Establish whether telemetry is landing before you ask whether a rule fired. Establish whether the risk signal is published before you ask whether anything acts on it.

Working in that order is not fussiness, it is what stops you debugging the wrong layer. A rule that finds nothing on a fleet where a quarter of devices stopped reporting is not a rule problem, and an afternoon spent rewriting the query is an afternoon that would have been saved by one count taken first. The order also matches the cost: the first two checks are a query each and the last one requires a conversation with another team.

The fourth row has no entry under signal or where, and that is the finding rather than an omission from the card: its absence is not an event, so the only check available is to go and look for a policy that consumes the signal.

The third row is worth a sentence of its own because it sits between the two extremes. A compliance state that has stopped updating does not turn red, it stays at whatever it last was, so a device that fell out of management a month ago is still reporting compliant and still satisfying whatever policy depends on it. That is failure as a frozen value rather than as an error, and the check for it is the age of the evaluation rather than its result.

The same reasoning applies to anything else in your estate that reports a state rather than an event. Ask what the value would look like if the thing producing it stopped, and if the answer is that it would look exactly as it does now, the value needs a timestamp beside it before it can be trusted. That single question resolves a surprising number of arguments about whether a dashboard is accurate.

Run the four checks in this order once a quarter and the whole section collapses into about twenty minutes of work. It is worth putting in a calendar rather than in a runbook, because three of the four failures described here develop over months without anybody touching anything.

The next section takes the estate this course uses throughout, names every population in it, and shows why the machines that acquire controls last are the ones an operator most wants to reach.