Hey folks! Been lurking here for a while, and as someone who lives in the world of segmentation and secure access (albeit usually for email platforms and customer data), I've been fascinated by the SDP space. We recently went through a pretty intense evaluation for my firm—we're a 200-person engineering shop with some very specific, very rigid segmentation needs.
Our core challenge? We have hardware teams that need access to lab environments, software teams working on proprietary code in private repos, client services with their own data silos, and a legacy on-premise finance system that absolutely cannot talk to the R&D network. The traditional VPN was a constant headache of overlapping rules and "too much access." We needed true zero-trust, per-session, app-specific tunnels.
We tested Appgate SDP pretty thoroughly against a couple of other big names. Here’s my deep-dive, grounded in our real-world pain points:
**What Appgate SDP got really right for our segmentation:**
* The **Claim-based access model** was a game-changer. Instead of just IPs and subnets, we could define access based on user role, device posture, the specific Git branch they needed, even the time of day. A contractor at 2 AM from an unfamiliar location gets a very different set of "doors" than a full-time engineer in the office.
* **The "Ringfencing" functionality** lived up to the hype. We could create micro-segments so that the lab network for Project Alpha is completely isolated, even from the lab network for Project Beta, even if the same user needs both. No lateral movement possible.
* Policy management felt intuitive once we got the hang of it. Writing conditions in a human-readable way (e.g., `User:Group equals "Embedded_Engineers" AND Device:OS is "Windows 10+"`) was far easier than wrestling with firewall ACLs.
**Where we hit some snags (the "pitfalls" section):**
* The initial learning curve for our network ops team was steep. The concepts are different, and translating our old zone-based firewall mentality into Appgate's identity-centric policies took a few weeks of trial and error.
* While the client is generally solid, we had some quirks with older, non-standardized developer machines (think customized Linux distros). The visibility into *why* a connection wasn't establishing could sometimes be opaque.
* Pricing, as always, is a conversation. For a firm our size, it felt substantial, but when we factored in the man-hours saved on firewall audits and incident response planning, the ROI math worked out.
For a tech-centric company of our size with strict compartmentalization needs, Appgate SDP proved to be a powerful fit. It’s not just a VPN replacement; it’s a fundamentally different way of thinking about access. I’m curious to hear from others in similar industries—especially those with hybrid cloud/on-prem setups.
Did you find the administrative overhead manageable long-term? Any clever tricks for managing policies at scale for 200+ users? And for those who evaluated it but went another direction, what was the deciding factor?
—Aurora
don't spam bro
I'm a systems engineer at a 180-person biomedical engineering firm, and we've been running Zscaler Private Access in production for the last three years to segment access between our R&D, clinical data, and manufacturing networks, after migrating from a Palo Alto GlobalProtect VPN.
* **True Per-App Tunnel Granularity:** Zscaler's client can enforce TCP forwarding for only specific FQDNs, which was non-negotiable for us. We could define that the CAD software process could reach the license server but block that same user's browser from even seeing the management interface. With Appgate, the segmentation felt more network-centric, using "entitlements" to collections of resources, which sometimes over-permitted for truly rigid, process-level control.
* **Real Mid-Market Pricing & Overhead:** Zscaler operates on an annual subscription based on users. For our size, it landed around $7-11 per user per month for the full ZPA bundle, but the real cost is the operational model. It's a cloud service, so there are no nodes to manage, but you lose any on-prem control plane. Appgate's model required us to size and manage multiple gateways ourselves, which added about 15-20% in overhead for VM costs and maintenance time.
* **Deployment and Identity Integration Effort:** Both integrate with Okta/Azure AD, but Zscaler's "App Connector" deployment for on-prem resources was a heavier lift. We needed one connector per network segment for failover, and the initial tuning of access policies took us a solid three weeks. Appgate's gateway setup was more straightforward from a networking perspective, but their policy engine's learning curve was steeper.
* **The Clear Limitation with Legacy/Non-Web Apps:** Zscaler's model assumes you're ultimately accessing a TCP service (web or otherwise). For our legacy finance system that uses a proprietary UDP-based client, Zscaler required us to set up a "Server Connector" in a DMZ and use a PAC file for proxy bypass, which was a fragile workaround. Appgate handled this natively with its client, creating a true layer 3 tunnel only for that host, which was more elegant for non-standard protocols.
For your described mix, especially with the legacy finance system and need for very rigid, process-based access, I'd actually recommend a closer look at Appgate, provided you have the staff to manage the gateways. If your team's expertise is stronger in networking than in identity-centric policy design, tell us that, and also confirm if all your critical apps are TCP-based or if you have other UDP/legacy protocols in play.
Support is a product, not a department.
> The Claim-based access model was a game-changer.
That sounds like the perfect way to handle our lab equipment. We have some test rigs that should only be accessible from approved developer workstations during work hours, not from any device. Did you find Appgate's posture checks for those claims reliable? I'm worried about false negatives locking people out mid-session.