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
You're spot on about the admin interface being a big step up from Cisco's. That initial relief is real!
>The hidden cost of re-engineering all your access policies
This is the killer. It's not just the policies themselves, it's the stakeholder meetings to define them. We got bogged down for weeks debating access levels for "temporary contractors from partner X." Phasing the rollout, like user1142 mentioned, is the only way to keep sanity.
Has your team looked at any external logging or monitoring to get around the useless client logs? We had some luck piping traffic from problem Macs into a separate analyzer, which at least showed the drops weren't on our end.
null
Your breakdown of the true cost mirrors our audit findings. The licensing ballooning with IoT devices is a classic example of a "consumption adjacency" fee that isn't transparent in the initial sales cycle. We observed the same pattern where non-human endpoints were rolled into per-user licensing, effectively doubling our projected spend.
I'd extend your point on exit strategy. The policy logic lock-in creates a significant hidden cost often missed in TCO models: the labor valuation of the engineering time spent building those rules. When we calculated the fully loaded cost of that engineer's salary, benefits, and overhead across the months of policy rebuild, it exceeded the three-year licensing delta between Appgate and AnyConnect. The sunk cost isn't just in configuration, it's in institutional knowledge that becomes a barrier to exit.
Always check the data transfer costs.
Phasing the rollout is such a smart move, and your point about avoiding project stall is spot on. I've seen teams get stuck in a "perfect policy" loop for months, trying to account for every edge case from day one.
On the network switching issue, we observed a similar correlation, especially with Macs using USB-C Ethernet adapters. The client didn't seem to handle the rapid interface metric change gracefully. Our workaround was a script to delay the VPN service restart on network change, which reduced but didn't eliminate the drops. It definitely points to a deeper client stack issue, doesn't it?
Architect first, buy later
Exactly. The lock-in is the real cost. That "nice" admin interface is just a prettier cage. You aren't just buying a VPN, you're buying a new language for your access policies that only they speak. Try exporting those granular rules to anything else. You can't. It's a boat anchor disguised as a feature.
You think Cisco support is a racket? Wait until your first Appgate renewal when they know you've burned six months of engineering time building their custom logic.
If it ain't broke, don't 'upgrade' it.