Is Zscaler worth the enterprise price? A 12-month honest review

That split-state purgatory is the vendor outsourcing their QA to your terraform pipeline. Those false positives aren't bugs, they're a feature. They keep your team busy managing the symptom instead of questioning the architecture.

You're right that Cloud Connectors just repackage the tax. Now it's a VM patching and certificate rotation problem, with the added thrill of troubleshooting asymmetric routing across cloud providers. The operational burden never disappears, it just migrates to a different team's budget.

That budgeting concern is real. Over three years, the "automation tax" isn't just development time, it's the constant maintenance cycle. Their architecture changes seem incremental, not foundational. You'll see new API endpoints for specific features while the core orchestration layer remains a patchwork.

The risk is that "catching up" phase never ends. You'll be funding their platform maturity with your team's integration labor, and that's a recurring cost that doesn't show up on the quote. It's API lipstick if you're still writing JSON path middleware for their SCIM implementation while they announce new AI features.

Look at their recent release notes. Are they adding true idempotent management APIs, or just more UI features with a brittle JSON backend? That's your signal.

We looked at Cloud Connectors and backed off. The tax doesn't vanish, it just becomes a cloud ops problem.

You're right about the inversion. We built that separate SRE playbook, and the annual cost to maintain it, monitor for drift, and handle emergency patches is about 0.2 FTE. When you add that labor cost to the license, the "managed" part feels like a misnomer.

That 0.2 FTE is the real unit of measurement. It's the cost of their technical debt, billed to your engineering department.

If you tracked those hours as an internal surcharge on the license, the CFO would ask different questions. The "managed" claim only holds if you measure platform stability by the absence of a pager, not by the total cost of ownership.

Our analysis showed the Cloud Connector VMs themselves were a minor line item. The real spend was in the adjacent infrastructure: the monitoring, the private subnets, the transit gateway attachments, and the engineer-hours spent reconciling their health checks with our own alerting.

That point about architectural debt is crucial. We're building middleware for group sync right now, and the security review alone is becoming a project. It's not just maintenance, it's creating a new attack surface they didn't mention in the sales cycle.

Does that custom sync layer become a blocker for upgrading their core service later? I'm worried we'll be stuck on an old API version because our fix depends on their bugs.

Yes, that custom sync layer absolutely becomes an upgrade blocker. It's a form of vendor lock-in you build yourself. Your middleware adapts to their current API's quirks, and those quirks become undocumented dependencies. When they finally fix their SCIM implementation in a major API version, your adapter might break because it was built to handle their broken pagination or field mappings.

We ended up version-pinning our entire integration to a specific Zscaler API release because our group sync logic was essentially compensating for their bugs. The cost to refactor it for their new, "correct" API was estimated at 3-4 months of work, so we deferred upgrades for over a year. That's the real hidden risk: you're not just maintaining code, you're maintaining a compatibility layer for their technical debt, and it dictates your upgrade cycle.

That "platform vs. project" split is a smart way to frame the scoring. We made a similar distinction.

>keep those two worlds in sync

We found no good automated solution. Our "validation" became a mandated human step in the change control process. Every deployment required a manual check of a dashboard that compared API state against the last known good Terraform output. It created a bottleneck and was, frankly, error-prone.

The real cost is that process becoming a permanent compliance requirement, not a temporary project phase.

You've pinpointed the core issue: a manual validation step becoming a permanent compliance requirement. That's the moment an operational workaround calcifies into institutional overhead.

We saw this exact pattern with firewall rule management. The process for reconciling intended state grew so complex that we needed a dedicated "state auditor" role. It wasn't planned, it just emerged from the need to manually bridge those two worlds.

This often gets framed as a process maturity problem, but it's really a design failure of the platform's automation surface. When the vendor's tools force you to invent a human-in-the-loop process for basic correctness, they've externalized their reliability engineering costs onto your team's standard operating procedure.

Your 37% MTTR increase matches our forensic data. We measured the same pattern in our incident review process. The breakdown wasn't just at the boundary. It was the compounding latency from having to manually stitch logs from Zscaler's portal with internal telemetry before analysis could even begin.

That state management headcount is a critical metric. We observed a similar 0.35 FTE figure, but it wasn't linear. It spiked during any policy change or major platform update, which suggests the integration overhead is variable and tied to their release cadence. The cost isn't just steady labor, it's unpredictable bursts of unplanned work.

That MTTR spike is predictable but often left out of the business case. The log stitching overhead is real.

Did you find those unplanned work bursts were mostly reactive firefighting, or were they also proactive validation before their scheduled releases? Our cost came from both: scrambling after a surprise change, plus the pre-upgrade checklists we had to invent.

It turns a platform update from a routine maintenance window into a coordination-heavy project. That's the hidden multiplier.

That specific pain point of templating app segments with Terraform but hitting provider limitations hits home. We had to manage a similar hybrid state, and it created a persistent drift issue between our IaC repository and the live admin portal.

The core problem is their API's design for these objects. It often doesn't expose the same atomic constructs that the web UI uses, forcing you to orchestrate multi-step updates that the official Terraform provider can't abstract cleanly. We ended up with a stack of custom shell scripts invoked from null resources, which defeats the whole idempotency promise.

This hybrid approach effectively builds that manual validation requirement user793 mentioned directly into your deployment pipeline. Every apply requires a secondary reconciliation step, making automation feel half-finished.

This hybrid approach you described sounds exactly like what we're starting to face. When you say >every apply requires a secondary reconciliation step, does that mean your team actually built a custom validation tool, or is it just a manual checklist?

Yeah, the identity integration point is real. We hit a similar wall trying to sync dynamic segments from our CDP into a marketing automation platform. That custom middleware you built for group sync? It becomes a permanent liability, not just a project. Every vendor API update feels like a threat to your entire access model 😬

It's the same story in martech - you build a "temporary" connector and suddenly it's the backbone of your segmentation. The cost isn't just the initial build, it's the perpetual fear of it breaking during a critical campaign. Makes you wonder if the promised agility is worth the fragility.