Building a Modern Endpoint Architecture with Intune + Entra ID + Defender

Most enterprise tenants have all three of these products deployed. Entra ID handles sign-in. Intune manages devices. Defender watches for threats. And in most of those tenants, the three run as three separate tools that happen to share a licence bundle, not as the single correlated architecture they were actually designed to form.

That gap, deployed versus wired together, is what this post is about. Here's the shape of the whole thing first, then each layer in depth, then the part almost nobody configures that makes the other two actually talk to each other.

                    Microsoft 365
                         |
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
     Entra ID          Intune          Defender
        ↓                ↓                ↓
   Identity          Endpoint         Security
        └────────────────┼────────────────┘
                         ↓
                 Conditional Access
                         ↓
                    Enterprise

This maps directly onto three of the six pillars in Microsoft's own Zero Trust framework: Identity, Endpoints, and (partially) the signal correlation that feeds Applications. It doesn't cover Data or Network, and I'll say plainly where this diagram's scope ends later on. What it does cover, it covers deep.

The Foundation: Identity Comes Before Everything Else

Here's the sequencing almost every simplified architecture diagram glosses over: a device has to establish an identity in Entra ID before Intune can manage it at all. Registration and enrollment are not the same step, and conflating them is where a lot of "why won't this device enroll" tickets actually start.

This is also where Entra ID's Identity Protection lives: user risk and sign-in risk, MFA, and Privileged Identity Management for just-in-time admin access. Everything above this layer, endpoint management, security telemetry, Conditional Access itself, is being evaluated in the context of an identity this layer already vouched for.

The Endpoint Layer: Intune Defines "Healthy"

Once a device is enrolled, Intune's job is to define, enforce, and continuously verify what a healthy device actually looks like: encryption, OS version, password policy, and every application on it, wrapped, detected, and deployed correctly. I've written extensively about the mechanics underneath this layer, what actually happens after you upload a .intunewin file, why detection rules report the wrong answer, when dependencies and supersedence apply, and how Autopatch now controls the update side of that health definition. All of that operational depth exists to answer one architectural question reliably: is this specific device, right now, in the state we've decided counts as trustworthy.

That answer becomes the compliance signal, and it's a narrower answer than people assume, a device passing every one of Intune's checks is telling you it's configured correctly, not that it's currently safe. That distinction is the entire subject of compliance versus security, worth reading in full if you haven't; this post assumes it and builds on top of it.

The Security Layer: Defender, and What's Actually Underneath It

The diagram shows one "Defender" box. What's actually running underneath it is Microsoft Defender XDR, a correlation engine sitting across Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, and Defender for Office 365, fusing their signals together rather than reporting them separately.

Here's a concrete example of why that fusion matters. Defender for Identity detects an on-premises Kerberos attack against a hybrid-joined account, a completely different product and completely different signal type than anything Defender for Endpoint or Entra ID would see on their own. That detection doesn't stay siloed:

This is also where Defender for Endpoint's device-level risk score feeds back down into the Intune layer, covered in detail in the compliance post linked above: a device Defender flags as high-risk can be made to fail Intune compliance automatically, but only if that specific integration setting is actually configured. The fusion described here happens on the identity side regardless; the device-to-compliance link is something you have to deliberately wire in.

Where the Three Actually Meet: Conditional Access

Conditional Access doesn't generate any signal of its own. It's the decision engine that reads what the three layers above produced, device compliance from Intune, the fused risk score from Defender XDR flowing through Entra ID Protection, plus location, client app, and required authentication strength, and turns all of it into one access decision: grant, block, or require more.

That's the architectural reason "require compliant device" alone is an incomplete Conditional Access strategy. It's reading exactly one of the signals this whole stack was built to produce.

Enterprise: What the Decision Actually Protects

The bottom of the diagram, "Enterprise," is deliberately abstract, because what it represents varies: SharePoint, an internal LOB app, a financial system, email. What's consistent is what Zero Trust actually means at this final step: access isn't a single decision made once at sign-in. It's continuously re-evaluated as the signals above it change. A user who was compliant and low-risk an hour ago and is now flagged by Defender XDR doesn't keep their access because they already got in once, the next policy evaluation sees the new state and acts on it.

A Maturity Checklist

Deploying all three products gets you the diagram's shape. These specific configurations are what actually wire it together:

Five checks, and most tenants that have deployed all three products for years still fail at least one of them. That gap between "we have the licences" and "we built the architecture" is exactly what turns three separate consoles into the single trust fabric this diagram is actually describing.

Which of these five is still open in your own tenant? For most environments I've reviewed, it's the separated risk policies, user risk and sign-in risk sitting in one combined rule instead of two. Drop a comment below with what you found in yours.