The EDR→MDM→IdP Loop

The mechanism that makes tenet 5 real

Lesson 1.1’s tenet 5 said assume nothing is clean; monitor everything. Here is the machinery that turns that from a poster into an access decision — the single clearest Zero Trust mechanism in production today, and the reason Module 2 kept saying “device signals arrive in Module 3”:

  EDR (endpoint detection)        MDM (device management)        IdP (the PDP)
  ┌──────────────────────┐        ┌─────────────────────┐        ┌────────────────┐
  │ watches the device;  │ risk   │ compliance policy:  │ state  │ CA baseline's  │
  │ computes a live      │──────► │ "risk must be at or │──────► │ CA03: require  │
  │ machine-risk score   │ score  │ below threshold" +  │        │ compliant      │
  └──────────────────────┘        │ encryption, OS ver, │        │ device         │
                                  │ firewall, secure    │        └───────┬────────┘
                                  │ boot                │                │
                                  └─────────────────────┘                ▼
   detection at 2:03 p.m. ──► noncompliant at 2:04 ──► next access evaluation: BLOCKED

Walk the loop with Lesson 1.1’s own test case: a field tech’s laptop picks up an infostealer at 2 p.m. EDR’s risk score jumps to High at 2:03. The compliance policy — which includes “machine risk Medium or below” as a criterion — flips the device to noncompliant. The identity platform’s CA03 policy now fails the device condition, and the next token request (or continuous evaluation event — Lesson 4.3) is denied. The attacker’s window shrank from “until someone notices” to minutes on a well-wired stack — with the honest caveat: propagation latency is platform- and sync-cadence-dependent, and a lazily-configured loop takes an hour-plus. Measure yours (Lesson 4.3’s timeline exercise does exactly this), tighten the cadences, and let continuous evaluation close the remainder. Either way, no human was in the loop. That’s tenets 4, 5, and 6 operating as one system — detection became a policy input, not a ticket.

Design decisions that make it production-grade

Thresholds by tier. One threshold for everyone is either too loose for admins or too harsh for the fleet. The pattern: standard users blocked at High risk (“Medium or below” passes); privileged users and PAW devices blocked at anything above Low. Write it as a table, pair each row with its rationale, and revisit quarterly:

Tier                     Compliance threshold        Rationale
Standard workforce       risk ≤ Medium               containment without lockout storms
Privileged / tier-0      risk ≤ Low                  admin devices get no benefit of doubt
Unmanaged/BYOD           no compliance claim -->     app-protection policies + session
                         limited access (CA08)       controls instead - different door

Compliance ≠ enrollment. An enrolled device that hasn’t checked in for three weeks, is missing disk encryption, or runs an out-of-support OS is enrolled and unhealthy. The compliance policy is the health bar: encryption on, firewall on, secure boot, OS at supported version, EDR present and reporting, risk at threshold. “Enrolled” is the parking pass; “compliant” is the inspection sticker.

Report-only first — this rollout has a signature failure. The Module 2 discipline applies with extra force here, because device policies fail in bulk: enforce CA03 before the fleet is actually compliant and Monday morning is a lockout storm — hundreds of blocked users, a helpdesk fire, and a program that just spent its political capital (Lesson 1.3’s killer #1 in its most spectacular form). The sequence that works: compliance policy in audit → drive the fleet green (patching waves, encryption pushes) → report-only CA03 until surprises approach zero → enforce per department, never big-bang.

The 2025-26 problem this loop must also answer: token theft

Attackers adapted to strong authentication by stealing what comes after it: session tokens, lifted by malware or adversary-in-the-middle kits, replayed from the attacker’s machine — no password or MFA needed. The loop answers this two ways: the EDR leg (the infostealer that grabs the token also raises the risk score, revoking the device’s standing), and device-bound credentials — tokens and passkeys cryptographically bound to the hardware they were issued to, so a replayed token fails on any other machine. Bind what your platform supports (primary refresh tokens, session token protection policies, device-bound passkeys from Lesson 2.2), and treat “token works from anywhere” as the vulnerability it now is.

Prompt first

Design the device-trust rollout for this estate:
1. The compliance policy per platform (Windows/macOS/mobile): criteria list
   incl. EDR-risk threshold; mark which criteria are audit-only in phase 1
2. The tier table: thresholds for standard / privileged / BYOD, with rationale
3. The fleet-greening plan: current compliance % per criterion, the waves
   that raise it, and the enforce date each department earns
4. Token-theft posture: which credentials are device-bound today, which
   session-protection features we can enable, and the revocation runbook
   when EDR flags a device (who re-admits it, on what evidence)
Include the rollback: what un-enforcing CA03 takes if the storm hits anyway.

That last line in point 4 matters operationally: a blocked device needs a re-admission ceremony (EDR cleared + reimage-or-verify decision + compliance re-evaluated), not a helpdesk override — otherwise the loop’s teeth get pulled one sympathetic ticket at a time.

Key takeaway

Detection drives compliance drives access — the loop turns “assume breach” into an automatic response measured in minutes. Thresholds by tier, compliance as the health bar (never mere enrollment), report-only until the fleet is green, and device-bound credentials so stolen tokens die off-device. The device signal now exists; the next two lessons spend it on the network.