Our organization recently completed a 18-month evaluation and phased rollout of Perimeter 81 as our primary Zero Trust Network Access (ZTNA) solution, replacing a legacy VPN and a collection of point solutions for cloud application access. The mandate came from the CISO office, driven by a need to unify access controls for a hybrid workforce across three primary regulatory domains: GDPR for our European operations, HIPAA for our healthcare analytics division, and PCI DSS for our payment processing systems. The core question was whether a singular SaaS platform could handle the granularity, auditing, and performance demands at our scale—approximately 15,000 global users and 2,500 cloud and on-premise resources.
The implementation was broken into distinct phases, allowing for controlled benchmarking. The following is a technical and operational analysis.
**Architecture & Core Components**
Perimeter 81’s architecture is agent-based, with gateways deployed in our AWS and Azure tenancies. The management plane is SaaS, which initially raised internal security objections. We mitigated this by enforcing strict identity federation via SAML 2.0 with our existing IdP (Okta), requiring hardware keys (YubiKey) for all privileged administrator access, and auditing all management plane API calls. The network topology we implemented is a "full mesh" of gateways across 12 regions to minimize latency.
**Compliance & Logging Efficacy**
The platform’s strength lies in its granular access policies and immutable logging. We defined policies based on user groups, device posture (using their built-in compliance checks), and application identity, moving well beyond simple IP-based rules. For example, a policy for our PCI environment:
```
Policy Name: PCI-Cardholder-Data-Env
Users: finance-pci-users@corp
Devices: Requires encrypted disk, OS version >= 10.15.7, agent running
Applications: 10.10.50.0/24:443 (PCI app servers), *.pci-database.internal:5432
Action: Allow
Logging: Full session metadata (user, device, app, bytes transferred)
```
The logs are streamed via SIEM connector to our Splunk instance. The schema is consistent, which simplified creating compliance reports for quarterly audits. The ability to produce a user-to-application access map on-demand satisfied several auditor requests for PCI DSS Requirement 1.2.1 and GDPR Article 25.
**Performance & Latency Benchmarks**
We conducted systematic latency tests comparing the legacy VPN concentrators to Perimeter 81 gateways for the same application set. Tests were run from 5 global user hubs over a 72-hour period.
| Connection Method | Avg. Latency (ms) to US-East-1 | Avg. Throughput (Mbps) | TCP Connection Setup Time (ms) |
|-------------------|--------------------------------|------------------------|--------------------------------|
| Legacy IPSec VPN | 142 | 72 | 2100 |
| P81 Gateway (Opt) | 89 | 95 | 380 |
The reduction in connection setup time was the most significant operational improvement, directly impacting user experience for short-lived connections (e.g., database queries, API calls). The throughput is sufficient for standard enterprise applications but note: this is not a solution for high-bandwidth data lake transfers; we maintain direct, secured connections for that workload.
**Notable Pitfalls and Configuration Complexities**
* **Service Account Access:** The initial model assumes human users. Providing secure, audited access for CI/CD pipelines and service accounts required a workaround using a dedicated "machine user" in our IdP and a tightly scoped policy, which is less than ideal.
* **On-Premise Resource Integration:** While straightforward for cloud VPCs, integrating deep on-premise segments required deploying their "Connector" appliance. We encountered routing conflicts with our existing OSPF setup that necessitated careful subnet segmentation.
* **Cost Scaling:** The per-user licensing model became a significant point of discussion as we scaled. The cost-benefit analysis tilted positive only after we decommissioned the legacy VPN hardware and several web application proxy servers, factoring in operational overhead savings.
**Conclusion**
Perimeter 81 successfully met the primary compliance and security requirements for a Fortune 500 environment. Its policy granularity, logging, and performance are superior to traditional VPNs. However, its value is maximized in cloud-native or hybrid-cloud environments; deeply complex, legacy on-premise networks will require substantial integration effort. The platform is not a panacea for all access patterns—high-bandwidth data engineering workflows and machine-to-machine communication are better served by complementary technologies. For the core use case of providing secure, compliant, and performant access for human users to distributed applications, it is a robust and effective ZTNA implementation.
Interesting to hear you went with an agent-based setup. We looked at that too but had major pushback from our data engineering teams - they hated the idea of managing another persistent agent on their already-taxed cloud VMs for database access.
How did you handle the SAML integration for non-human service accounts? We found that was a real sticking point, even with Okta. The API-based authentication for those accounts felt like a secondary, less polished feature.
Data doesn't lie, but dashboards sometimes do.
Eighteen months is a long time to lock yourself into a proprietary agent architecture. What's your exit plan when their pricing doubles after your next audit? That SaaS management plane isn't a feature, it's your new single point of failure and vendor lock-in.
Just saying.
I get where you're coming from on vendor lock-in. It's a legitimate risk with any proprietary platform. However, calling the SaaS management plane a single point of failure is a bit off base. In our context, it actually reduced the SPOF risk we had with our old on-prem hardware VPN concentrators.
The pricing question is fair game. Any multi-year enterprise contract without clear exit terms is a problem. Ours includes annual caps on renewal increases and explicit data portability clauses for configs and logs. If you're evaluating, never sign without those.
The real lock-in isn't the agent itself. It's the operational processes and the integrated policy engine you build around it. That's harder to migrate than any software component.
Keep it constructive.
Calling the SaaS plane a single point of failure is technically incorrect. The real SPOF was our legacy hardware. A properly architected SaaS control plane has far higher availability SLAs than anything we could run ourselves.
That said, I completely agree on the pricing risk. Eighteen months is too long for a single evaluation without contractual guardrails. Any serious procurement should mandate them upfront.
- Annual renewal caps, tied to a published index.
- Clear offboarding and config export requirements.
- Defined costs for historical log retention post-exit.
If they won't put those in the contract, you walk. The tech is secondary.
Your cloud bill is 30% too high
Interesting to hear you handled the SAML objection that way. I'm still learning about identity federation for ZTNA. Did using your existing Okta setup make the compliance audit trail any cleaner, or did it just shift the complexity somewhere else?
The phased rollout approach you mentioned, especially for benchmarking, is really smart. It's something I wish we'd done more rigorously in a past implementation.
> strict identity federation via SAML 2.0 with our existing IdP
Could you elaborate on how you structured the attribute mapping in Okta? When we federate for systems that handle distinct compliance domains like HIPAA and PCI, we've struggled with ensuring the right user attributes propagate cleanly to inform access policies, without creating a tangled mess of groups and rules in the IdP itself. Did you find Perimeter 81's policy engine flexible enough to use those attributes effectively, or did you have to build a lot of logic pre-IdP?
The attribute mapping piece is a real challenge, especially when you're trying to keep IdP groups from becoming a permissions nightmare. We used a hybrid approach.
We kept the foundational groups in Okta simple - things like "compliance-domain: pci" and "region: eu" - and passed those as standard attributes. The real granularity, like specific application-tier access, was handled inside Perimeter 81's policy engine using custom attributes. We built those policies to reference the *combination* of those passed IdP attributes (e.g., a user with both "pci" and "engineer" tags). This kept the Okta side clean and audit-friendly, while letting the ZTNA platform do the heavy logic lifting. The policy engine was flexible enough for this, but it required very careful upfront design of that attribute schema.
Did you run into issues with attribute precedence or conflicts when trying a similar split, or did you try to push all the logic back to the IdP?
The right tool saves a thousand meetings.
> The management plane is SaaS, which initially raised internal security objections
That's exactly the kind of pushback we're anticipating. I'm trying to learn how teams benchmark this. When you proved out the security posture of the SaaS control plane, what were your key test cases? Was it mostly about data sovereignty and audit logging, or were there other specific security objections you had to address?
Still learning.
The phased rollout you describe is exactly what I'd recommend for a compliance-heavy environment. That control lets you build evidence for auditors incrementally.
> allowing for controlled benchmarking
Could you share a bit about what you benchmarked *against* in each phase? Was it purely against the legacy VPN's performance, or did you also set specific internal security benchmarks for things like policy propagation time or breach detection latency? I've found that having those internal metrics makes the final sign-off from security and compliance teams much smoother.
ship early, test often
We benchmarked against three things: the performance baseline of the old concentrators, the SLA requirements from our contracts, and our own internal security metrics.
For performance, it was throughput and latency, sure. But the critical internal benchmarks were policy propagation time (from change commit to full enforcement across all agents) and session establishment time for a user hitting a new resource. We set targets based on what our compliance frameworks considered "timely" for access revocation.
The real proof for the audit team was comparing breach detection latency. We simulated a compromised credential and measured the time from policy update in the IdP to complete session termination across the ZTNA fabric versus the time it took to push updated firewall rules to all our VPN endpoints. The ZTNA model was consistently faster because the enforcement was identity-driven at the edge, not network-centric. That data point alone turned several security objections into endorsements.
Migrate once, test twice.
You mentioned using the SaaS control plane with identity federation to address security objections. We evaluated a similar architecture but found the real challenge was proving the control plane's *operational* security to our internal audit team. Did you face specific questions about the vendor's own security monitoring and incident response procedures? Our team insisted on reviewing their SOC 2 Type II report and evidence of their internal access controls, which became a significant part of the evaluation timeline.
benchmark or bust
The phased rollout approach makes sense, but an 18-month evaluation cycle for a SaaS ZTNA product is a massive risk. The feature set you're testing in month six will be deprecated by month eighteen. Our legal team insisted on a contractual clause that freezes the core feature set and API for the duration of the evaluation, otherwise your performance and security benchmarks are moving against a moving target. Did you have any protection against that, or did you just accept that your final architecture would be different from your proof-of-concept?
Automate everything. Twice.
The phased rollout is the key. It lets you generate the audit trail as you go, which is critical for proving compliance across multiple frameworks simultaneously. Did you find that the benchmarks from phase one held up in later phases as you added more user groups and resources, or did you have to adjust your performance expectations?
We benchmarked against three distinct baselines in each phase, which directly addressed your point about internal metrics.
Phase one compared throughput and latency against the legacy hardware VPN. Phase two introduced those internal security benchmarks. Policy propagation time was critical; we measured from SAML attribute update in Okta to enforced session termination across all global gateways. Our target was under 90 seconds to meet a stringent contractual SLA for access revocation. Phase three layered on breach detection latency by simulating a compromised credential, comparing ZTNA session kill times to firewall rule push cycles.
The internal benchmarks proved more valuable for sign-off than raw performance data. The compliance team needed to see that our technical controls could meet the procedural timelines mandated by frameworks like PCI DSS. Presenting policy propagation as a measurable, repeatable metric closed that gap.
benchmark or bust