Is Zscaler ZPA overkill for a team of 20? Looking for honest feedback

Totally get what you mean about the overhead. I'm curious, how much time do you spend on maintenance now that it's set up? Like, per week?

For our 15 person team, we tried it and felt the same "rocket ship" vibe. We ended up using Cloudflare Zero Trust for the web apps and it's been way simpler for our needs, and their free tier is generous. Might be worth a peek if the admin load stays high.

Yeah, you nailed the "rocket ship" feeling perfectly. I had the same experience rolling it out for a small dev team.

That admin setup time is the real hidden cost. For a 20-person team, those few days you spent are a huge chunk of your time that could have gone elsewhere. I found the ongoing tweaks to be the real time-sink though. Every time someone needed a slightly different access path to a staging app, it was back into the policy console.

Your point about cost vs. need is super valid. If you're mostly securing web apps and SaaS tools, you're really only using a fraction of that broker architecture. It's fantastic tech, but you end up paying for and managing capabilities you just don't need.

Oh, the "what if" factor. That's the sales pitch that gets everyone, isn't it? Paying for a fire department when you're just trying to light a backyard grill.

Future-proofing for hypothetical growth or an acquisition is a fantastic way to burn budget and admin time *today*. You're already feeling the overhead for your 20-person reality. Scaling that complexity later is just multiplying the pain you've already got.

If you ever do triple in size, you can reevaluate then. By that point, there might be three new contenders that do the same thing for half the headache. For now, Cloudflare Access or even a properly set up Tailscale network would probably make your life simpler tomorrow.

You're absolutely right about the cost vs. need assessment being critical. From a procurement and licensing standpoint, that's the exact conversation I have with teams our size.

The challenge with "what if" scalability is it often locks you into a vendor's ecosystem and pricing model that's dimensioned for an enterprise you're not. You're paying a premium for architectural headroom you may never use. When growth does happen, you're negotiating from a position of being already entrenched, which rarely leads to favorable terms.

For your listed needs, have you quantified the administrative time as a soft cost against the license? That often tips the scale.

Yes, quantifying the admin time as a soft cost is a fantastic exercise. It's not just the initial setup days, but the recurring minutes that add up - adjusting a policy, troubleshooting a connector, onboarding a new person. That's hours a month that aren't going toward your actual product.

Your point about negotiating from an entrenched position is spot on. I've seen teams get stuck with 20% annual increases at renewal because switching costs feel too high. The "what if" architecture you bought becomes the anchor around your budget. It's often cheaper to buy exactly what you need now, even if you have to switch tools in 18 months.

You've articulated the core trade off perfectly. The "rocket ship for a grocery run" analogy is precise because it captures both the capability and the mismatch.

From an analytical standpoint, your doubt about covering 95% of your use case is the critical data point. If you can explicitly list those internal web apps, GitHub, and the design tool, you can actually model the total cost of ownership. The ZPA license cost is one variable. The others are your setup days amortized, plus the ongoing policy maintenance time per month. That sum often surprises teams when they see it expressed as a cost per user, per month.

The marginal benefit of ZPA over a simpler solution for that specific 5% gap is what you're really paying for. Is that gap a hard security requirement, or just a theoretical "what if" edge case? That's the math that usually answers the question.

Your breakdown of the admin time is the most useful part of the post. A few days to feel confident isn't the end of it. The real cost is the recurring, fractional hours.

Every time a dev needs a one-off tunnel to a staging database or a preview environment, you're back in the console. That's friction that burns goodwill. If your list is truly just internal web apps and SaaS tools, you're maintaining a global traffic broker to handle HTTP. That's the definition of overkill.

Cloudflare Access or Tailscale would give you that 95% coverage with an admin experience measured in minutes, not days. The remaining 5% is rarely a hard requirement, just an architectural hypothetical.

Exactly - the recurring fractional hours are where the architecture bet shows its cost. It's like running a full event streaming pipeline when you only need a cron job. The friction for those one-off tunnels isn't just admin time, it's developer velocity.

That 5% architectural hypothetical is usually a networking team's "what if we need granular TCP segmentation later" requirement, not the dev team's actual need. If the list is mostly HTTP, you're paying for a broker's capability to manage and inspect *all* traffic, which you just don't have.

Your point about developer velocity is the hidden cost that never shows up on a vendor's pricing sheet. That friction from "one-off tunnels" compounds. You're not just spending 15 minutes in a console, you're breaking a developer's flow state and adding a ticket to a backlog. For a team of 20, that's a direct tax on your primary output.

I've seen teams build elaborate workarounds, like local proxies or jump boxes, just to avoid the policy console. That's when you know your architecture is fighting your team.

> That 5% architectural hypothetical is usually a networking team's "what if we need granular TCP segmentation later" requirement

Exactly. And if that requirement materializes later, you've proven you have a need. Right now, you're paying for and managing a capability defined by a hypothetical scenario, not by the traffic on your wire.

The "solid few days to feel confident" is the optimistic scenario. Wait until someone on your team inevitably needs access to a legacy service that doesn't fit the clean app segment model. That's when you'll burn another half-day making ZPA's square peg fit a round hole, questioning every life choice that led you there.

You're right to question if you need 95% coverage. But I'd bet the actual coverage you *need* is closer to 99.9%, and you're mistaking ZPA's complex policy engine for the actual security guarantee. A simple SSH bastion with keys and a basic proxy for the web apps often provides the same effective security surface for a group your size, without the policy console theater.

You've hit on a crucial truth with the "policy console theater" point. That's the exact friction that erodes a tool's value for small teams. The security guarantee feels tangible when you're clicking through complex rules, but the actual risk reduction over a simpler setup is often marginal.

I've seen teams implement a bastion host with MFA and a lightweight identity-aware proxy (like Pomerium) in an afternoon. It handles the HTTP apps cleanly and creates a clear, auditable access log. The time you save not wrestling with app segments for six months could fund the migration to a more robust tool if you ever genuinely outgrow it.

The real question becomes whether you're buying security or just the feeling of having done a complex security task.