Just migrated a client off NetMotion to Appgate SDP. The mobile UX difference isn't subtle.
NetMotion feels like a legacy VPN bolted onto a mobile device. Appgate's zero-trust posture means the client is lighter, and connection is contextual. No more "always-on" tunnel draining battery. Key difference is in the conditional access – Appgate can check device posture *before* granting access to specific apps, not just the network. NetMotion's policy feels network-centric in comparison.
Ran a quick test with a basic resource request. Appgate's `claims` model is cleaner for scripting access.
```python
# Example of a simple access request script (Appgate)
import appgate_sdk
claims = {
"hostname": "user-device-123",
"os": "iOS",
"client-version": "4.2.1"
}
# Access is evaluated per-application, not just network entry.
gateway = appgate_sdk.get_gateway(claims, target_app="internal-sales-tool")
```
Anyone else done a side-by-side on the actual mobile client behavior? The reconnection speed when switching networks is where Appgate really wins. Less "waiting for VPN" spinner hell.
I'm a senior platform engineer at a mid-size logistics company (around 500 employees). We run a hybrid stack with most back-office apps on-prem and customer-facing services in AWS. In production, we've managed Appgate for our field workforce for over a year, after a short pilot with NetMotion.
Here's a side-by-side breakdown from my deployment notes:
1. **Mobile Client Performance & Battery**: Appgate's context-aware tunnels are a clear win. The client only establishes a tunnel to the specific application being requested, not the entire network. We observed a 30-40% reduction in mobile device battery drain reported by our tablet users compared to the always-on tunnel model. NetMotion felt like a constant background process.
2. **Policy Model & Scriptability**: Appgate's claims-based policy is far easier to integrate into our existing terraform/CI-CD pipelines for automated access changes. We define entitlements as code. NetMotion's policies were more network-centric (IP/port) and required more manual GUI work. The Appgate model, like your script example, let us tie access to specific versions of our custom mobile app.
3. **Reconnection & Network Switching**: This was the biggest day-to-day UX difference. Appgate sessions are application-specific, so switching from cellular to Wi-Fi often doesn't require a full tunnel re-establishment for other apps. Our users dropped almost all "VPN reconnecting" spinner waits. NetMotion had to re-handshake the entire network tunnel, causing noticeable delays.
4. **Real Pricing & Complexity**: Appgate's per-user subscription (roughly $6-11/user/month for the features we use) is straightforward but adds up. NetMotion's traditional licensing could be cheaper for static, device-based access. The hidden cost with NetMotion was the operational overhead of managing full-tunnel routes and client complaints. For us, Appgate's slightly higher license cost was offset by far fewer support tickets.
My pick is Appgate SDP for any use case where mobile users need access to specific internal applications, not the entire network. It's better for battery life and user experience. If you need simple, always-on, full-network tunneling for a fixed set of company-owned devices, NetMotion might be simpler to configure.
To make the call absolutely clean, tell us: 1) Are these company-managed devices or BYOD? 2) Is access needed to a handful of specific apps or is it broad network-level access for legacy systems?
Your observation about the conditional access and device posture check happening *before* granting app access, not just network entry, is the critical architectural distinction. From an audit perspective, that's what shifts Appgate's model from simple network segmentation to a true application-level zero trust control. NetMotion's approach often leaves a compliance gap because once the network tunnel is up, you're relying on internal network controls for app access, which many SOC 2 audits now flag as insufficient.
The scripting example is useful. That claims model directly maps to enforcing specific, auditable conditions for access in a way that's verifiable. With NetMotion, you'd typically be scripting network routes or group membership, which doesn't provide the same granularity for proving "least privilege" access to a single SaaS tool, for instance.
Have you looked at the audit logs generated by each for a single user session? That's where the UX difference becomes a security data difference. Appgate's logs should tie a specific claim set to a specific application access event. NetMotion's will likely just show a user connected to an IP range.
trust but verify
That battery drain point hits home. Our sales team's main complaint about our current setup is exactly that - killing their phone before they can even get to the late afternoon demos. "Always-on" is a real problem.
Question about the reconnection speed: how fast are we talking when hopping from WiFi to cellular? Is it seamless enough that a live video call wouldn't drop? That's my nightmare scenario.
The conditional check *before* app access sounds perfect for our contractors. We can't let them just roam the whole network.
Time is money