We've been piloting Zscaler Private Access (ZPA) for a zero-trust application replacement for our traditional VPN. The core connectivity and access model is sound, but we are encountering persistent and severe conflicts between the ZPA App Connector/Client and multiple Endpoint Detection and Response (EDR) and Anti-Virus (AV) agents on our Windows 10/11 endpoints.
The symptoms are not subtle. We observe:
* **System instability:** Frequent BSODs (mostly `DRIVER_IRQL_NOT_LESS_OR_EQUAL` and `SYSTEM_SERVICE_EXCEPTION`) with crash dumps implicating `zpawsp.sys` (ZPA WFP driver) and EDR kernel drivers.
* **Performance degradation:** Extreme CPU spikes (sustained 90%+ on a core) by `Zscaler Service` or the EDR service when both are active, often tied to network-heavy operations.
* **Network disruption:** The ZPA client will sometimes successfully establish a connection, but then all traffic (even to non-private apps) is dropped or severely throttled. Disabling the EDR's network inspection component immediately resolves this.
* **Mutual blindness:** In several cases, the EDR console shows the endpoint as "healthy but offline" while ZPA is connected, suggesting the EDR's heartbeat is being blocked.
Our testing matrix has included ZPA with CrowdStrike Falcon, Microsoft Defender for Endpoint (in active mode), and Carbon Black. Each combination produces a variant of the issues above, though the specific drivers and crash signatures differ.
From a technical standpoint, this appears to be a classic kernel-level driver conflict. Both ZPA and modern EDRs install Windows Filtering Platform (WFP) callout drivers and network inspection drivers (at the minifilter or NDIS filter level) to intercept and evaluate traffic. When two such drivers attempt to inspect, modify, or drop the same packets in a non-cooperative sequence, the result is undefined behavior—crashes, loops, or packet loss.
We've attempted standard exclusions (process, path, network) in both directions, as per various support articles, with limited success. For example, adding ZPA processes to the EDR's exclusion list prevents file scanning but does nothing to mitigate the network filter conflict.
Has anyone else conducted a deep dive on this specific issue? I'm particularly interested in:
* Documented, stable exclusion methodologies that go beyond file/process scanning.
* Any official guidance from Zscaler or major EDR vendors on load order or mutual certification.
* Whether deploying ZPA in Service Tunnel (always-on) mode versus App Tunnel mode changes the conflict profile.
* If the conflict extends to the ZPA App Connector (server-side) when EDR is installed on those instances.
Our security team is rightfully hesitant to whitelist or neuter EDR functions, and our operations team cannot tolerate the instability. I will share any diagnostic findings from our side, including relevant `driverquery` outputs and WFP filter layer dumps, if there is community interest.
CPU cycles matter
That sounds like a nightmare to debug. The crash dumps pointing at zpawsp.sys and EDR drivers together is a classic filter driver conflict. What EDR/AV products are you seeing this with most? We're just starting to look at ZPA and I'm curious if it's isolated to certain vendors.
I've read that some people had luck by adding the ZPA service and the zpa folder to the AV exclusion list, plus disabling the EDR's network inspection for the ZPA client process. But that kind of defeats the purpose of having EDR watch network traffic. Have you tried any of the suggested exclusions from Zscaler's docs? And does the problem get worse with real-time scanning on or off?