I’ve been looking into Zero Trust solutions for our small team, and Perimeter 81 keeps coming up. Their marketing talks a lot about zero trust network access, but from what I can see, it looks like they're mainly providing a managed VPN with some extra access controls.
I’m trying to understand what truly makes it different from a traditional VPN with good firewall rules. Is the "zero trust" label mostly a branding thing, or does their implementation actually change how users and devices are verified? For example, does it go beyond just requiring a login to connect?
You've hit on a key distinction. A traditional VPN, even with strong authentication, typically grants access to a network segment. Zero trust shifts the unit of access to the application or service itself.
With a true zero trust model, the login is just the first step. Every request is evaluated against policies that consider identity, device posture, location, and other context. The connection isn't a persistent tunnel to a network; it's a continuously verified, least-privilege pathway to a specific resource.
So for Perimeter 81, the question is whether they're doing that granular, per-request authorization or just providing a more secure on-ramp to a trusted subnet. The marketing is often ambiguous.
Commit early, deploy often, but always rollback-ready.
Good luck figuring that out from their marketing. It's all the same buzzword salad.
If they're just checking a login and dropping you into a subnet, it's a VPN with a fancy dashboard. The real difference is if they verify every request, not just the initial connection. Most of these tools don't.
Ask them if the auth token is re-evaluated for each HTTP call, or just to establish the tunnel. That'll tell you what you're actually buying.
-- old school
Spot on about checking the auth token. Many "zero trust" gateways just do an initial OAuth flow and then issue a session cookie or a long-lived JWT. That's essentially a VPN handshake with a different protocol.
For a true per-request check, you'd need something like a sidecar proxy that calls out to a policy decision point for *every* resource access, not just at tunnel setup. That's where the performance overhead kicks in, and most vendors shy away from it.
If their documentation only talks about "user-to-application" tunnels and doesn't mention continuous authorization loops, it's a strong signal they're just rebranding.
sub-100ms or bust
You're right that "auth token re-evaluated for each HTTP call" is the litmus test. I've seen this exact ambiguity in some data pipeline security layers too.
They'll advertise "zero trust data access," but it's really just a single auth at the start of a streaming session. If the user's permissions change mid-session, the old connection keeps all its access. That's not zero trust, it's a glorified, stateful firewall for your Kafka topics.
The performance overhead for true per-request checks is real, but sometimes it's just an engineering trade-off they didn't want to make.