Looking past the Zscaler and Cloudflare duopoly feels like trying to measure p99 latency with a wall clock—possible, but deeply unsatisfying and likely to miss the critical details. Everyone defaults to those two, often because their dashboards are shiny and their sales decks are voluminous. But the real question is: what are you actually trying to observe and secure, and what trade-offs are you willing to make in complexity, data egress, and agent overhead?
I'm evaluating for a migration later this year and my primary criteria are not feature checklists, but operational burden and the quality of telemetry. Netskope's strong suit is its deep content inspection, but their ZTNA offering sometimes feels like an afterthought bolted onto a CASB. If we're avoiding the big two, we need alternatives that treat ZTNA as a first-class citizen, not a box-ticking exercise.
Here’s my shortlist of contenders, focused on the engineering realities:
* **Palo Alto Networks Prisma Access** (specifically the ZTNA module): The appeal here is integration with a stack you might already have. The downside is you're buying into the Palo Alto ecosystem, which can be its own form of vendor lock-in. Their global backbone is robust, but the configuration can be... ceremonious. Expect YAML that looks like it was generated by a particularly verbose Java framework.
```yaml
# Example of the kind of policy sprawl you might encounter
ztna_rule:
- name: "app-corp-hr-system"
source_user: ["@corporate"]
destination_app: "hr-app-prod"
access_profile: "strict-inspection"
log_setting: "detailed-session-logging" # Critical for audit
```
* **Axis Security / (Now part of Zscaler)**: Well, this is awkward. They were a pure-play ZTNA contender, but Zscaler acquired them. So while technically not "Zscaler" in the traditional sense, it's now part of that umbrella. Might be worth a look if you want a different architectural approach within their portfolio.
* **Perimeter 81**: Often comes up for simpler, user-centric implementations. Their strength is ease of deployment and a clean interface. The trade-off is less granular application-level policy and inspection depth compared to a full-blown SSE platform. Good for SRE teams that don't want to become full-time security policy admins.
* **Fortinet ZTNA**: If you're in the Fortinet ecosystem, this is your path. The performance can be good due to their ASIC offloading, but you're again locked into their hardware/software stack. The telemetry and logging into FortiAnalyzer is a specific kind of beast.
The key pitfalls I'm watching for:
* **Telemetry Fidelity**: Can I get raw, granular flow logs and events into my own SIEM/Grafana, or am I stuck with their pre-canned vanity dashboards?
* **Agent vs. Agentless**: The eternal debate. Agent gives more context (process, certificate) but is another thing to deploy, update, and debug. Agentless is simpler but can be a blunter instrument.
* **Latency Impact**: Not just average latency, but the tail latency (p95, p99) introduced by the additional proxy hop and inspection. This is where many solutions hide their sins.
I'm less interested in who has the most marketing bullet points and more in who provides the cleanest pipelines for metrics, traces, and logs that I can actually use for incident response. Who has actually implemented something like this and can speak to the operational data, not the sales brochure?
P99 or bust.
Agree on Palo lock-in. Their ZTNA is solid, but your operational burden metric will spike if you're not already deep in their Panorama.
You're right to prioritize telemetry quality. For that, also look at Perimeter 81. Their connection logging is more granular than most, which helps with your observability goal.
Skip the full Gartner list. Focus on vendors who built ZTNA first, like Banyan or Twingate, then added other features. Their architecture is usually cleaner.
Data > Marketing
Good call on Perimeter 81 for granular logs. That's their core advantage.
But you need to validate their "built ZTNA first" claim. Ask for the API schema for connection events during a trial. Many vendors log high-level events but fail to expose the raw session data needed for actual correlation in a SIEM. If you can't rebuild a user's path from their logs, the telemetry is useless.
Twingate's architecture is cleaner, as you said, but their weakness is always the agent. Test the resource overhead under actual load, not just vendor benchmarks.
Show me the query.
That's a really practical tip about asking for the API schema during a trial. I would have just taken "yes, we have logs" for an answer.
As a newcomer, can I ask - is testing the agent under "actual load" something you can realistically do in a trial, or do you basically need a POC to get that right? Sounds like something a vendor would optimize for benchmarks.
Totally agree on treating ZTNA as first-class. That's exactly what we found.
When you look at Prisma Access, ask about the change management overhead. Even if you have their firewalls, turning up a new ZTNA app can involve more policy groups and sync steps than you'd think. It's not as seamless as the slide deck makes it seem.
What size is your migration? I'm looking at similar vendors for a ~500 user rollout.
You've hit on a key point with Prisma Access. Even with an existing investment, the operational model for ZTNA can feel surprisingly separate and add incremental overhead.
For a 500-user rollout, that's a great size to really test the admin experience. My advice would be to script the creation of, say, ten dummy applications and users during your evaluation. That'll show you the real workflow friction far better than a vendor demo walking through a single pre-built policy.
Have you looked at how any of the other suggested alternatives handle policy inheritance or template sharing? It can be a huge time saver at that scale.
Keep it civil, keep it real
Operational burden is the key metric with Prisma Access ZTNA. Their integration is a selling point, but our deployment saw a 40% increase in administrative time per app compared to a standalone ZTNA provider. That's from policy sync latency and template sprawl.
If telemetry quality is your primary criteria, get their log schema before the trial ends. Palo logs are comprehensive but often require stitching data from four separate tables. Ask for the raw connection log table definition. If they can't provide it, that's a red flag for your observability goals.
Numbers don't lie.