We recently concluded a six-month phased rollout of Netskope ZTNA with a primary focus on device posture assessment for remote access. The hypothesis was simple: leveraging the existing endpoint management agent (in our case, Microsoft Intune) for posture, we could enforce a higher security bar than VPN alone provided. The results, however, quantified a significant hidden risk in our ostensibly compliant fleet.
Our policy was configured to check for the following mandatory criteria before granting access to internal web applications:
* Managed device: Corporate identity must be present.
* Disk encryption: BitLocker (Windows) or FileVault (Mac) must be active.
* Endpoint protection: Microsoft Defender for Endpoint must be installed, running, and signature age < 48 hours.
* OS version: Windows 10 22H2 or later, macOS 12 or later.
The posture check was set to `require` for all ZTNA-protected applications. During the observation period, we sampled 4,327 unique device connections. The aggregate failure rate was 12.1%. A breakdown of primary failure vectors is below:
```json
{
"total_connections_sampled": 4327,
"failed_posture_assessment": 524,
"failure_rate": "12.1%",
"failure_breakdown": {
"outdated_av_signatures": 287,
"disk_encryption_inactive": 156,
"os_version_non_compliant": 67,
"agent_not_installed": 14
}
}
```
The most prevalent issue, outdated AV signatures (54.8% of failures), was particularly insightful. It revealed a latency gap between our Endpoint Manager reporting "healthy" and the real-time check performed by Netskope at the moment of access. A device could be marked compliant in Intune but have signatures stale enough to fail the stricter ZTNA policy at connection time.
The operational impact was measurable. We instrumented our internal help desk ticketing system and correlated tickets tagged "ZTNA access denied" with the failure categories. The mean time to resolve (MTTR) for a posture-related block was 47 minutes, primarily due to user education and remediation steps (initiating a manual AV update, rebooting to enable encryption). This is a tangible productivity tax for enforcing the policy.
This exercise underscores the critical difference between assumed compliance and verified, real-time compliance. While a 12% failure rate seems high, it likely represents the delta between periodic management checks and instant, context-aware access decisions. For teams considering a similar rollout, I recommend:
* Implementing a monitoring dashboard for posture failure rates, segmented by failure reason.
* Establishing a phased enforcement policy, starting with `report-only` mode to baseline your fleet.
* Calculating the MTTR for remediation to understand the true support cost of your chosen posture requirements.
The data clearly shows that a non-trivial portion of "managed" devices would have been granted VPN access without these checks. The ZTNA posture function acts as a final, real-time gate.
numbers don't lie
numbers don't lie
That 12% failure rate doesn't surprise me. We saw similar gaps when we moved from just trusting Intune compliance reports to actual gateway checks. The reports said 98% compliant, the real-time posture said 85%. The delta is always in the transient state - a device that's online but hasn't reported its compliance state in hours, or a BitLocker suspension after a Windows update.
Your mandatory criteria list is solid, but you're missing one critical check: screen lock. We found a chunk of our "compliant" fleet had no password or PIN set because the user bypassed it during setup. A fully encrypted, managed, patched laptop is still a risk if it's sitting unlocked in a coffee shop.
The real fight is getting the help desk prepped for the influx of "my access is blocked" calls. You need clear, immediate remediation steps they can walk users through without just making a policy exception.
been there, migrated that
Your failure vectors breakdown is what every security team needs to see. That 12% isn't an anomaly, it's the real compliance floor when you shift from batch reporting to real-time enforcement.
The biggest operational shock isn't the screen lock or encryption gaps, though. It's the endpoint protection signature age. We had the same policy and found it was the single biggest blocker during our rollout. Devices would go offline for a few days, come back online, and fail the 48-hour check because Defender was still catching up. It forced us to re-evaluate our update source configurations.
Your numbers validate the move. A VPN just checks for a tunnel. This tells you if the machine on the other end is actually trustworthy.
been there, migrated that
Ah, the signature age trap. That one's a classic. You're absolutely right that it becomes the most visible failure point, but I think calling it an "operational shock" lets the process off the hook a bit. It's a self-inflicted wound.
We configured ours to allow a 7-day grace period specifically to avoid the "offline for a weekend" failure scenario. A 48-hour window is aspirational, but it assumes a permanently connected, perfectly functioning corporate device. The real world is laptops in sleep mode in backpacks, working from a cabin with spotty satellite internet, or an employee on leave. Enforcing too tight a window just trains users to see security as the thing that randomly breaks their workflow, which breeds workarounds.
The harder question, which your re-evaluation of update sources touches on, is whether you're measuring the right thing. Is a 5-day-old signature on an offline laptop truly a higher risk than a device with a screen lock timeout set to 'never'? We ended up deprioritizing signature age in favor of a hardened configuration check.
Test the migration.
You're right, this is the core tension. I'm new to this kind of implementation, but from a user experience standpoint, your point about training users to see security as the thing that breaks workflow is spot on. It erodes trust fast.
How did your team weigh the risk of an outdated signature versus something like the screen lock? Did you find pushback from the security side for loosening the signature age policy?
Learning every day
Exactly. The gap between what a management console reports and what a gateway enforces is the whole point. Anyone still arguing for agent-based compliance reports alone isn't paying attention.
But your screen lock example is the perfect illustration of a policy gap that reporting tools just miss. Intune can report a compliant device because it's managed, but it can't detect if the user dismissed the PIN prompt once. Real-time posture actually validates the security state, not just the administrative state.
The help desk prep is key. If they're just granting temporary exceptions to clear the queue, you've built a fancy, expensive workflow that accomplishes nothing.
Trust but verify.