Our organization has been conducting a detailed operational cost and performance analysis of our Zero Trust implementation, with a specific focus on the endpoint resource consumption of Zscaler Private Access. A recurring and quantifiable issue has emerged from our field engineering teams: the 'always-on' connectivity feature is causing significant and unsustainable battery drain on managed laptops, primarily Dell Latitude and MacBook Pro models. This is directly impacting productivity and hardware lifecycle costs, as batteries are being cycled more aggressively.
We have isolated the variable to the ZPA client's persistent tunnel maintenance. Our hypothesis is that the continuous cryptographic handshakes, heartbeat mechanisms, and network path persistence—even during idle periods—are preventing modern OS power management states from engaging effectively. The drain is most pronounced when users are on cellular hotspots or unstable Wi-Fi, where the client appears to increase retry frequency.
Our initial data collection from a sample group of 50 machines over a 30-day period shows the following average impact:
* **Battery Life Reduction:** 35-40% decrease in usable hours per charge compared to periods with ZPA disabled or in on-demand mode.
* **CPU Wake Lock Frequency:** The `ZscalerService` process prevented sleep states approximately 22 times per hour during 'always-on' operation.
* **Network Energy Impact:** Constant low-bandwidth TLS traffic maintained network interfaces in a higher power state.
We have explored the documented ZPA client configuration settings but have found the granular controls for power management to be lacking. The binary choice between 'always-on' and completely manual connection is not optimal for a mobile workforce that needs both security and battery longevity.
**Primary Question:** Has any organization successfully implemented a technical or policy-based mitigation for this issue without compromising the zero-trust security posture? We are particularly interested in:
* Registry or configuration file modifications to tune heartbeat intervals or aggressive timeout behaviors.
* Scripted approaches to dynamically enable/disable the 'always-on' feature based on power source (battery vs. AC).
* Any third-party tools or GPO/Intune policies that can manage the ZPA client's network power footprint.
**Secondary Consideration:** If such mitigations are not possible, we are evaluating the cost-benefit of alternative architectures, such as a always-on VPN at the network layer (which may allow for hardware offloading) versus ZPA at the application layer. Any comparative data on resource consumption would be invaluable.
Our next step is to instrument a controlled test with detailed power telemetry, but we hoped the community might have already navigated this challenge and could provide actionable configuration insights.
every dollar counts
That's a really well-documented observation, and something I've seen echoed in other enterprise communities. Your point about unstable Wi-Fi or cellular links increasing the retry frequency is spot on, it seems to exacerbate the issue considerably. It's not just the cryptographic handshake overhead, but the constant network interface activity keeping everything awake.
Have you been able to test a temporary workaround like setting the ZPA client to "on-demand" mode during travel, or is that a non-starter from your security team's policy perspective? I'm curious if the battery hit is deemed an acceptable trade-off for the security posture.
Raise the signal, lower the noise.
On-demand mode is a policy bypass, not a workaround. It defeats the zero-trust principle.
The trade-off is a false choice. A security client shouldn't cripple the hardware. This is a vendor implementation problem. Zscaler needs to fix their idle-state resource management, period. Other clients manage persistent tunnels without this level of drain.
show me the logs
I largely agree that framing this as an "acceptable trade-off" is a flawed premise. It absolves the vendor of responsibility for inefficient code.
However, calling on-demand mode a "policy bypass" is technically correct but ignores the operational reality. Some organizations are forced to use it as a stopgap precisely because the vendor hasn't fixed the core issue. The failure isn't the admin who flips the switch to restore productivity, it's the engineering team that hasn't optimized idle resource consumption.
We've measured similar clients (like Palo Alto's GlobalProtect with always-on) and the differential is stark. The data shows this is a solvable problem.
Measure twice, spend once
Exactly right on it being a vendor problem. The false choice narrative is pure vendor deflection. They'll sell you the zero-trust dream and then blame your hardware when their client acts like a poorly written crypto miner.
I've seen the same thing in audits. Other tunnel clients go truly quiescent. ZPA's architecture seems to treat any idle time as a prelude to a reconnect, so it just churns. Calling that a necessary security cost is dishonest engineering.
— geo