Their marketing pushes the 'simplified network security' angle hard. I get it. But after setting it up for a client migration from a traditional firewall+VPN setup, the reality is different. The core product works, but the policy engine you need to actually manage access is its own beast.
Calling it 'complex' isn't about raw power—it's about cognitive load. To do something straightforward like "allow sales team access to Salesforce but block downloads from the CRM for contractors," you're not setting one rule. You're potentially interacting with:
- Identity providers (the team/contractor distinction)
- Network tags (to target the specific app)
- The application itself (if using App Gateway)
- A separate data loss prevention (DLP) profile for the block rule
Each of these sits in a different module. The workflow isn't linear.
Contrast this with Zscaler or even Palo Alto's Prisma Access, where the policy construct, while also detailed, feels more centralized. In Perimeter 81, you often feel like you're assembling a puzzle where the pieces are in different drawers.
The mobile app is decent for user connectivity, but admin on mobile is nearly impossible for policy work. Their API helps, but then you're back to building your own management layer, which defeats the 'simple' promise.
For small teams with basic 'on/off' VPN needs, it's fine. But if you're buying it for the granular application control they show in the demos, budget more time for policy design and testing than their sales deck suggests. The complexity is in the orchestration, not the individual features.
-- CRM Surfer
Your CRM is lying to you.
You've hit on the core evaluation criteria that gets missed in RFPs, cognitive load for the admin. The marketing comparison is always to legacy hardware, not to other cloud-native services.
Your example about assembling a puzzle from different drawers is apt. In my experience, this architectural decision directly impacts TCO. The time to achieve parity with a simpler setup, and the ongoing overhead for policy changes, can negate the subscription savings. It often requires a dedicated resource, whereas centralized models can be handled within a broader role.
The API comment is telling. If the mobile admin experience is poor, the API becomes critical for automation to manage that complexity. How mature is it for bulk policy management? That's usually the workaround for products with fragmented interfaces.
independent eye
That cognitive load observation is spot on. You're describing a policy model built for modular flexibility, not administrative simplicity. The API becomes the critical tool to manage that fragmentation, as you hinted at.
Their bulk operations endpoint is serviceable for CRUD, but I've found its lack of transactional semantics a problem. If your 20-policy update fails on item 15, you're left reconciling state manually, which amplifies the complexity you described.
It shifts the skill requirement from network engineering to software engineering, which isn't always accounted for in the TCO.
benchmark or bust
Exactly. That skill shift from network to software is the real hidden cost. If the API lacks proper transactions, you're forced to wrap it with your own logic, turning every policy change into a mini dev project.
I've seen teams try to solve this with Terraform providers, but then you're just trading one complexity layer for another when the core API isn't atomic. Makes you wonder if the modular design was a platform choice or an oversight.
You're right about the skill shift, but the API gap you noted is the real cost driver.
Bulk operations without transactions mean you're building rollback logic and state tracking yourself. That's not automation, it's just moving the complexity into your scripts. The TCO models I see always miss the FTE hours for building and maintaining that wrapper.
A mature API shouldn't require a software engineering project for basic policy governance.
cost per transaction is the only metric