I've been investigating a persistent and seemingly illogical ZTNA policy enforcement failure within our hybrid environment for the past week, and I'm hoping the community can assist in validating my diagnostic approach or suggest alternative causal pathways. The issue manifests as follows: a subset of corporate-managed devices (Windows 11, enrolled via Intune, with the requisite ZTNA agent installed and running) consistently trigger a "device not compliant" gate in our ZTNA policy, despite all available telemetry indicating full compliance with our defined conditional access policies (e.g., OS version, disk encryption, security agent health).
Our ZTNA architecture follows a service-initiated model, integrating our identity provider (Azure AD) with a leading ZTNA vendor's cloud proxy. The compliance decision is intended to flow: Device -> Intune (reports compliance state) -> Azure AD (Conditional Access evaluates) -> ZTNA Provider (enforces session establishment).
**My diagnostic steps and findings thus far:**
* Verified the device's compliance status in Microsoft Intune admin center is reported as "Compliant." The last reported timestamp is recent (within 1 hour).
* Confirmed Azure AD Conditional Access policy for "Require compliant device" is assigned to the relevant user group and targets the ZTNA cloud application.
* Examined the Azure AD Sign-in logs for a failed session initiation. The log shows:
* Status: **Success**
* Conditional Access: **Not applied** (This is the anomaly)
* The "Device Info" tab correctly lists the device as Managed (Microsoft Entra ID joined) and Compliant.
* The ZTNA provider's own connection logs show the session was denied with reason: `policy_requirement_failed: device_compliance`.
This creates a logical contradiction: the sign-in succeeded (authentication passed), but Conditional Access reports it was not applied, yet the downstream ZTNA provider claims a device compliance policy failed. This suggests either a latency/state synchronization problem between Azure AD and the ZTNA service, or a scenario where the ZTNA provider is evaluating a separate, cached device posture signal not aligned with Azure AD's.
**Current Hypothesis & Configuration Check:**
I suspect the ZTNA provider may be configured to perform a secondary, direct device posture check (e.g., via a local agent health signal sent directly to the ZTNA cloud) that is out of sync with the Intune/AAD compliance engine. The vendor's documentation on "hybrid compliance evaluation" is notably vague.
Has anyone encountered a similar split-state scenario in integrated ZTNA deployments? Specifically:
* Are there known latency tolerances for Azure AD compliance state propagation to third-party ZTNA services?
* What are the definitive log sources to isolate whether the failure originates from the identity layer (AAD Conditional Access token claim) versus the network enforcement layer (ZTNA provider's own policy engine)?
I will follow up with any relevant sanitized log excerpts or policy configuration blocks if needed for further analysis.
- Dr. C
Nullius in verba