We've been running Netskope's ZTNA stack in our production environment for approximately 18 months, managing access for a user base of ~2,300 across multiple global offices and a significant remote workforce. The migration was part of a broader zero-trust initiative to move away from a legacy VPN-centric model. My team's purview is the backend platform and developer experience, so our lens is heavily on API stability, integration patterns, and operational overhead.
The implementation has been largely successful from a security posture standpoint, but the journey has been architecturally nuanced. The core strength is its tight integration with the broader Netskope SSE platform (SWG, CASB). However, the ZTNA component, particularly the private app access via the Netskope Client, introduced several considerations we didn't fully anticipate during the PoC.
Key observations from an infrastructure perspective:
* **Agent-Based Model Nuances:** The reliance on the Netskope Client as the "gatekeeper" for all private app traffic means it becomes a critical performance path. We've had to profile its impact on developer workstations, particularly around:
* TCP connection handling for applications that open numerous concurrent connections (e.g., certain CI/CD tools, internal monitoring dashboards).
* Resource utilization during large data transfers to/from internal data lakes, where the TLS inspection and re-routing overhead becomes measurable.
* **API and Automation Gaps:** While APIs exist, we found the automation for policy lifecycle management (especially for dynamic groups based on our internal IAM) to be less mature than we hoped. We built several internal orchestration tools to bridge this. For example, syncing non-HR system-of-record attributes into Netskope required a custom service.
```go
// Simplified example of our sync service logic
func syncEntitlementToNetskope(user User, app AppResource) error {
// Internal IAM check
if !user.HasAccess(app.IAMRole) {
return revokeNetskopePolicy(user.ID, app.PolicyID)
}
// Netskope API call to ensure policy assignment
policy := NetskopePolicy{
UserID: user.NetskopeExternalID,
AppID: app.NetskopeAppID,
Action: "allow",
Context: []string{user.Department},
}
return nsClient.UpdatePolicy(policy)
}
```
* **Latency and Geo-Routing:** Our private applications are hosted across AWS and on-prem data centers. The Netskope POP steering for private app traffic sometimes created suboptimal routing, adding 30-50ms of latency for certain regional users accessing apps in a geographically close data center. This required careful configuration of "direct" vs. "gateway" traffic rules and close collaboration with their support to adjust routing logic.
The transition did achieve our primary security goals: eliminating VPN attack surface, enforcing device posture checks, and providing application-level access. However, the operational complexity resides not in the day-to-day user access, but in the plumbing—integrating with our service mesh, managing exceptions for legacy protocols that aren't HTTP-based, and the continuous tuning of performance policies.
I'm particularly interested in hearing from others at a similar scale about your experience with the operational data plane. Have you measured the performance overhead of the client in a quantifiable way? How are you handling service-to-service communication in a hybrid model where some services are behind ZTNA and others are not?
Latency is the enemy