PotSolutions › Modern Workplace › Device Compliance

Zero Trust & Security

Device Compliance Is Where Zero Trust Either Holds or Fails

Multi-factor authentication, Conditional Access, even phish-resistant sign-in — every one of those controls inherits the trust level of the device it runs on. If that device was never verified, none of it holds up.

9 min read Updated July 2026

Most security budgets go into identity: stronger MFA, Conditional Access policies, phishing-awareness training. All of it assumes something that’s rarely checked with the same rigour — that the device on the other end of the session is actually safe to trust. In practice, it often isn’t.

Two very different attack techniques exploit exactly that gap. Info-stealer malware sitting on an unmanaged laptop can lift saved browser passwords, session cookies, and application tokens without ever triggering a login prompt. Adversary-in-the-Middle (AITM) phishing kits capture a live session token the moment a user completes MFA — on whatever device happens to be rendering the phishing page. In both cases, the identity check did exactly what it was built to do. It just didn’t ask the one question that mattered: is this device one we’d actually trust with company data?

A password reset does not fix either problem. Once a session token or cookie has been copied, it stays valid until it expires or is explicitly revoked — completely independent of what the user does with their password afterwards.

This is the argument for treating device compliance as a first-class control, not a checkbox ticked once during onboarding. We build it as the foundation every other Zero Trust control sits on — inside our own Modern Workplace & Enterprise Security baseline and in Config365, the automation platform that deploys it.

The Standard

What “Compliant” Actually Enforces

Continuous, Not One-Time

Intune compliance policies check that disk encryption is active, the firewall hasn’t been disabled, antivirus is running and reporting clean, and the operating system sits at a minimum patch level — before a device can touch anything. The part that matters is that this isn’t a one-off gate at enrolment. Compliance is re-evaluated on a recurring cycle, and a device that drifts out of policy mid-day loses its standing automatically, without anyone having to notice and step in.

That loop closes tighter still when Defender for Endpoint is in play. If it flags an active threat on a device, that signal feeds directly into Intune, which marks the device non-compliant in near real time — turning detection into enforcement in one automated step, rather than a ticket someone reviews the next morning.

OS Hardening, Not Just Antivirus

Attack Surface Reduction rules block the exact techniques ransomware and phishing payloads rely on — Office macros spawning child processes, scripts launching from temp or download folders. Controlled folder access stops unauthorised applications from touching OneDrive and document directories, and Network Protection refuses connections to known-malicious domains before they resolve. None of this depends on a user making the right call in the moment; it’s enforced at the OS level regardless of what gets clicked.

The Enforcement Layer

Binding the Session to the Hardware

Continuous Access Evaluation

A standard OAuth token is trusted until it expires — often an hour or more later, regardless of what happens to the device in between. Continuous Access Evaluation changes that assumption: Entra ID and connected services re-check critical signals near-instantly and can cut a session off the moment a device falls out of compliance, a user account is disabled, or a sign-in is flagged as high-risk. The token itself doesn’t need to expire for access to stop — the platform simply stops honouring it.

Conditional Access is what turns that compliance signal into an actual access decision. Company applications — Outlook, Teams, SharePoint — are only reachable from a device that passes its compliance check at the moment of the request. Fail that check, and access is blocked or restricted automatically, with no manual review in the loop.

Device-Bound Tokens

This is the piece that specifically defeats cookie and token theft. On a Windows device, the Primary Refresh Token is cryptographically bound to that machine’s hardware via a TPM-backed key. Token protection policies in Conditional Access extend the same idea to individual sign-in sessions. Copy that token file to another machine — exactly what info-stealer malware and AITM proxies are built to do — and it’s inert. It cannot be replayed anywhere else, because the token was never just “a secret,” it was a secret tied to specific hardware.

This is what turns “the user completed MFA” into “the user completed MFA, on a device we can verify, and it still counts an hour from now.” Remove the device-trust layer, and MFA only ever proves the first half of that sentence.

It Extends Past Microsoft’s Own Apps

Most organisations run more than Microsoft 365 — Salesforce, QuickBooks, internal line-of-business tools. Federate those through Entra ID with SAML or OAuth, and they inherit the same Conditional Access and device-compliance requirements as Outlook or Teams, rather than running their own separate, usually weaker, authentication path. One identity, one enforcement point, no gaps introduced by the third app nobody thought to lock down.

  • Single sign-on across Microsoft and federated third-party apps, without separate credentials to manage or reuse
  • The same device-compliance and Conditional Access checks apply, regardless of which app is being accessed
  • A session revoked or a device marked non-compliant loses access everywhere at once — not just inside Microsoft 365
BitLocker / FileVault Defender for Endpoint Conditional Access Continuous Access Evaluation Primary Refresh Token SAML / OAuth Federation

Deployed as Infrastructure, Not Paperwork

Device compliance only holds up if every policy, every Conditional Access rule, and every security group targeting stays consistent as the tenant grows — which is a poor fit for a manual settings checklist maintained by hand. We deploy this baseline through Config365, our open-source Microsoft 365 automation platform: policies as versioned configuration, changes previewed before they apply, and every tenant running the same audited standard rather than whatever survived the last onboarding session.

That’s also the difference between a security posture that degrades quietly over eighteen months and one that stays enforced. Related reading below covers what happens once a session token is actually stolen, and how CSS-based sign-in validation catches AITM phishing at the point of interception.

Related Reading

Session Token Theft: The Attack Path That Skips MFA Why device compliance is the control that neutralises a stolen token Agentless CSS Phishing Protection Catching Adversary-in-the-Middle phishing at the Microsoft sign-in page itself Modern Workplace & Enterprise Security The full Zero Trust baseline this control is part of

Get Started

Is Every Device on Your Tenant Actually Verified?

We’ll review your current Intune and Conditional Access setup, find the gaps that let unmanaged devices through, and close them — deployed and automated, not a one-time audit.

Start a Project View M365 Security Overview
Theme