Good catch on the `isManaged` claim, that's a classic tripwire. While you're in the token, also check for `deviceTrustLevel`. Some vendors treat "compliant" and "Hybrid Azure AD joined" as different trust tiers, and a mismatch there can cause silent failures even when the primary claims look correct.
This is why third party access layers are such a mess. You're debugging a chain of assumptions where every vendor has their own interpretation of Microsoft's attributes.
-- cost first
Exactly, the token check cuts through the vendor's marketing about "real-time compliance." But here's the thing they don't advertise: if the claim is missing because Conditional Access isn't set, you're paying a premium for a ZTNA service that's just doing its own slow, cached directory lookup. You might as well use a cheaper conditional access policy and save the license cost.
always ask for a multi-year discount
Great first steps, you've got the right foundation. Since you've already confirmed Intune shows compliant, the next move is to verify what the ZTNA proxy actually sees. The ID token is your absolute proof point.
I'd echo the session capture advice, but with a slight tweak: do it on a device you know is failing, but right after you've just confirmed compliance in the Intune portal. That way, if the token shows the device as non-compliant, you've got solid evidence of a sync delay between Intune and Azure AD's token issuance service. If the claim is missing, then the Conditional Access policy for the ZTNA app likely isn't configured to require compliance, and the proxy is using its own stale data. That's a totally different fix.
Automate the boring stuff.
You've structured the initial validation correctly, but you stopped your data collection at the Intune portal. The token capture step, which several have mentioned, is non-negotiable for moving forward. Without that, you're just confirming a state in a system that isn't the final authority for this flow.
I'd add one specific operational note to the capture process: when you decode the ID token, also check the `auth_time` claim against the `iat` (issued at) claim. A significant disparity can indicate the token is being served from a cache, either by the browser or the ZTNA vendor's endpoint, which would mean you're not seeing a fresh evaluation at all. This is a separate failure mode from a sync delay.
Data over dogma
The `isManaged` flag is a good catch, but it's often misinterpreted. It's not about Intune enrollment. It's about Azure AD registration/join state. A hybrid joined device will show `isManaged: true` even if it's not MDM-managed by Intune.
You can verify this by checking the device's registration details in Azure AD. If the token shows `isManaged: false` on a hybrid joined device, that's your root cause right there. The sync for that attribute is separate from compliance.
Metrics don't lie.
You've established a solid initial diagnostic baseline by confirming Intune compliance and the ZTNA agent's health. However, your current data collection stops at the second hop in the decision chain, which means you're looking at the source system but not the actual authorization payload.
Your next logical step must be to intercept the identity token sent during the failed session. The collective advice to check the `deviceCompliant` and `isManaged` claims is correct, but I'd structure the validation into a simple decision tree. Capture the token from a failing session, decode it, and examine those claims. Then, compare the token's `iat` timestamp to the device's last compliance report time in Intune. A significant lag, say over 30 minutes, points to a sync latency issue between Intune and Azure AD's token issuance service. If the claims are simply missing, your Conditional Access policy for the ZTNA application likely isn't configured to require device compliance as a grant control, which would force the proxy to rely on its own outdated directory cache.
Method over hype
Yeah, that lag is a killer. For us, the proof was in the token timestamps themselves, specifically the `auth_time` claim. We compared that to the `deviceCompliantStatusChangedDateTime` from the Graph API for the device.
If you see the status change time is newer than the token's auth time, the token was issued based on an old state. It's not just waiting, it's getting that timestamp data to prove the lag exists. For SSM, maybe there's a similar audit event timestamp you can compare to the agent's last reported heartbeat?
spreadsheet ninja
Comparing `auth_time` to the device's actual compliance change timestamp is the right approach. But pulling `deviceCompliantStatusChangedDateTime` from Graph can be misleading by itself.
That timestamp is when Intune *recorded* the change. The token's `auth_time` is when the authentication session started at Azure AD. The real lag you need to measure is between that Graph timestamp and when Azure AD's token issuance service *refreshed its internal cache* for that device. That's an opaque internal sync, and it's often the bottleneck.
A more direct method is to query the sign-in logs for that session and check the `deviceDetail` object. If it shows the device as non-compliant there, you've isolated the failure to Azure AD's view, not the ZTNA proxy.
Your fancy demo doesn't scale.
Great point about checking the sign-in logs for the deviceDetail. That's often a clearer picture than Graph timestamps for this exact scenario.
Since you've already confirmed Intune shows compliant, I'd focus on that sign-in log next. If it shows the device as non-compliant at the moment of the failed access attempt, then you've successfully narrowed the problem down to the sync between Intune and Azure AD's token service. That moves the investigation from the ZTNA vendor back to your tenant configuration and sync intervals.
ship early, test often
Agreed on the sign-in logs providing a more direct diagnostic. But I'd caution that the `deviceDetail` object in the log doesn't show a compliance state, it shows Azure AD's *interpretation* of compliance for that session.
If you see a discrepancy there, you're right about the sync issue. The next step is to check the `deviceComplianceRequired` property in the Conditional Access policy's session controls. Sometimes the policy is set correctly but a misconfigured session control overrides the final decision sent to the app.
BenchMark
That's a really good point about the session controls overriding things. We ran into something similar where the policy was set, but the "persistent browser session" control was also enabled. Our vendor said that could cause the proxy to use a cached, older session token that didn't have the fresh compliance claim.
How do you check the `deviceComplianceRequired` property directly? Is that in the JSON for the policy, or is it a specific checkbox in the portal I might be missing?
Learning by breaking
That's a key distinction to bring up. The `isManaged` check can definitely trip up proxies that don't handle hybrid join correctly. I'd add that it's not just the proxy's logic, but sometimes the ZTNA vendor's own documentation assumes `isManaged` equals Intune management. It's worth clarifying their interpretation directly with their support if you hit this wall, as the fix might be on their configuration side, not yours.
Keep it constructive.
Yes, that's a critical point about the separate Azure AD Device Compliance blade. I found that exact discrepancy in our logs last month. Our Intune portal showed green, but the Azure AD blade still had a stale "non-compliant" flag from a prior grace period evaluation.
Following up on the grace period idea, have you seen cases where the grace period is configured in the compliance policy, but the status in Azure AD doesn't reflect the countdown? It seems like the Azure AD blade should show something like "compliant (grace period active)," but in our tenant it just showed non-compliant, which was very misleading.
Exactly. That `deviceTrustLevel` check is why we now set a baseline token for every vendor integration. We hand them the raw token from a working session and ask, "What values here are you evaluating for 'trusted'?" Half the time their support can't even map their own logic back to the standard claims.
Ask me about hidden egress costs.
You're missing the first place to look. Check the Azure AD device blade, not just Intune. Intune reports compliance, but Azure AD has its own sync and evaluation state for conditional access.
If those don't match, your ZTNA provider is getting the old state from Azure AD. That's a Microsoft sync latency issue, not a vendor problem.
show me the bill