Everything so far has been about making the endpoint strong. This last piece is about what the endpoint then says about itself, because a managed device produces a risk verdict, and that verdict can flow into compliance and from there into conditional access. Done well, it closes the loop between endpoint security and who gets to reach your resources. Done carelessly, it is the single fastest way to lock your own users out of everything they need, from a cause that has nothing to do with an actual threat. This is the article where the series is most opinionated, because the difference between those two outcomes is entirely a matter of design.
The connector, and what it actually evaluates
The link between Defender and Intune is a connector you enable on both sides, in the Defender portal and in Intune, after which it quietly connects every managed device and every future one. What it evaluates is narrower than people assume, and the gaps matter. Machine risk feeds compliance evaluation on Windows, Android, and iOS. The mobile threat signal that flows into app protection policies is Android and iOS only. And macOS is not supported for machine-risk compliance at all, which means any design that expects a Mac’s Defender risk score to gate its access is building on a capability that does not exist. This is worth stating early because the compliance-and-conditional-access machinery will happily let you author a policy that silently evaluates nothing on the platforms it does not cover. Know the surface the connector actually reads before you make access depend on it.
The risk score is an alert score
The device risk level that compliance consumes is, in practice, a function of active alerts on the machine, their number, type, and severity. It is not a measure of how the device is configured or how exposed its software is; that is the separate exposure level, and conflating the two leads to muddled policy. The compliance rule lets you require a device to sit at or below one of four levels, clear, low, medium, or high, and here Microsoft’s own guidance is not unanimous. The Intune documentation recommends low as the best balance of security and productivity for most organizations. The Zero Trust guidance recommends allowing access at medium or lower. Both are current, and the disagreement is real rather than a documentation lag. My position is that low is the right target for the population where you actually want risk in the access decision, precisely because that population should be small and well-behaved enough that a low ceiling is not a constant source of friction. But the more important decision is not the number. It is which devices are subject to the rule at all.
The brittleness that locks people out
Here is the part that earns the article, because the risk-in-compliance rule fails users for reasons that have nothing to do with risk. A device only registered to Entra, without a full Entra join or hybrid join, does not receive a machine risk score at all, and a compliance rule that requires a score it can never produce will mark that device non-compliant and cut it off. A device that stops reporting to the sensor for more than seven days is treated as inactive, and its risk score goes stale or disappears, with the same downstream effect. A freshly onboarded machine can read hot for a short window before its picture settles. In every one of these cases the device is not compromised. It is simply not producing the clean, current signal the rule demands, and conditional access cannot tell the difference between a genuinely risky device and one that is merely quiet. Each of these is a self-inflicted lockout waiting to happen, and they happen most often to exactly the people who can least afford it, executives on new hardware, remote staff whose machines sleep for a week, the population you were most trying to protect.
The design that survives contact
The way through is to stop treating the risk score as a fleet-wide gate and start treating it as a control for a specific, well-chosen population. Reserve the risk-level compliance rule for a high-assurance subset of devices that you know are Entra or hybrid joined, that report continuously, and that run Windows, and carve that rule into its own compliance policy targeted only at that group. For the rest of the fleet, lean on the controls that do not go stale or blind: disk encryption, patch level, a firewall that is on, Defender actually running. Those make a device demonstrably healthy without betting access on a signal that vanishes when a laptop sleeps. Then wrap the whole thing in the discipline the Intune guide already teaches for conditional access, rolling the policy out in report-only mode first, watching who it would have blocked before it blocks anyone, and always excluding your break-glass accounts and your directory synchronization account from the policy entirely. The risk score is a genuinely powerful signal. It earns its place in the access decision only when you have decided, deliberately, which devices are reliable enough to stake a login on.
Inventory and exposure, the quieter half
Risk is the loud signal, the one wired to access. The same platform produces a quieter set of signals worth knowing about. Device discovery, a Plan 2 capability, uses your onboarded endpoints to find the unmanaged devices sitting on the same networks, running by default in a standard active mode that fingerprints what it sees. It is how the machines nobody enrolled become visible, which is often the first step to managing them. One current caveat belongs in any design that leaned on it: authenticated scanning for Windows devices has been deprecated, so a discovery approach built around it needs rethinking. Alongside discovery sits the core of Microsoft Defender Vulnerability Management, included with Plan 2, which scores your exposure and turns it into prioritized recommendations. Be careful quoting a specific exposure number right now, though, because the scoring model is mid-migration to a newer method that weighs exploit probability and asset context, and during the rollout two models coexist and the same estate can show different scores depending on which one it is on. Read the recommendations, not the single headline figure, until the model settles. This vulnerability signal is also the natural bridge outward from the endpoint into the wider suite, where exposure across identity, cloud apps, and mail gets scored together.
Where the endpoint block ends
That closes the endpoint block. Across it we onboarded devices without conflating the act with configuration, learned to configure the ones we deliberately left unenrolled, tuned the protection engine past its defaults, reduced the attack surface with rules that are precise rather than blunt, and finally decided, carefully, when a device’s own verdict should govern its access. The endpoint is the spine of this series because it is the workload whose signal everything else correlates against, and it is now standing. From here the series works outward to the other pillars, identity, mail and collaboration, cloud apps, exposure management, and the correlation fabric that turns their separate alerts into single incidents, the payoff the suite anchor promised. Those pillars are where we go next.
Defender XDR
‹ Previous: [D 2.4.1] The Attack Surface Reduction Policy Set
Next: [D 2.5.1] Wiring Risk to Access: Connector, Compliance, and the CA Gate ›
