Zero Trust Endpoint Architecture: Never Trust a Device Just Because It Is Corporate

"It's a corporate device" is the single most common unexamined trust assumption in enterprise IT, and it's wrong often enough to matter. A corporate laptop can be stolen, infected, jailbroken, or simply left signed in and unattended. Ownership was never the actual security property worth trusting. Zero Trust architecture exists specifically to stop treating "corporate" as a synonym for "safe."

User
  ↓
Identity
  ↓
Device
  ↓
Device Risk
  ↓
Intune Compliance
  ↓
Conditional Access
  ↓
Defender
  ↓
Application
  ↓
Data

This is a loop, not a one-way pipeline. Every request runs down through all nine stages, and the results feed back into the next request, continuously, for the life of the session and every session after it.

The Nine Stages

User: Where Every Request Actually Starts

Nothing below this layer is the point. It all exists to make one person's request to check email or open a file safe to grant, without them needing to understand any of the eight layers underneath it.

Identity: Verified Independently of the Device

Entra ID answers exactly one question at this stage: is this person who they claim to be. The full authentication ladder from password alone to phishing-resistant MFA is covered here. Critically, this layer says nothing about the device being used yet, identity and device are evaluated as two genuinely separate trust objects, which is the architectural decision that makes the rest of this post possible.

Device: A Separate Trust Object, Not Inherited From the User

A verified person on an untrusted device is still a real risk, which is why the device gets its own identity in Entra ID, established through a TPM-backed key pair, the hardware chain of trust covered in full here, rather than borrowing trust from whoever happens to be signed in.

Device Risk: A Continuous Signal, Not a One-Time Check

This is the stage that separates a genuinely Zero Trust architecture from one that just checks a box at enrollment and stops looking. Device risk pulls together live signals, Microsoft Defender's machine risk score based on actual observed behaviour, whether the device's boot state still matches what was recorded at Stage 3 of the hardware chain of trust, and whether anything about this specific sign-in attempt looks anomalous.

Intune Compliance: Configuration, Checked on a Schedule

The actual mechanism carrying a compliance result into an access decision is covered in full here: a scheduled evaluation, roughly every 8 hours by default, comparing the device's real configuration against policy, then syncing that result to the device's object in Entra ID.

Conditional Access: Every Signal Above, Combined Into One Decision

This is the actual decision point, and the two real combination rules underneath it are covered in full here: any matching policy that says Block always wins, and every required grant control from every matching policy has to be satisfied together. Identity, Device, Device Risk, and Compliance all feed into this single evaluation, none of them individually makes the call.

Defender: Watching What Happens After Access Was Already Granted

Application: The Specific Resource Actually Being Reached

Not every application deserves identical trust. Restricting access to genuinely sensitive applications, payroll, HR, finance, as their own distinct policy target is covered as its own pattern here, separate from the general-population policy protecting everything else.

Data: The Thing Every Layer Above Exists to Protect

The layer everything above was actually in service of. What happens to data specifically when the device holding it is lost, and why encryption is the layer that still holds even after every access control above it becomes irrelevant, is covered in full here.

A Worked Scenario: The Laptop That Still Looks Corporate

At no point in this story did "the laptop belongs to the company" do any actual security work. Every stage that mattered was evaluating something else entirely.

Summary

Where in your own environment does "it's a corporate device" still quietly substitute for an actual trust decision? Device Risk is the stage I see skipped most often, treated as a nice-to-have rather than the thing that catches what Compliance structurally can't. Drop a comment with what you've found.