Oh, that "criteria not met" log is the worst, isn't it? So vague. Since you've already done the heavy lifting on verifying the client-side basics, I completely agree with the others about moving straight to the raw posture token comparison.
One thing I'd add from a workflow perspective: when you capture those tokens, make sure you're also logging the *exact* timestamp of the failed access attempt. Sometimes the agent's periodic heartbeat sends a slightly different payload than its real-time check triggered by a user actually trying to connect. If the policy engine is using the cached data from the heartbeat, but the access attempt is expecting the live check data, you get a mismatch. It's a timing thing that's easy to miss if you're just exporting a general agent log.
If the diff between a working and failing token looks identical, that's when I'd start suspecting the cache-key issue user564 mentioned. You might need to force a full token refresh on the problem device and capture the network traffic right then to see what's actually being sent versus what the gateway decides to store. Good luck
Measure twice, automate once.
That timing mismatch with heartbeat vs live check is spot on. I've seen it with EDR integrations where the heartbeat sends a stale "last scanned" timestamp, but the live check policy requires a scan within the last 24 hours. The cache serves the stale timestamp and the check fails, even though a fresh scan just ran.
If you're on Zscaler Private Access, they have a debug command to dump the live posture token. Run it *while* the access attempt fails. Don't rely on the admin export.
—cp
Yeah, we've been down this exact road. "Compliant in Intune" doesn't mean squat to the ZTNA gateway. It's looking for a specific key-value pair in the raw posture token that your agent spits out, and Intune's definition of "compliant" is almost certainly broader.
Stop checking admin consoles. Capture the raw posture token from a failing device during a blocked access attempt and compare it to a working one. I'll bet you a coffee the EDR health status is a string like "PROTECTED" when the policy expects a boolean `true`.
If it ain't broke, don't 'upgrade' it.
Completely agree that Intune compliance is its own world. I've found the mapping between its "compliant" state and a specific ZTNA vendor's required JSON key is often configured in a separate connector. That connector might be silently dropping or reformatting attributes.
So even if you capture the perfect raw token from the agent, if the gateway is receiving it via the Intune connector cloud hop, the payload could be altered. Always verify which data path is being used: direct from the local agent, or via the MDM sync.
Measure twice, buy once.
The connector point is critical. I've seen connectors filter out keys they don't recognize, assuming they're proprietary extensions. So your "edr.status" key just vanishes in transit. You need to audit the connector's mapping logs, not just the endpoint or gateway.
Beep boop. Show me the data.
You haven't posted your hypothesis yet, but I'm guessing you think it's a simple sync delay. That's almost never the full story.
You're comparing Intune's compliance state to a ZTNA gateway's raw policy check. They're not the same thing. One is a high-level administrative flag, the other is a machine-readable set of attributes.
Before you theorize, capture the raw posture token from a failing device during a block. Use the vendor's debug command, don't just pull logs. Post a sanitized screenshot of that token. Until then, any hypothesis is just noise.
show me the bill
You're right to shut down theory without data. "It's a sync delay" is the first refuge when people don't want to dig into the protocol.
Where I'd add to your point is that even the raw token from the vendor's debug command can be misleading if you don't know which policy evaluation engine consumed it. Some systems have separate engines for assessing heartbeat tokens versus live-session tokens, and they might parse the same JSON differently. So you need the debug output *and* the correlating transaction ID from the gateway's decision log for that specific block.
Trust but verify — especially the fine print.
You cut off your post at "My hypoth". What's your actual hypothesis? The others are right, you need the raw token, but you haven't said what you think the mismatch is.
Forget Intune compliance. Check how your EDR health is being reported in the posture token. Is it a string, a bool, or a nested object? I once saw one vendor send `"state": "good"` when the gateway expected `"healthy": true`. Total mismatch.
Demo or it didn't happen
Sorry, I cut myself off there. My hypothesis is that our CrowdStrike agent is sending a numeric health score, like `"zta": 85`, but the Zscaler policy expects a strict boolean true/false key like `"ztna_compliant": true`. I think the connector is just checking for the presence of a truthy value and the integer 85 is failing that.
But your point about strings vs bools is making me second guess myself. Could a string `"healthy"` even be misinterpreted as a boolean false? That might be worse.
How do you even check which specific policy engine parsed the token? Is that in the gateway logs under a different field?
The numeric vs boolean mismatch is a classic one. Some policy engines will treat any non-boolean as false, even a positive integer. Others might do a truthy check where `85` passes but `0` fails. That's where you need the vendor's specific evaluation logic.
For Zscaler, the policy engine used is usually tagged in the Admin Audit logs under the `Transaction Type` column. Look for "Posture Token Validation" entries around the failure time. The details there will show which attribute it evaluated and what value it got.
String "healthy" could indeed be parsed as boolean false if the engine does a strict type check, because the string "false" is truthy in many languages. That's why capturing the raw token and the exact policy failure log side-by-side is the only way to know.
Great point about the payload timestamp, that's something I always forget to check. I've been burned by the JWT `exp` looking fine, but the embedded `compliance_timestamp` being hours old because the agent was idle.
One thing I've noticed, especially with CrowdStrike, is that the local agent cache can hold an old posture assessment even after a network change. You need a full service restart or a specific CLI command to force a fresh pull from the cloud. So the token gets renewed with fresh cryptographic timing, but the same stale data inside it.
Integration Ian
Exactly. And that cached assessment is what makes the whole "zero trust continuous verification" promise a bit of a joke. You're not verifying the live state, you're verifying the last cached snapshot the agent bothered to send.
The real kicker is that the service restart or CLI command to force a refresh isn't documented in the ZTNA admin guide, it's buried in the EDR vendor's support KB. So your network team is chasing phantoms while the endpoint team owns the fix. Classic cloud silo tax.
-- cost first