Advanced Zero Trust: Device Health, and the Eight Hours Inside It
In this article
Summary
Meet corporate Windows laptop "LT-2291". It is enrolled in Intune, onboarded to Defender for Endpoint, covered by a compliance policy, and its user reaches Microsoft 365 through a Conditional Access policy that requires a compliant device. On paper it is the finished picture. At 14:02 on a Tuesday something lands on it, Defender for Endpoint raises the machine risk score, and the device becomes non-compliant, and the next access request is blocked. Every clause of that is true, and the sentence still leaves out the two things that decide whether device trust works in a tenant: the configuration each hop assumes you already did, and the time each hop takes. This article works through both, then looks at the harder half of the control map, which is the devices you do not own and the local administrator rights you have not yet taken away.
Testing the Propagation Claim
Take the sentence apart by drawing it against a clock.
The check-in interval is the dominant term. Across platforms the estimated schedule is roughly every eight hours, and a device is permitted only one maintenance sync every six and a half hours regardless of what its own schedule says. Freshly enrolled devices poll far more aggressively, every few minutes for the first stretch, which is exactly why a pilot feels instant and the fleet does not. Intune will push a notification to online devices when policy changes, and that helps, and it is best effort rather than a guarantee.
Three pieces of configuration have to exist before any of this moves at all, and none of them is on by default.
| Hop | What has to be true first | Typical delay |
|---|---|---|
| Defender to Intune | The Intune connection toggle switched on in the Defender portal, then the per-platform toggles under Compliance policy evaluation in Intune | Minutes. The connection status itself can take 15 minutes to show as enabled. |
| Risk score to compliance | A compliance policy that actually contains "Require the device to be at or under the machine risk score." Without that rule the score is computed and consumed by nothing | None, but only at the next evaluation |
| Compliance to Entra | Nothing extra. This part genuinely is plumbing | Follows the device check-in, so up to 8 hours |
| Entra to the gate | A Conditional Access policy granting on compliant device, and a token request to evaluate | Token lifetime, unless continuous access evaluation is in play |
Table 1 - Describes the two toggles and one policy rule. Miss any of them and the pipeline looks configured while carrying no signal.
The threshold itself deserves a look before it is set and forgotten. Require the device to be at or under the machine risk score takes Clear, Low, Medium or High, and High permits every threat level, which makes it a reporting posture rather than a control. Microsoft's own recommendation is Low. Worth knowing too that the compliance integration lists Windows, Android and iOS or iPadOS as its supported platforms. A Mac can be onboarded to Defender and still not feed a machine risk score into a compliance policy the way "LT-2291" does.
Risky devices are described as self-healing, and the block side of that is fair. The unblock side usually is not. The risk score falls when the underlying incident is resolved in Defender, and resolving an incident is generally analyst work. So the path into the blocked state has nobody in it, and the path out often has a queue.
Compliant by Default
There is a tenant-level setting called Mark devices with no compliance policy assigned as. It ships set to Compliant. A device that has never been evaluated against anything therefore reports isCompliant: true, and a grant control requiring a compliant device waves it through.
The second thing to check is what a failure is scheduled to do. Actions for noncompliance are a sequence, each with its own timing, and a grace period on the block action means the device carries on as compliant for however many hours you configured after it has already failed the policy.
Read the last two lines together with Figure 1 and the arithmetic is uncomfortable. Eight hours to notice, twenty-four hours of grace, and a token lifetime on top. That is a design choice somebody made for good reasons about help desk volume, and it should be an explicit number in a document rather than a default nobody revisited.
Data Where You Cannot Manage the Device
App protection policies are the honest answer to personal devices, and the honesty is the part worth teaching. They protect the app and its data. They do not protect, inspect, or know much of anything about the machine underneath.
What survives the loss of enrolment is more than people expect. Work app data can be encrypted at rest behind an app PIN, copy and paste and save-as can be constrained to managed destinations, and corporate data can be wiped selectively without touching a personal photo library. Conditional launch adds a genuine security signal on top: a maximum allowed device threat level of Secured, Low, Medium or High, sourced from Defender for Endpoint, with either Block access or Wipe data as the response. That evaluation runs on iOS and Android whether or not the device is enrolled, which is the single most underused fact in this part of the stack.
Which Grant Goes Where
In Conditional Access this becomes two grants rather than one. Corporate devices like "LT-2291" get the compliant device requirement. Personal devices get the app protection policy requirement, which admits the device and constrains the app. Trying to serve both populations with a single compliant-device policy produces the predictable outcome, which is an exclusion group that grows quietly and never shrinks.
Taking Admin Off Every Desk
Endpoint Privilege Management inverts the usual arrangement. The user account holds no administrative rights, and individual processes are elevated according to rules that match on file details and publisher certificate. Alongside the three elevation types there is an Elevate as current user variant, which runs the elevated process under the signed-in user's own account so that tools depending on user-specific paths keep working. It is a compatibility valve, and it is the one to audit most closely.
The trap here rhymes with the one in Privileged Identity Management. An automatic elevation rule with a loose match is standing local administrator with extra logging, in the same way that an eligible role with auto-approval is standing directory administrator with a delay. The rule set is the control, not the feature. Deploy in audit mode, read the elevation report for a few weeks, and build rules from what people actually run, because the report will hand you the file hashes and certificates to write them with. Two practical notes: this is a licensed Intune add-on rather than a toggle in the base product, so it is a budget conversation before it is a technical one, and removing local administrator from a fleet that has always had it will surface a queue of genuinely broken line-of-business applications. Both of those are easier to raise at design time than at go-live.
Conclusion
Binding access to current device state is the right design, and the state is a measurement with an age on it. For "LT-2291" the honest answer to how fast a compromised laptop loses access is the check-in interval plus any grace period plus the token lifetime, and every one of those three is a number you chose. Write them down, decide whether the total is acceptable, and check that the tenant is not quietly calling unevaluated devices compliant.