Look for risky devices that can still access applications, policy exceptions that accumulate without review, and EDR health signals that do not affect access outcomes. If posture data changes but the login decision does not, the control is decorative rather than enforceable.
How to tell when device-health conditional access is failing
The clearest warning sign is a mismatch between device posture and access outcomes. If a device is known to be risky, out of compliance, or unhealthy, yet it still reaches protected apps, the policy is not enforcing the control path you think it is. The same is true when device state changes in your endpoint stack but sign-in decisions do not change.
That mismatch usually shows up in one of two ways: the access policy is too permissive, or the telemetry feeding it is stale, incomplete, or not trusted by the policy engine. In both cases, the device-health signal exists, but it is not materially shaping authorization at login.
Where the control usually breaks down
Device-health conditional access fails most often at the boundary between posture assessment and enforcement. A device may be marked noncompliant, but the policy scope excludes the app, user population, or authentication flow that should be blocked. Another common failure is reliance on a health source that is present for reporting but not wired into the actual decision.
Accumulating exceptions are another strong indicator. If risk-based bypasses, temporary exclusions, or break-glass paths become routine and are never reviewed, the control drifts from a policy to a paper record. At that point, the org may still be collecting device health data, but it is no longer using it to govern access.
For identity-centric enforcement, the useful comparison is not “do we have telemetry?” but “does the policy engine actually consume it at decision time?” NHIMG’s Zero Trust Identity Guide is relevant because continuous evaluation only works when the access decision is tied to the current state, not a stale one.
What to check in the access path
Start with sign-in logs, policy evaluation results, and the device status presented at the time of access. You are looking for evidence that unhealthy devices are still being granted access, or that the sign-in path is silently falling back to a weaker rule when the device-health check fails.
Then compare the control plane to the signal plane. If EDR, compliance, or management data changes but the conditional access decision does not, the integration is broken somewhere between source, sync, and enforcement. That gap is often more important than any single failed login event, because it reveals the control is decorative rather than operative.
Healthy device enforcement also depends on dependable identity and federation plumbing. NHIMG’s Identity Provider and SSO Security Guide helps frame the point that access decisions are only as strong as the token, session, and federation signals that feed them. If those signals are weak, the device check may never reach the point where it matters.
Device policy enforcement also needs a clear trust boundary for the endpoint itself. NHIMG’s Active Directory and Entra ID Hardening Guide is useful where device trust, privileged access, and hybrid identity controls overlap, because weak directory hygiene can undermine what looks like a device-only decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity Assured with Device and Session Context | Device-health conditional access is continuous access evaluation in practice. |
| Recommendation — Tie device posture signals to access decisions and re-evaluate trust continuously. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Device-health gating depends on trustworthy machine and endpoint authentication context. |
| AC-2 — Account Management | Persistent exceptions and stale access paths are account and access governance failures. | |
| Recommendation — Require strong device authentication and verify endpoint state before granting access. Review exceptions and revoke access paths that bypass device-health enforcement. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Conditional access is an access-control mechanism that must enforce current policy conditions. |
| Recommendation — Enforce access rules so device posture directly affects authorization decisions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is whether risky devices are still permitted through access controls. |
| Recommendation — Continuously test that risky devices are denied or step-up challenged as intended. | ||
Practitioner Guidance
What to prioritise: Validate the exact policy path first, not the headline posture score. If a risky device can still reach the app, treat that as an enforcement failure until proven otherwise, even if the device is technically “managed” or “compliant” in a dashboard.
What to verify: Confirm that unhealthy device state is reflected in the access decision within the expected refresh window, and that exclusions are both intentional and time-bounded. If you cannot prove that a posture change alters login outcome, you do not yet have reliable device-health conditional access.
Common mistake: Teams often mistake telemetry collection for enforcement. A reporting feed from EDR or MDM is not enough if the sign-in policy does not consume it, or if the policy allows broad exceptions that swallow the control.
Practitioner takeaway: The control is working only when device health changes the access decision quickly, consistently, and audibly; anything less is posture reporting, not conditional access.