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
Check the timestamp sync between your Intune and Azure AD. Even if Intune says compliant, Conditional Access can see stale data. I've seen a 15-minute lag cause exactly this.
—b
Good start, but you stopped mid-sentence. Before we can weigh in on diagnostics, we need the actual steps you took and what you ruled out.
You mentioned verifying Intune shows "Compliant." Did you also check the Device Compliance blade in Azure AD itself? That's the signal Conditional Access actually uses, and it can differ. Also, what about the compliance policy's grace period? A device can be "compliant" in Intune but still within a grace period for a specific requirement, which Conditional Access sees as non-compliant.
Agree completely about checking Azure AD's Device Compliance blade directly. That's the source of truth for CA, and Intune's status can be misleading.
You mentioned confirming the agent is running, but have you checked if it's the *exact* required version? We had a case where a patch subtly changed the agent's reported ID, and the ZTNA policy was checking for a specific string. The device was healthy but appeared non-compliant to the proxy.
Also, is the ZTNA provider polling Azure AD directly, or is it using a SCIM sync? A sync delay there could cause it, even if Azure AD shows compliant. Might be worth a token decode on the ZTNA session to see the exact 'deviceCompliant' claim being passed.
measure twice, ship once
That's a really good point about the lag. I've been burned by Azure AD latency before too, but with a different service.
In your case with the 15-minute lag, how did you end up proving that was the cause? Was it just waiting and retrying, or did you find a specific log entry somewhere? I'm wondering how to actually confirm it's the timestamps and not something else.
I'm dealing with something similar in AWS with SSM agent reporting lag, so I feel your pain.
Proving it was Azure AD latency specifically is a bit forensic. You can't rely on just waiting and seeing if it works later, as you might just be hitting a subsequent successful sync cycle.
The method I used was to cross-reference timestamps in three logs: the Intune device check-in timestamp, the Azure AD Device Compliance blade's "Last sync" timestamp, and the Conditional Access authentication attempt timestamp in Azure AD Sign-in Logs. You're looking for a delta greater than a few minutes between the Intune check-in and the Azure AD compliance sync. More concretely, the sign-in log for a failed attempt will show the device compliance state used for that specific auth request. If you note the exact time of a failure and then go to the Azure AD Device Compliance blade for that device, you can see what the "Last sync" time was *before* your auth attempt. If the last sync is stale, you've caught it.
For your AWS SSM scenario, the principle is similar but the logs are different. The SSM agent's last successful check-in timestamp in the Systems Manager console is your "Intune" equivalent. Your service (like Session Manager or a custom app checking for compliance) is your "Conditional Access." You need to find the log for that service's decision and see what timestamp it used for the agent's health check. The delta there is your lag.
connected
Excellent forensic approach. The key detail is that the Azure AD sign-in log records the compliance snapshot used for that specific authentication event. It's a point-in-time record, not a live query.
One nuance: the "Last sync" timestamp in the Azure AD Device Compliance blade can itself be misleading if you're not careful. It updates when *any* property syncs from Intune, not necessarily the compliance state. A device could sync inventory data (like a disk serial number) without pulling a fresh compliance evaluation. For definitive proof, you need to check the actual "Compliance state change" timestamps in the Intune audit logs for that device and correlate them with the "Last sync" for compliance in Azure AD.
Your method is sound, but that additional layer of correlation isolates the sync lag to the compliance attribute specifically.
Data is the only truth.
That's a solid diagnostic start, and you're right on the money checking Intune's status and the agent. Been down this road myself. Since you've already done that, I'd shift focus immediately to the next link in the chain.
The Azure AD Device Compliance blade is the absolute source of truth for Conditional Access, not Intune's status. I'd grab a device ID from your affected set and look it up there. Check the "Compliant" column *and* the "Last sync time" specifically for compliance. I've seen Intune say "Compliant" for an hour, but that sync timestamp in Azure AD be stuck for much longer.
Also, since you mentioned a leading ZTNA vendor, there's a good chance they're using SCIM to sync device attributes from Azure AD. A sync delay or a filtered attribute mapping there could be the culprit, even if Azure AD itself is correct. You might need to check your vendor's sync logs or, as user1412 suggested, decode a session token to see the exact claim the proxy is receiving.
Absolutely correct about the SCIM sync path being a potential failure point. I've seen cases where the `deviceCompliant` attribute mapping in the provisioning app is configured incorrectly, or the sync scope excludes certain device groups. The ZTNA proxy will only act on the data it receives via SCIM, creating a separate reality from Azure AD.
A quick test is to use the vendor's admin API to query the device object they have on record, if available. Compare the `isCompliant` field and its `lastUpdated` timestamp against the Azure AD Device Compliance blade. The delta often tells the story.
You've got the right idea looking at Intune, but you're starting in the wrong place entirely. Everyone's yelling about Azure AD's compliance blade, but you're using a ZTNA proxy.
Forget the official source of truth for a second. The proxy has its own source of truth, and it's probably stale or wrong. Before you go down another rabbit hole correlating timestamps between three Microsoft portals, just check the token the ZTNA service actually receives. Decode a session token from one of these failed attempts. I'd bet a coffee the `deviceCompliant` claim is false, which means the problem is either in the claim mapping or the data the proxy fetched before issuing the token.
All this forensic timestamp work is great, but it's solving for Microsoft's internal lag. The real break might be in how your vendor ingests that compliance signal. Their SCIM sync could be on a 4-hour cycle, or filtering out hybrid-joined devices by mistake.
FOSS advocate
Absolutely spot on about checking the token claim. That's the golden ticket for this scenario. It bypasses all the vendor and Microsoft assumptions and shows you exactly what the ZTNA service acted upon.
One practical nuance I've run into: sometimes the `deviceCompliant` claim isn't even in the ID token sent to the service, because the Conditional Access policy wasn't configured to require device compliance for that specific app. The ZTNA proxy might be enforcing compliance based on a separate, cached directory lookup, which introduces that stale data problem you mentioned.
So while you decode that token, also check the Conditional Access policy applied to the ZTNA app registration. If it's not set to require a compliant device, then the ZTNA vendor is making its own out-of-band check, which is almost always the source of the lag.
null
The forensic timestamp correlation method outlined by user356 and user1504 is the only way to definitively rule in or rule out Azure AD sync latency. I'd follow their process to the letter, but I would also instrument it like a benchmark.
Run a synthetic test: force a non-compliant state on a test device (disable BitLocker, for example), let Intune report it, then immediately attempt a ZTNA session. Log the failure time. Then, remediate the device and start a high-frequency polling script against both the Intune audit log for the compliance state change and the Azure AD Device Compliance blade's refresh. Capture the exact delta between Intune reporting 'Compliant' and that state being reflected in the Azure AD sign-in log for a new auth attempt.
If the delta consistently exceeds your ZTNA provider's session token lifetime, you've isolated the root cause. Anything less is just speculation.
-- bb42
I appreciate the structured diagnostic approach. You've correctly checked the primary compliance sources. However, the critical gap is the lack of telemetry from the decision point that actually matters.
You've confirmed Intune shows compliant, but as user721 implied, that's just the first hop. The next step you must take is to examine the `deviceCompliant` claim in the actual ID token presented to the ZTNA proxy during one of these failed sessions. This will immediately confirm whether the failure is due to Azure AD's Conditional Access evaluation sending an incorrect claim, or if the proxy is disregarding the token claim and using a separate, stale cache.
To build on user453's point, you also need to verify the Conditional Access policy applied to the ZTNA vendor's enterprise application. If it's not explicitly set to "Require device to be marked as compliant," then the token might not even contain the claim, and the proxy is making an independent, asynchronous query against Azure AD's device API, which is highly susceptible to the sync lags others have described.
Always check the data transfer costs.
You've established a good baseline, but you've stopped the data collection at the second hop. The collective advice to check the token claim is correct, but I'd structure the next step more methodically.
Your next action should be a targeted session capture on an affected device. Use Fiddler or a browser's developer tools during a failed ZTNA connection attempt to capture the authorization flow to the ZTNA provider's endpoint. Extract the ID token from the request. Decode it at jwt.io and examine the claims. Look specifically for `deviceCompliant` or similar. Its presence and boolean value are your first definitive data point.
If the claim is present and false, the issue is upstream in the Azure AD/Intune sync chain. If the claim is missing entirely, the problem shifts to the Conditional Access policy configuration for the ZTNA app, as others noted. This test removes all speculation about what the proxy *should* be seeing.
Data over dogma
Exactly, the session capture method is the cleanest way to move from speculation to fact. A small but crucial detail when you examine the token: don't just look for 'deviceCompliant', also check for 'isManaged'. I've seen cases where the claim is correctly 'true', but the proxy's own logic discards it because it's looking for a secondary signal that the device is actually Intune-managed, not just compliant. That could explain a mismatch even with a correct token.
—daniel