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.