The promise of Zero Trust Network Access is clear, but the reality of applying it to a massive, complex enterprise with a significant legacy on-prem footprint is where the rubber meets the road. Many solutions are built for greenfield SaaS or cloud-native apps. My team was tasked with evaluating ZTNA vendors, specifically for their ability to handle our 15-year-old Java monoliths, internal databases, and mainframe terminals, all without a full network overhaul. We needed a solution that could layer modern identity-centric access over our existing network-centric infrastructure.
Netskope's ZTNA stood out because it didn't require us to forklift our data center. The Private Access model, using lightweight Clientless and Client-based options, was key. For our legacy apps, the architecture looked like this:
1. **Clientless for contractor/third-party access:** For our legacy web apps (some still using TLS 1.0), we could publish them via a secure browser session without installing an agent on the user's device. This was crucial for compliance and vendor access.
```yaml
# Simplified example of an app definition for a legacy HR system
application:
name: "legacy-hr-portal"
internal_url: "https://hr-app.internal.corp:8443"
published_host: "hr.company.ztna.net"
authentication:
type: "SAML"
idp: "AzureAD"
policies:
- users: "contractors"
action: "allow"
features: ["clipboard-disabled", "print-disabled"]
```
2. **Client-based for internal employees:** The Secure Client (which also handles SWG and CASB) provided TCP forwarding for non-web protocols. This allowed our developers to securely reach internal databases (e.g., PostgreSQL, Oracle) and SSH servers as if they were on the local network, without a traditional VPN's broad network permissions.
**Performance and the "Tunnel-Lite" factor:** The benchmark that mattered most was latency on the legacy apps. Netskope's "Tunnel-Lite" (their term for the proxied, session-oriented connection) showed a 5-15ms overhead versus a full tunnel VPN, which was acceptable. The bigger win was in access revocation speed and session-level logging, which our audit team required.
**The pitfalls we encountered:**
* **Application profiling:** Netskope's system automatically profiles apps to suggest policies. For our truly ancient, custom-built apps, this failed. We had to manually define the traffic patterns and allowed origins/destinations.
* **Client deployment:** Rolling out the Secure Client to 50,000+ global employees was a project in itself, integrated with our existing MDM. The clientless option mitigated this for non-employees.
* **Cost model:** The per-user, per-month pricing scales linearly. For a Fortune 500, this becomes a significant line item, and you must ensure you're maximizing the value from the full Secure Access Service Edge (SASE) suite to justify it.
In conclusion, for a legacy-heavy environment, Netskope ZTNA worked because it offered a graduated path. We didn't have to re-architect everything on day one. We could start with clientless access for the most critical legacy apps, then roll out the client for internal users, all while building granular, identity-aware policies to replace our old network-level VLANs and ACLs.
benchmark or bust
benchmark or bust
The clientless approach for legacy web apps is a critical feature that doesn't get enough discussion. Its true value isn't just about avoiding an agent install; it's about sidestepping incompatible or unsupported client operating systems. We've had third-party contractors still running Windows 7 machines for specific legacy toolchains, and a client-based ZTNA solution would have been a non-starter.
However, I'd be curious about the latency implications you observed for interactive mainframe terminal sessions (like TN3270) routed through that secure browser channel. In our POC with a different vendor, the added render-before-display overhead introduced perceptible lag for data-entry staff. Did Netskope's implementation handle that any differently, perhaps with a protocol-specific optimization?
API whisperer