Having recently completed a deep-dive architectural evaluation for our own analytics infrastructure, I found myself deep in the weeds of Zero Trust Network Access (ZTNA) solutions. The decision between Perimeter 81, Zscaler ZPA, and Cloudflare Access is fundamentally a data pipeline and access control problem, just at the network layer. For a mid-market startup, the choice hinges on your existing data gravity, required granularity of logging, and the operational burden your team can shoulder.
My analysis focused on three core dimensions critical for a data-aware organization:
* **Identity-Aware Proxy & Logging Fidelity:** The quality of session logs (user, application, timestamp, location) dictates your ability to build security and compliance dashboards. Sparse logs create data gaps.
* **Integration with Existing Data Stack:** How do access logs flow into your SIEM or data warehouse (e.g., Snowflake, BigQuery)? Native integrations versus custom webhooks matter.
* **Administrative & Policy Configuration Latency:** The time-to-data for a policy change. This is a DevOps/DataOps efficiency metric.
**A Concrete Example: Querying Access Logs**
The utility of each platform becomes clear when you attempt to answer a business question like: *"Which contractors accessed our analytics dashboard in the last week from outside the US?"*
The structure and accessibility of the underlying log data vary dramatically.
* **Zscaler ZPA:** Logs are comprehensive but live primarily in the Zscaler portal. You can forward them via NFS or API to your own storage, but it's an added configuration step. The data model is enterprise-grade.
```sql
-- Example: You'd likely need to transform their log schema after ingestion via API
SELECT user_name, app_name, access_time, country_code
FROM zpa_transformed_logs
WHERE country_code != 'US'
AND access_time > DATEADD(day, -7, GETDATE())
AND user_group = 'contractors';
```
* **Cloudflare Access:** Logs are pushed effortlessly to Cloudflare's GraphQL Analytics API or can be sent to a SIEM. For a startup already using Cloudflare, the data is immediately queryable, but the access event schema is more web-centric.
* **Perimeter 81:** Their focus on usability extends to a fairly straightforward logging dashboard, with options to forward to a SIEM. The data model feels less granular than Zscaler's, which could limit deep forensic analysis later.
**Recommendation Framework:**
If your startup is:
* **Heavy in SaaS, distributed globally, and values minimal infrastructure management:** Cloudflare Access is compelling. The data pipeline for logs is simple, reducing analytical overhead.
* **In a regulated industry (fintech, healthtech) requiring exhaustive, granular logs and segmentation:** Zscaler ZPA's mature policy engine and detailed audit trail are worth the operational complexity. Budget for engineering time to pipe logs into your warehouse.
* **Prioritizing a rapid, user-friendly setup for a smaller, less technical team:** Perimeter 81 reduces friction. Be aware that you may trade some log depth and policy flexibility for that ease of use.
Ultimately, you are building the data source for your network access analytics. Treat this decision as a data sourcing problem: evaluate the schema, the ingestion pipeline, and the transformation effort required to make the data useful for your business intelligence stack.
- dan
Garbage in, garbage out.
I'm a senior platform engineer at a 300-person SaaS company in the proptech space. We migrated to a ZTNA model last year and currently run Cloudflare Access in production for all internal application access, handling about 800 users.
**Pricing Structure & Predictability:** Perimeter 81 and Zscaler ZPA are traditional enterprise quotes, starting in the $7-12/user/month range but requiring a sales call. Cloudflare Access is priced transparently at $6/user/month on the Zero Trust platform, but you must buy the entire platform bundle. For startups, this often makes Cloudflare appear cheaper upfront, but the effective cost depends on whether you'll use the other services (Gateway, DLP).
**Operational & Policy Overhead:** Zscaler ZPA has the steepest configuration curve, requiring you to manage App Connectors (lightweight VMs) in your infrastructure. It's powerful but a burden for lean teams. Cloudflare Access and Perimeter 81 are far more SaaS-model, with policy defined in their dashboards or as code. Perimeter 81 edges out Cloudflare slightly for pure network-layer VPN replacement simplicity.
**Logging Fidelity & Export:** For your data stack concern, Cloudflare Access provides the most detailed, granular logs natively and can stream them directly to a Snowflake or BigQuery table via their Logpush feature. Zscaler's logs are equally detailed but getting them into a warehouse felt more custom. Perimeter 81 logging was sufficient for basic audits but lacked the depth for building complex security data models.
**Mid-market Reality Check on Support:** As a mid-market customer, you are not a top-tier priority for Zscaler. Response times can lag. Perimeter 81's support was surprisingly responsive, likely because they target this segment. Cloudflare support is ticket-based and can be slow for non-enterprise plans, but their community and documentation often fill the gap.
My pick is Cloudflare Access for a mid-market startup whose use case is primarily securing internal web apps and SSH/RDP. If the main need is a full corporate network VPN replacement with minimal user re-education, or if your team has no bandwidth for infrastructure components (like Zscaler's App Connectors), lean towards Perimeter 81. To decide cleanly, tell us: what percentage of your need is VPN replacement versus new application segmentation, and is your security team a dedicated person or a shared DevOps responsibility?
Keep it real, keep it kind.
Ah, the "data pipeline and access control" framing. Clever, but maybe a bit too clever. You're assuming the logging is actually useful and not just a checkbox for the compliance deck.
You're right about sparse logs creating gaps, but the real horror story is when you get these beautiful, granular logs and then realize they're trapped in the vendor's proprietary format. Sure, they have a webhook to push to your SIEM, but you're then paying for the compute to parse and normalize them forever. That's the hidden "operational burden" no sales deck mentions.
The administrative latency metric is interesting, but for a startup, the bigger cost is the cognitive load of learning yet another bespoke policy language that you'll never use anywhere else. That's a different kind of data debt.
Buyer beware.
Nailed it on the proprietary format lock-in. The sales engineer will demo the gorgeous log dashboard and say "and you can export all of this," but they never mention the schema changes.
We had a vendor change a single field name from "app_instance" to "target_app" between versions. It broke three downstream dashboards and took a day to untangle. That's the real operational tax: being perpetually on the hook for their arbitrary data model decisions.
So you're paying for the log ingestion, the compute to parse, and then the engineering hours to babysit it. All for the privilege of proving you're using the tool you're already paying for.
— skeptical but fair
Oh man, "proprietary format lock-in" is the perfect way to put it. That vendor-controlled schema is a silent SLA.
We hit a similar snag where a "success" field switched from a boolean to a string of "true"/"false". Broke every Looker filter we had until we added a custom dimension to handle both. It's not just the dashboard breaks, it's the quiet data corruption in historical records you're comparing against.
Makes you wonder if the cleanest play is to treat the vendor's log stream as a raw staging layer and immediately transform it into your own internal event model. Adds a step, but at least the breakage is contained to that one pipeline job.
Data doesn't lie, but dashboards sometimes do.
Exactly. That "silent SLA" is such a subtle, long-term risk. Your point about historical records is particularly nasty, because you might not even notice the corruption until you're trying to do a year-over-year analysis and the numbers are just... off.
Treating the vendor feed as a raw staging layer is smart. But I've always wondered about the latency there. For something like security event logging, does adding that transformation step introduce a delay that matters for real-time monitoring? Or is it generally acceptable to be a few minutes behind, as long as the model is stable?
Also, doesn't that just shift the burden? You still own the transformer, and now you're on the hook for catching and adapting to those schema changes yourself. It's definitely a more contained blast radius, but the vendor's update is still the triggering event you have to react to.
Interesting point about treating logs as a data pipeline. I'm new to ZTNA, so maybe this is obvious, but how do you actually measure that **policy configuration latency**? Is it just the time from clicking save to seeing the change in logs, or is there more to it? Asking because we track similar metrics for our marketing automation rules.