The device-risk article took a position: the machine risk score belongs in the access decision only for a small, high-assurance, always-reporting population, carved into its own compliance policy, while the rest of the fleet is gated on the health signals that do not go stale. This build wires that position. It connects the risk signal, writes the compliance policy that consumes it, and puts the conditional access gate in front of it, and it does all of that in report-only first, because the difference between a gate that protects the estate and one that locks people out is entirely in the sequence you build it.
Turning on the compliance path
The connector you enabled in the onboarding build carried the tenant relationship. The risk-into-compliance path is a separate set of toggles in the same Intune blade, under Endpoint security and Microsoft Defender for Endpoint, and every one of them defaults to off. The compliance-facing switches connect Windows, Android, and iOS devices to Defender for Endpoint so their machine risk can feed a compliance policy; the Windows switch is the one this build turns on, and its name lost the old version qualifier it used to carry, so confirm the current label rather than searching for the phrase you remember. A separate group of switches connects the mobile platforms to the app-protection path instead, which is the mobile-threat route into app protection policies rather than device compliance. Turn on only the platforms you actually intend to gate. A toggle enabled for a platform you have no policy for is a connection that does nothing but widen the surface you have to reason about.
The compliance policy
The risk rule lives in a Windows compliance policy under the Microsoft Defender for Endpoint category, where it requires the device to be at or under a machine risk level: clear, low, medium, or high, from most to least strict. The device-risk article laid out why Microsoft’s own guidance splits between low and medium here and took the position that low is right for the population that should be subject to this rule at all, precisely because that population is small and well-behaved enough to carry a low ceiling without constant friction. The more important design choice is the one the article argued and this build enforces: this rule goes in its own compliance policy, assigned to the high-assurance device group, and nowhere else.
That policy should not carry the risk rule alone. Pair it with the health attestations that make a device demonstrably sound without depending on a live risk score, because those are what keep the general fleet compliant when the risk signal is not part of their gate at all.
| Setting | Value | Why |
|---|---|---|
| Require the device to be at or under the machine risk score | Low | The risk gate itself, on the high-assurance population only. Alert-driven, so it moves with real detections. |
| Require BitLocker, Secure Boot, code integrity | Require | Health attestations that never go stale. These hold a device to a hardware and boot standard the risk score does not measure. |
| Defender antimalware, real-time protection, signatures up to date | Require | Confirms the engine you tuned is actually running and current, which is the fleet-wide floor beneath the risk gate. |
| Mark device noncompliant, schedule 0 days | Immediate | For the risk gate, act at once. A grace period on a risk rule is a window in which a genuinely risky device keeps its access. |
The schedule value is worth a sentence, because a grace period on this rule works against it. A device that goes noncompliant with a schedule of zero is marked noncompliant immediately; a device with a grace period enters an in-grace-period state that, in Microsoft’s worked example, keeps access under conditional access until the period expires. For hardware and patch attestations a short grace period is humane. For the risk rule specifically, it is the difference between a compromised device losing access now and losing it next week, so keep it at zero.
The gate, in report-only
Compliance without conditional access is a status nobody acts on. The gate is a conditional access policy whose grant control requires the device to be marked as compliant, and the single most important thing about building it is that it starts in report-only mode, not on. Report-only evaluates the policy against every sign-in and records what it would have done without doing it, which is how you find the population you are about to lock out before you lock them out. Read the report-only results in the sign-in logs for a real period, widen or fix what it would have wrongly blocked, and only then flip the policy on.
Two exclusions are not optional. Your break-glass accounts and your directory synchronization account must be excluded from this policy entirely, because a compliance gate that catches them is how a tenant locks itself out of its own recovery path. And a specific caveat belongs in the build: a compliance-requiring policy in report-only can prompt macOS, iOS, and Android devices for certificate selection during evaluation, so exclude those platforms from this Windows-device policy rather than letting it reach devices it was never meant to gate. Scope the policy to the platforms and users it is actually for, exclude the accounts that must never be caught, and the gate does its job without becoming an incident of its own.
Two tenant settings that set the default
Underneath the policies, two tenant-wide compliance settings decide what happens to everything you did not explicitly cover. The compliance status validity period, thirty days by default, is how long a device’s last evaluation stays trusted before it is treated as no longer active, which is the compliance-side echo of the seven-day sensor-inactivity threshold and worth understanding as the same kind of staleness control. And the setting that marks devices with no compliance policy assigned defaults to treating them as compliant, which is the wrong default the moment conditional access is enforcing, because it means an unmanaged device satisfies the gate by having no policy at all. Set it to mark unassigned devices as not compliant, so that being ungoverned fails the gate instead of passing it.
Proving the loop end to end
The whole point of this build is a loop, from a threat on a device to a changed access decision, and the only way to trust it is to run it once. The Defender portal hosts a set of guided attack simulations, reached now through the help menu rather than the older evaluation area, and the document-drops-backdoor scenario is the right one for testing the gate. The chain you are watching for is specific: run the simulation on a pilot device in the high-assurance group, watch an alert surface in the portal within roughly ten minutes, see the device risk level rise on its inventory record, trigger a manual device sync from Intune rather than waiting on the check-in cycle, confirm the compliance policy flips the device to noncompliant in its per-setting status, and then find the sign-in in the report-only results showing what the gate would have blocked. Resolve the alerts, let the risk recalculate, sync again, and watch it return to compliant. That round trip is the proof.
Two honesty notes make the test trustworthy rather than misleading. Microsoft does not publish a propagation time for how long the risk signal takes to travel from Defender into Intune, so do not build a test that asserts one; use the manual sync to force the point and observe what actually happens. And whether a given simulation moves the machine risk score at all is not documented behavior, so treat a score change as an observation you confirm in your own tenant, not a guarantee. The check that matters is the shape of the loop: a real detection changes a real access decision, and clearing the detection restores it.
Where the endpoint block ends
That closes the endpoint block at every level. The decision tier argued what to do; this build tier stood each decision up in the console, from onboarding a sensor to gating access on its verdict, with the one documented contradiction between the antivirus and attack-surface builds surfaced rather than buried. The endpoint is the spine of this series, and it is now built as well as mapped. From here the series works outward to the other pillars of the suite, each of which gets the same treatment: the map first, then the build.
Defender XDR
‹ Previous: [D 2.5] Device Risk, Inventory, and the Compliance Loop
Next: [D 3] Defender for Identity: The Identity Fabric Has Two Ends ›
