Intune Compliance Is Not Security: Understanding the Difference

"Our devices are compliant, so we're secure" is one of the most common false equivalences in enterprise IT, and it's dangerous precisely because it's half true. A compliant device really is meaningfully safer than a non-compliant one. But compliance is a report card against a fixed set of rules you wrote, checked periodically. It has no opinion on whether malware is running right now, whether a user's credentials were phished this morning, or whether the sign-in attempt using them came from somewhere it shouldn't have.

Here's the actual pipeline, and where each Microsoft product genuinely fits into it. If you want the underlying sync mechanism itself, how a compliance result actually travels from a device into an access decision, that's covered separately here.

Device State
     ↓
Compliance
     ↓
Conditional Access
     ↓
Access Decision

Device State: The Raw Facts

This is just what's true on the device, with no judgment attached. Is BitLocker on. What OS build is installed. Is a PIN configured. Is the firewall enabled. These are facts, collected the way I've described in how a device reports back to Intune, not opinions about whether that state is good enough for anything.

Compliance: A Checklist, Evaluated Periodically

Intune's job at this stage is narrow and specific: take the device state above, compare it against rules an admin wrote in advance, and output a binary-ish result, compliant or not. That's genuinely useful. It's also fundamentally limited in a way that matters:

I've written before about how even the compliance signal itself can be stale or wrong mechanically, a device that stopped checking in still shows its last known compliant status. Combine that mechanical lag with compliance's narrow scope, and "Compliant" in the portal is genuinely two layers removed from "currently secure."

Conditional Access: The Decision Engine

This is the layer that actually enforces anything, and the important architectural fact is that device compliance is just one input among several, not the whole picture. A Conditional Access policy can evaluate device compliance, user identity, sign-in risk, user risk, location, client application, and required authentication strength, together, in the same decision.

Treating "require compliant device" as your entire Conditional Access strategy uses exactly one of these signals and ignores the rest.

Where Microsoft Defender Fits

Microsoft Defender for Endpoint owns actual threat detection. Real-time behavioural analysis, active malware, EDR telemetry, the things a static compliance checklist was never designed to catch. It produces a machine risk score per device based on what it's actually observing.

That risk score doesn't reach Conditional Access on its own. It reaches Intune first, through a specific compliance policy setting: "Require the device to be at or under the machine risk score." Only once that setting is configured does a Defender-detected compromise actually flip a device to non-compliant, which is what Conditional Access can then act on.

Where Entra ID Fits

Entra ID Protection owns identity risk, and it's a completely separate axis from anything about the device. Two specific signals matter here:

Where Intune Fits

Intune owns the device side of this pipeline: collecting device state, evaluating it against compliance policy, and managing the configuration and applications that produce that state in the first place. It's the source of the device compliance signal Conditional Access consumes, and, when wired up correctly, the bridge that lets Defender's threat detection become an enforceable condition. It is not, on its own, a threat detection product.

Putting the Whole Picture Together

A Worked Example

A device shows "Compliant": BitLocker on, latest OS build, PIN configured, firewall enabled. It also has live malware Defender detected an hour ago.

Same incident, two completely independent detection and enforcement paths, neither of which is "compliance" by itself. Compliance was the delivery mechanism in the second step, not the thing that noticed anything.

The Actual Takeaway

Compliance is necessary hygiene: it keeps the baseline configuration honest and gives Conditional Access something concrete to require. It was never designed to be a security control on its own, and treating it like one leaves the exact gap Defender and Entra ID Protection exist to close. Real security in this stack comes from wiring all three signal sources together, device state, threat detection, and identity risk, into the Conditional Access policies that actually make the decision. Compliance alone is a report card. Security is what happens when that report card is one input among several the decision actually listens to.

Do you have the Defender-to-Intune compliance integration configured in your own tenant, or is device compliance still your only signal? I'd like to hear what pushed you to add the others. Drop a comment below.