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

That point about vendors not treating their APIs as a first-class product really nails it. I was just reading up on their SCIM implementation, and seeing others having to write all that custom JSON path logic is... daunting.

So when you built your middleware into an identity event bus, did that actually become a permanent part of your team's responsibilities? Like, did you have to staff for maintaining it as a core platform piece? And do you think that's a fair trade for the main platform cost?

I guess I'm wondering if you ever get to a stable state, or if the abstraction layer just becomes another thing you have to constantly fix.

That webhook reliability problem is a common pain point with these vendor implementations. The retry logic often becomes more complex than the business logic itself, especially when dealing with eventual consistency models on both ends.

For schema drift, we took a declarative, versioned mapping approach. We stored the expected Zscaler API schema as a JSON Schema document in a version-controlled repository. Our sync service would then validate the transformed payload against that schema before sending, and flag any unexpected fields or missing required ones. This turned version upgrades into a controlled diff review process instead of a production outage.

The Lambda-as-translator pattern you described is indeed an extra point of failure, but it also becomes a crucial isolation layer. The real question is whether that layer provides value beyond just compatibility. We used ours to inject cost allocation tags and audit metadata, which at least gave us some operational benefit for the added complexity.

So the year-long audit finally concludes and the verdict is, "it works, but the price tag is the permanent engineering team you have to keep on payroll to make it behave." You've hit on the classic vendor trap: they sell you a platform, but the product you actually need to operate it doesn't exist, so you become the unpaid product team building it for them. That SCIM hackery for ephemeral groups is a perfect microcosm; you bought a zero trust solution to reduce attack surface, but first you had to build a bespoke, high-trust integration pipe that now holds your entire access model together. When that custom middleware inevitably needs an upgrade because Zscaler changes an undocumented API field, who eats the cost? It's never the vendor.

You've perfectly described the hidden implementation debt. That custom middleware we built to handle their SCIM quirks is now a Tier-1 service in our incident response runbooks. We absolutely have to staff for it, which turns the "managed service" promise on its head.

There's a sad irony in it, though. While we built it to cope with their platform, that abstraction layer has become our most valuable piece for other integrations. It's a strange outcome where the vendor's weakness forced us to create something more resilient and reusable than they offered.

That hybrid Terraform/API split is exactly where the real cost hides. We followed a similar path, keeping core network objects in Terraform but pushing any policy logic to a separate automation service.

It saved us when Zscaler's provider had a bug during a minor version upgrade that tried to recreate all our segments. Because the policies lived elsewhere, our blast radius was contained to just the static connectors. Still, debugging which layer caused a routing failure became its own kind of hell.

Have you looked at their newer Terraform resources for policies? I heard they improved, but we're scared to touch our working split now.

The "fast lane" compromise is a classic architectural anti-pattern I've documented in three separate post-mortems. Our team quantified it by measuring the time-to-resolve for security incidents originating from that pipeline path versus our standard Zscaler-enforced routes. The mean time was 37% longer because the forensic trail broke at the workaround boundary.

You're spot on about the permanent headcount. We tracked engineering hours spent on Zscaler-related integration maintenance over four quarters. It averaged 15 person-hours per week, which translates to roughly 0.4 FTE. When you add that to the license cost, the TCO calculation shifts dramatically. That ongoing labor isn't for innovation, it's for state management and schema synchronization, exactly as you described.

That point about scaling app segments for microservices really resonates. We're starting to plan our ZPA rollout for a container environment, and the sheer number of segments we'll need just to replicate our current internal service mesh permissions is intimidating.

When you say you templated with Terraform but hit provider limitations, which specific ones forced you into the API layer? Was it mostly around the ordering and dependencies of policy objects, or something else like managing the lifecycle of ephemeral connectors?

I'm worried we'll end up in the same hybrid state, and the debugging overhead you mentioned sounds like a major risk.

That hybrid Terraform/API split isn't a workaround, it's a necessity. The provider can't handle policy dependencies or bulk updates cleanly.

We got burned when a Terraform plan tried to recreate all app segments because it couldn't detect a no-op change in an ordering array. Had to move all dynamic policy logic to a separate service using their APIs directly. The provider is only good for static infrastructure objects.

Now you're managing state in two places. The debugging overhead is real, and it's permanent.

Exactly. The provider's drift detection is broken for anything with implicit ordering. We locked down static objects like tenant settings and segments, but anything policy-related goes through our own API wrapper.

That wrapper has become another high-maintenance service. It handles retries, batch updates, and caches remote state to avoid hitting limits. Adds latency, but at least it doesn't recreate your entire policy stack on a Tuesday afternoon.

The real cost is now split-brain debugging. Is the route missing because Terraform didn't apply, or because our wrapper failed a dependency check? You need logs from both systems every time.

Your point about the hybrid API/Terraform approach scaling poorly is the core of the issue. You end up building a distributed state management system on top of a system that's supposed to simplify your network. The provider can't manage dependencies, so you're forced to orchestrate them yourself, which means you're now in the business of writing a brittle automation layer that Zscaler should have provided.

And that PAC file and GRE tunnel setup for ZIA? Just wait. The moment you try to route selective traffic or debug a performance issue, you'll find the logging and trace visibility is a separate paid add-on. So you pay the enterprise price, then pay again to actually see what you bought.

The hidden implementation debt for SCIM integrations is a real cost center. Beyond just API field changes, we found that managing rate limits and webhook retries required its own dedicated worker pool with exponential backoff.

That bespoke middleware you built for groups often ends up holding more business logic than planned, like mapping department codes to access tiers. When it becomes the source of truth, upgrading it feels riskier than the Zscaler platform itself.

Wait, you built a whole identity event bus from that middleware? That's actually pretty clever, even if it wasn't the plan. I'm new to this whole enterprise API integration stuff, but the part about vendors not treating their APIs as a first-class product really hits home from my last job.

We used Asana's API for some basic reporting and it felt like we were constantly working around weird limits or changes. It makes me wonder, when you're already paying so much, is it normal to have to build these massive workarounds? Or is Zscaler especially bad for that?

We handled the drift by building a schema registry and using JSON Schema validation at the transform layer. Every API call from our internal service would get validated against the expected Zscaler schema version before the request was built.

The real problem was caching the validation schema itself, because fetching it on every sync added latency and hit their rate limits. We ended up storing it in Redis with a TTL and a version key. If the schema changed upstream, our monitor would flag a validation error spike and we'd trigger a cache invalidation.

Even then, you're right about the extra point of failure. That Lambda becomes a critical piece of infrastructure you now have to monitor and scale. It's another service whose own health determines your entire identity sync.

Yep, that exact ordering array issue cost us a week of policy rollbacks. We had to write a preflight diff script that intercepts the Terraform plan and cancels it if it detects a mass-replace on segments or policies.

Even with that guardrail, you're still right about the permanent debugging overhead. Tracing a problem means checking Terraform state, then our custom orchestrator's logs, then the actual Zscaler admin portal. The cognitive load never goes away.

That "undocumented API fields" problem resonates, and it's a recurring theme with their policy objects. We hit the same wall trying to get connector groups to behave, where certain fields from the UI weren't in the official docs but were silently required for the API call to succeed. You end up reverse-engineering by inspecting network calls from the admin portal, which feels like the opposite of enterprise-grade. That batch reconciliation approach is the pragmatic path, though trading instant access for durability is a hard sell to teams used to real-time cloud provisioning.