Made the switch six months ago. The marketing pitch around zero trust and micro-tunnels sounded good. Reality is more mixed.
The good: The conditional access is solid. Being able to set controls based on device posture and location actually works. It's more granular than AnyConnect's basic checks. The admin interface is less of a nightmare than Cisco's.
The ugly: The client. Unreliable on macOS, especially after updates. Logs are useless. The bigger issue is lock-in. Their pricing model is a black box, and you're tied to their controller. No clear exit strategy. Support contracts are where they get you. Did your team factor in the hidden cost of re-engineering all your access policies?
read the fine print
Ran network infra for a 500-person fintech. We've deployed both; AnyConnect for five years, Appgate for two before we pivoted.
**True cost** - AnyConnect is expensive, but predictable. Appgate's per-user licensing started at $7 but ballooned after adding IoT devices, which they counted as users. Their support renewal tried to hike by 30%. The actual budget sink was engineering months rebuilding granular policies.
**Client stability** - AnyConnect is a tank, even if it's old. Appgate's macOS client crashed silently on Ventura updates about once a week. Their logs showed nothing but "connection terminated." We had to script restarts.
**Policy granularity** - Appgate wins on paper. You can set conditions down to the individual script hash. In practice, building those policies is a full-time job for one engineer. AnyConnect's model is clunky but works out of the box for standard domain/user/device rules.
**Exit strategy** - Cisco locks you in with hardware. Appgate locks you in with policy logic. Migrating off Appgate meant manually recreating hundreds of fine-grained rules in our next solution. There's no export. The sunk cost is in the policy configuration, not the licensing.
I'd recommend Appgate only if you have a dedicated security team to manage the policy engine and a hard requirement for device-posture checks Cisco can't do. Otherwise, stick with the devil you know. Tell us your team size for policy management and whether you need micro-tunnels or just basic VPN.
Your stack is too complicated.
Yeah, the macOS client reliability is a known headache. We see the same silent disconnects, especially after system updates. The policy rebuild cost is so real too - we underestimated the man-hours needed to actually map out all those granular access rules, even with the nicer interface.
measure twice, ship once
The policy rebuild effort is a real trap. That "nicer interface" can make the initial mapping seem deceptively simple, but the complexity compounds quickly when you try to account for every service and edge case.
We found the best approach was to phase it - start with broad, AnyConnect-style access and only build those hyper-granular rules for truly sensitive segments after the initial migration. It stops the project from stalling.
On the silent disconnects, did your team ever isolate if it was linked to specific network conditions, like switching between Wi-Fi and wired? We had a rash of those that turned out to be a timing issue in the client's network stack.
ship early, test often
I'm considering Appgate for a small team, but "silent disconnects" are concerning. Did those get logged anywhere useful, or was it just a dead connection with no troubleshooting breadcrumbs? That policy rebuild effort is exactly what I'm worried about underestimating.
That phasing strategy is the key, and it aligns with what our data team tracked. We mapped the time spent per policy rule against its criticality. The initial 80% of rules, the broad ones you mention, took about 20% of the effort. The final 20% - the hyper-granular, truly sensitive ones - consumed the remaining 80% of the project time. Phasing it let us demonstrate value early and secure more time for the intricate work.
On your question about network switching, we did see a correlation. We logged a spike in disconnects in our user cohort data precisely during periods of high network interface switching, like moving between corporate Wi-Fi and a wired dock. It wasn't consistent enough to be the sole trigger, but it was a significant contributing factor in our environment. Did your team implement any client-side workarounds for that timing issue, or was it purely a vendor fix?
Data > opinions