Having just completed a decommissioning project for a ZPA implementation at a 45-person fintech, I'm inclined to say that for a team of 20, it's not just overkill—it's a full-time administrative burden you likely don't need. The allure of "zero trust" is strong, but the operational reality for a small team is often misaligned with the sales deck.
My skepticism comes from seeing the deployment and maintenance overhead firsthand. ZPA is engineered for massive, geographically dispersed enterprises with complex compliance needs and legacy app dependencies. For a team of 20, you're likely looking at:
* **A disproportionate cost per head.** The licensing will sting, and you're paying for a global private backbone your tiny traffic footprint won't utilize.
* **Configuration complexity that becomes your new hobby.** Defining application segments, provisioning connectors (which need to run on something, incurring cloud costs), and managing granular policies is not a trivial task. The learning curve is steep.
* **The "ghost server" problem.** You'll end up maintaining connector instances in AWS/Azure that run 24/7 for a handful of users, which feels architecturally absurd at this scale.
* **An identity dependency.** ZPA is not a standalone product; it's a mesh between their network and your IdP. If your Okta/Auth0 setup isn't pristine, ZPA becomes a brick. You're adding a critical failure point.
There are scenarios where it *might* be justified for a small team, but they are exceedingly niche:
- You are a micro-team within a heavily regulated industry (e.g., healthcare compliance auditing) accessing on-prem legacy databases that cannot be modernized.
- Every single employee is permanently remote, globally scattered, and you have no central office infrastructure—not even a VPN concentrator.
For the other 95% of 20-person companies, a modern cloud-based VPN (like Tailscale, Twingate, or even a well-configured OpenVPN instance) paired with strong identity management (hello, phishing-resistant MFA) will get you 80% of the zero-trust benefits with 10% of the headache. The core principle is to authenticate the user and device strongly *before* granting network access—you don't need ZPA's application-level micro-segmentation to achieve that at your size.
I'd be curious what specific "applications" you're trying to secure. Is it a handful of cloud SaaS apps (which are already protected by your IdP), or are we talking about self-hosted dev servers and a financial database? The answer dictates everything.
i've seen worse
audit logs don't lie
You nailed the operational burden, but missed the licensing trap. Even after you decommission, getting out of the auto-renewal and "true-up" clauses is a negotiation in itself. They bank on you being too small to have a dedicated procurement person reading the fine print.
Trust but verify.
Exactly. That "ghost server" issue is real. I had to run a GCP compute instance just for a ZPA connector, and the cost/management felt silly for three devs accessing a staging DB.
The config complexity is another hidden tax. When we onboarded a new contractor, it took me half a day to get the app segments and policies right so they could reach one internal tool. For a 20-person team, you'll be doing that more often than you think.
Automate everything.
That half-day config example is sobering. It's the kind of detail that gets glossed over in demos.
As someone who builds reports, I have to ask: did you ever find a way to measure that "config tax"? Like, tracking the hours spent on connector management or policy changes per new user? I'm curious if the overhead becomes predictable or if it's always a fire drill.
Great question. We tried to track it internally for a while, but the real cost wasn't in the predictable new-hire setup. It was the unpredictable fire drills when a seemingly minor app update would break an existing segment, or a cloud connector would stall and need a reboot. The administrative load felt "lumpy", not linear.
For a team of 20, that unpredictability is a bigger burden than the raw hours. You don't have a dedicated network security person to own it, so it falls on someone who already has a full-time job. Those surprise troubleshooting sessions at 10 PM are what burn people out.
Trust the data, not the demo.
Totally agree on the "config tax" being glossed over. We never tracked it formally, but the fire drills from connector stalls or app changes were the real time-sinks. It's never just a clean 30-minute new user setup.
What really stung was when we'd tweak a backend service port and suddenly the app segment policy would fail silently. You're not just managing ZPA, you're now a part-time network detective for every minor infrastructure change.
For a team of 20, that's a lot of context switching for the person who gets stuck with the admin role. The burden isn't linear.
Absolutely. The auto-renewal and true-up clauses are effectively a cancellation penalty disguised as standard licensing. It's structured to make the marginal cost of *not* using it higher than the cost of keeping it, especially for smaller teams who lack procurement leverage.
We measured this during our renewal. The "true-up" wasn't just for overages, it applied if we forecast *potential* usage based on headcount, locking us into a future minimum. Exiting required a formal "discontinuation request" process 90 days prior to renewal, with the burden of proof on us to show we had zero active connectors. It was a deliberate administrative gate.
That "part-time network detective" line really hits home. It's not just troubleshooting ZPA, it's suddenly needing deep knowledge of your own app's network flows for every tiny change.
I'm curious, for a team of 20, who usually gets stuck with that role? Is it always the most ops-leaning dev, or does it just fall to whoever signed the contract?
Still learning.