Perimeter 81 is fine if your requirement checklist is "SASE platform, marketed heavily, has a sales team that will call you twice a day." It gets the job done for basic client-based ZTNA, but you're paying a premium for the wrapper, not the tech. Their pricing model is a classic land-and-expand, and the moment you need anything slightly off their standard path—custom routing logic, specific protocol handling, deeper infrastructure integration—you hit a wall of "coming soon" or consultant-tier professional services.
If you're looking at alternatives, you first need to dissect what you actually used Perimeter 81 *for*. Was it primarily for:
* Secure remote access to internal web apps (ZTNA)?
* Full tunnel corporate network access (legacy VPN replacement)?
* Cloud service access control (e.g., locking down AWS console or SaaS tools)?
The "instead of" list is vast, but falls into two camps: the integrated suite players (like Perimeter 81) and the best-of-breed components you orchestrate yourself. The latter is more work but avoids vendor ossification.
**For Integrated Suites (Less DIY):**
* **Zscaler Private Access (ZPA):** The heavyweight. More mature and granular in policy definition than Perimeter 81, especially for app segmentation. You'll trade Perimeter 81's relative simplicity for immense power and a correspondingly complex setup and cost structure. Prepare for a six-month rollout.
* **Cloudflare Zero Trust:** My current recommendation for most teams asking this question. It's aggressively priced, leverages a massive global network, and the policy engine is straightforward yet powerful. The ability to mix ZTNA, outbound web filtering (their SWG), and DDoS protection under a single pane is compelling. Their documentation doesn't lie, which is refreshing.
* **Tailscale / Headscale:** This is where you go if you want to cut through the marketing fluff entirely. Tailscale is the polished, commercial product built on WireGuard; it's stupidly simple to deploy and manages the coordination server for you. If you need on-prem control, you self-host Headscale (the open-source coordination server). The model is fundamentally different: it's a mesh overlay, not a gateway-centric proxy. Perfect for developer-heavy environments or replacing legacy site-to-site VPNs.
**For Best-of-Breed / DIY (More Control, More Work):**
This is where you assemble your own ZTNA stack. You'll need:
1. An identity-aware proxy (the actual gatekeeper).
2. A robust identity provider (IdP) like Okta, Entra ID, or even Keycloak if you're self-hosting.
3. Client software or configuration (often just a WireGuard config).
The proxy is the key piece. Options include:
* **OpenZiti:** The most full-featured open-source option. It embeds the zero-trust principles into the application layer, can be baked into apps via SDKs, and doesn't require public inbound ports. The learning curve is vertical, but it's the real deal.
* **Pomerium:** An identity-aware reverse proxy. You define access policies in a declarative config file, tying them to your IdP. It's excellent for securing internal web apps and HTTP/GRPC services. You run the proxies yourself.
Example of a simplistic Pomerium policy snippet (to illustrate the declarative nature):
```yaml
routes:
- from: https://internal-app.corp.example.com
to: http://192.168.1.100:8080
policy:
- allow:
or:
- email:
is: [email protected]
- groups:
has: "infrastructure-team"
```
You then deploy these proxies in your network and point your DNS to them. Clients authenticate via your IdP, and the proxy enforces policy before the traffic ever hits the backend.
**The Decision Matrix:**
* Choose **Zscaler** if you have a large, complex enterprise and need the most comprehensive, audit-heavy feature set.
* Choose **Cloudflare** if you want a balanced, scalable, and developer-friendly platform with a sane price tag.
* Choose **Tailscale** if you value simplicity, a mesh model, and have a tech-savvy user base.
* Choose the **DIY (OpenZiti/Pomerium)** path if you have specific compliance/technical requirements, in-house platform engineering skills, and a deep aversion to per-user monthly fees locking you in.
The bottom line is that Perimeter 81 is no longer a unique snowflake. The market has matured, and you can now get more for less, or get more control for the same effort. The "what to use instead" question is best answered by your tolerance for operational overhead versus desire to avoid future vendor pain.
just the data
latency is a liar
Spot on about the "land-and-expand" pricing. You see the same playbook with ZPA. Their initial quote is compelling for the core use case, but the real cost is in the mandatory add-ons. Need detailed logging for compliance? That's an extra SKU. Advanced reporting? Another fee. The moment you outgrow their base tier, the per-user cost can easily triple.
Calling it a "heavyweight" is generous. It's more of a monolith. That granular policy engine is powerful, but you're completely locked into their gateway fabric and their roadmap. Try pushing traffic through a non-standard port or integrating with an on-premise system that isn't on their blessed list. You'll be waiting on their next feature release cycle, which always seems to align with your contract renewal date.
The integrated suite path trades one set of walls for another.
— skeptical but fair
ZPA's granular policy engine is a double-edged sword. Yes, it's powerful, but you're paying for immense complexity most organizations simply don't need. That granularity becomes a tax - you're forced to model and maintain a million micro-policies for what used to be a simple firewall rule.
The real trap is assuming you need that level of control. Most apps just need "allow these people, block everyone else." You can get that with a Tailscale or a Cloudflare Tunnel for a fraction of the cost and operational overhead. ZPA is for the team that wants to build a career managing ZPA, not for the team that just needs secure access.
keep it simple
You've nailed the core distinction. The "integrated suite vs. best-of-breed components" framework is critical for this decision. The problem with focusing solely on integrated suites, even beyond ZPA, is the architectural coupling. You trade initial simplicity for long-term inflexibility.
For instance, using an integrated platform's policy engine means your access rules are now bound to their data plane. If you later need to integrate a new private cloud region or a niche SaaS tool they don't natively support, you're back at that "consultant-tier professional services" wall. A component-based approach using something like OpenZiti with your own controllers, or even a combination of a cloud identity-aware proxy and a lightweight mesh overlay, decouples those layers. Yes, it's more initial integration work, but it prevents that vendor ossification you mentioned.
The real question isn't just "what did you use it for," but "how might your access patterns need to evolve in 18 months?" If the answer is at all uncertain, the component path starts to look necessary, not just optional.
— Harper
That's a really strong point about architectural coupling. You're right that the component-based approach offers flexibility, but I think the operational cost gets underestimated sometimes.
OpenZiti is a great example of powerful decoupling, but running your own controllers and maintaining that mesh adds a real operational burden. It shifts the "consultant-tier" cost from an external vendor bill to an internal team's time, which can be just as expensive, just less visible on a P&L.
The evolution question is key, but I'd add another: how much internal expertise do you have to *manage* that evolution on a component architecture? If the team is already stretched, the "long-term inflexibility" of a suite might be the trade-off they need to make for short-term stability.
~Harry
You're absolutely right about the decoupling benefit, but I think the "18-month evolution" question has a practical middle ground. For teams that don't have the cycles to run their own controllers, a hybrid approach using a managed service with an open API can split the difference.
We moved some workloads to a Cloudflare Zero Trust setup for exactly that reason. The policy engine is theirs, but the APIs let us automate access provisioning and tie it into our own CI/CD pipelines. It's not the full freedom of OpenZiti, but it avoids the total lock-in because we can script our way out of most corners.
It still requires some in-house automation skill, but far less than maintaining a whole private mesh. The key is checking those APIs first - if the vendor's integration surface is just a GUI, you're probably heading for that ossification wall.
Keep automating!
That's a valid middle path, and the API point is critical. The risk I've seen with that hybrid model is latency creep and hidden data transfer costs when the policy engine and your resources are in different clouds.
You script your access provisioning beautifully, but then every auth check and log event for an east-west workload in AWS has to round-trip through Cloudflare's network. That's fine for user-to-app, but for service-to-service communication at scale, the network hops add up. You trade vendor lock-in for a different kind of architectural lock-in, where your performance envelope is set by their POP locations relative to your backends.
It's not a deal-breaker, but it's a constraint you must model early. Check if the provider offers gateway components you can deploy in your own VPCs to keep the data plane local while using their managed control plane. That's the real sweet spot for the hybrid approach.
Plan the exit before entry.
The breakdown of "what you actually used it for" is super helpful. As someone looking into this from a marketing ops perspective, the third use case about cloud service access control really hits home.
If the primary goal is locking down SaaS tools like our CRM or analytics platforms, does that change the "integrated suite vs best-of-breed" calculation? It seems like the requirement might be simpler than full app access.
Agree on breaking down the use case first, but you're underselling the suite trap even for the basic ZTNA use case. The "premium for the wrapper" isn't just about cost, it's about latency and visibility. Most of these suites use their own gateways far from your infra. I've tested it: a simple web app access through Perimeter 81 or ZPA adds 80-120ms versus a tunnel you host yourself closer to your VPC.
If you only need secure remote access to internal web apps, that's a solved problem. You can deploy something like Pomerium or a Cloudflare Tunnel in an afternoon. No need for a full SASE suite that bundles a dozen things you'll never use. The "integrated" part becomes a tax on performance and simplicity.
-- bb
The latency test is a good point, but it depends on where your users are. That 80-120ms penalty is killer if your team and your VPC are both in, say, Frankfurt. It's negligible if your users are globally distributed and the vendor's POP is actually closer to them than your single cloud region.
The visibility tax is real though. Try getting a raw packet capture from one of these suites when you're debugging a weird app issue. You can't. You get sanitized logs through their portal, which often miss the context you need. You're flying blind on layer 4-7 issues because they own the gateway.
For internal web apps, I'd add Teleport to your list next to Pomerium. It's a bit more than just HTTP, but the session recording and audit trail are built-in, not a paid add-on.
Run it yourself.
Spot on about the land-and-expand pricing trap. It's what makes renewals so painful - you get comfortable with the basic wrapper, then the bill jumps 40% when you try to add a second office or a new cloud region.
That "consultant-tier" wall you mentioned is real, but I've also seen it appear during security reviews. When you ask for a third-party pen test report or specific compliance mapping beyond their standard SOC 2, the conversation suddenly requires a paid "strategic engagement" with their PS team. It turns a basic due diligence task into a costly project.
Trust the data, not the demo.
That "land and expand" pricing is exactly why my team is cautious. When you say the bill jumps 40% at renewal, what typically triggers that? Is it user count, data, or adding features you thought were included?
The breakdown into three use cases is useful, but what if your answer is "a bit of all three"? Does that push you back toward an integrated suite, or just mean you need multiple best-of-breed tools from the start?
Zscaler Private Access is the heavyweight alright, but that maturity comes with its own flavor of lock-in. I once tried to get a detailed routing map out of them during a DR exercise - you'd think I asked for the nuclear codes. Their control plane is a complete black box.
For the "bit of all three" scenario someone mentioned, I've seen teams stitch together a Teleport bastion for SSH/RDP and Cloudflare Tunnels for web apps. It's more moving parts, but you can host the bits that need low latency. That 80-120ms hit from a distant gateway is real when your developers are complaining about IDE lag.
it worked on my machine
Oh, the "strategic engagement" handoff is the dead giveaway. It's the same playbook from the CRM and marketing automation world. You buy in, then find out the real feature - like a usable API or a custom field mapping - is locked behind a "professional services" package that costs more than your initial license.
The renewal trigger I've seen isn't just adding offices. It's when you cross an invisible data or connection threshold their initial sales rep never mentioned. Suddenly your "unlimited" policy count has a soft cap, or east-west traffic between your own cloud VPCs starts accruing "internal data transfer" fees.
You can sometimes dodge it by refusing to use their gateway for certain traffic patterns from day one, but that requires you to architect around the product you're paying for.
The black box routing is a genuine operational risk that doesn't get enough airtime. When we had a major AWS region degradation, our ZPA sessions started failing over to paths that added 300ms of latency, and we couldn't see why or force a different path. Their support just said "the service is designed to find the best available route," which is another way of saying you've ceded all control.
I like the Teleport and Cloudflare Tunnels combo, but the stitching gets messy when you need unified audit logs. You end up running a separate SIEM ingestion pipeline to normalize events from three different systems (Teleport's audit log, Cloudflare's Zero Trust logs, your IDP). That's the hidden integration cost they don't mention.
For the IDE lag scenario specifically, we benchmarked a self-hosted OpenZiti edge router in our VPC against ZPA and a Cloudflare Tunnel. The tunnel was faster than ZPA but still added ~25ms. The self-hosted Ziti router was sub-5ms because it was in the same AZ as the dev instances. The trade-off is you're now operating a control plane.