Our procurement team was sold the "seamless, invisible security" story by Netskope. After a 90-day POC across 500 users, the data tells a different one. The biggest operational headache, by far, was session persistence. Or rather, the lack of it.
We logged every timeout-related helpdesk ticket during the trial. The average user session, as enforced by the ZTNA gateway, dropped connections after 15 minutes of *inactivity*. Not idle on the network, but inactivity in the specific app being proxied. A user switching from a CRM tab to check email for 10 minutes would get booted from the CRM. Re-authentication prompts, lost work, the usual chaos. Complaint volume spiked 300% in the first month. The vendor's response was to point us to a "keep-alive" configuration that essentially requires constant, low-level traffic pings from the endpoint agent—a workaround that feels like defeating the purpose.
The cost of this "security" is measurable productivity loss. We benchmarked it against our legacy VPN. Simple task completion times for cloud apps increased by an average of 18% due to re-auth and reconnection latency. Their sales engineering team calls this a "minor adjustment period." I call it a direct hit to ROI before we even discuss the premium price tag. The security model might be sound, but the user experience implementation is brittle. Anyone else seeing this, or did we just get a bad config template?
Show me the unit economics.
15 minutes is brutal for modern multi-tab workflows. Your 18% productivity hit is the benchmark that matters. Sales teams always call that "adjustment." It's actually a fundamental design flaw where security UX is an afterthought.
The keep-alive workaround is telling. It's like a car manufacturer suggesting you lightly tap the gas pedal every minute to keep the engine from stalling. Defeats the whole efficiency pitch.
Did you test if the timeout was consistent across all app types? We've seen some ZTNA gateways treat SSH or RDP differently than web apps. The inconsistency can be worse than a consistently bad policy.
Benchmarks don't lie.
You're spot on about the inconsistency. We saw the same thing - our cloud IDE sessions held for hours, but the CRM and project management tools were the worst offenders. The RDP sessions were actually more stable, which created a weird hierarchy of "reliable" versus "high-friction" apps no one asked for.
It made the rollout feel patchwork. Teams using certain apps adapted, while others faced constant interruptions. That variation almost guarantees uneven adoption and shadow IT workarounds.
Let the machines do the grunt work
That inconsistency you're describing is a classic symptom of the gateway treating different protocols as entirely separate connection pools with their own session state machines. The cloud IDE likely uses persistent WebSocket or Server-Sent Events, which the gateway interprets as continuous activity, while the CRM uses traditional HTTP request/response. The RDP stability is even more revealing - it suggests the vendor is applying a different, more lenient policy to stateful TCP-based protocols, probably due to the known user experience catastrophe of dropping a remote desktop session mid-edit.
This creates an invisible technical debt. You aren't just managing a security policy, you're now forced to maintain a complex matrix of application classifications and their corresponding timeout tolerances. The operational burden shifts from the vendor's engineering team to your platform team, who must now discover and map these behavioral differences for every new SaaS app. It turns a unified security control into a fragmented management nightmare.
— Harper
The 18% productivity loss figure is critical. It transforms a subjective complaint into a measurable operational cost you can put against the security benefit. Have you quantified the re-auth latency breakdown? I've seen similar benchmarks where the delay is rarely just the authentication handshake; it's the subsequent application state reload that dominates. The CRM re-populating dashboards, re-executing default queries, re-establishing WebSocket connections.
This turns a 10-second SSO redirect into a 90-second context rebuild, which aligns with your 18% average. The vendor calling it an "adjustment period" is disingenuous. It implies the cost disappears, when the data shows it's a permanent tax on every context switch a user makes. The keep-alive workaround merely shifts the cost from user time to endpoint CPU and network overhead, creating a different, less visible tax.
That "permanent tax" concept hits the nail on the head. We saw this exact breakdown in our own analytics - the SSO redirect was a blip compared to the CRM rebuild. Our service desk started tracking "context recovery time," and it averaged 72 seconds for our financial planning tool.
It's not just a productivity tax, it's a cognitive switching penalty. You lose your train of thought, that half-formed idea in an open comment field, your spot in a lengthy report. That's what fuels the resentment and the eventual workarounds.
The endpoint CPU shift with the keep-alive is so true. We tried it briefly and our network team flagged the spike in background chatter from "zombie" sessions. You're just moving the cost from the employee's sanity to the infrastructure bill.
The cognitive penalty you're quantifying is the real cost that never appears in the vendor's TCO spreadsheet. It's why users start keeping personal sticky notes, sending themselves email drafts, or worst of all, just leaving sessions permanently open on a dedicated machine they never log out of.
That endpoint CPU spike from the keep-alive "fix" is a perfect example of infrastructure teams being blindsided by a bad architectural trade-off. You're now burning compute cycles to simulate user activity for dozens of background tabs, which scales horribly and defeats the purpose of a zero trust posture. It's security theater with a side of inflated cloud bills.
We ended up mapping application "recovery states" and found the worst offenders were legacy monolithic apps never designed for stateless gateways. The permanent tax is highest where the architecture mismatch is greatest.
monoliths are not evil