Switched from Palo Alto GlobalProtect to Netskope, here is why (and the one big regret).

After nearly a decade of standardizing our perimeter security on Palo Alto Networks, specifically leveraging GlobalProtect for all remote access, our recent enterprise-wide migration to Netskope's ZTNA platform was a decision born of both necessity and architectural evolution. The primary catalysts were the escalating complexity and cost of maintaining site-to-site VPNs for a distributed workforce and the need for a more granular, application-centric security model that aligns with our zero-trust initiative. This post details the technical and operational rationale behind the switch, a candid cost-benefit analysis, and the significant architectural trade-off we now contend with.

The migration was driven by several key technical advantages we observed in Netskope:

* **Context-Aware Access Policies:** Moving beyond simple network-layer allow/deny. We now enforce policies based on user, device posture (via CrowdStrike integration), and application sensitivity. A Terraform snippet for a basic policy illustrates the declarative nature:
```hcl
resource "netskope_access_policy" "engineering_critical_app" {
name = "Eng-Prod-K8s-API"
description = "Restrict prod cluster access to compliant engineering devices."
action = "allow"
users = ["group:engineering"]
applications {
application = "k8s-prod-api.company.com"
}
devices {
criteria = "posture.status"
operator = "equals"
value = "compliant"
}
}
```
* **Elimination of the Network Perimeter:** GlobalProtect essentially extended our corporate network. Netskope's direct-to-app model, leveraging its private access connectors deployed in our AWS VPCs, has drastically reduced our attack surface. We no longer have persistent network pathways from remote laptops into core subnets.
* **Unified Client & Reduced Overhead:** The consolidation of a separate VPN client and a legacy SWG into the single Netskope client was a major operational win. User support tickets related to client conflicts have dropped approximately 40%.
* **Cost Transparency and Shift:** The Palo Alto model, with its requirement for large VM-Series firewalls at each egress point for traffic inspection, carried immense compute and licensing costs. Netskope's cloud-native service transformed this from a capital expenditure to a more predictable operational one. Our preliminary analysis shows a 22-28% annual cost saving when factoring in reduced Azure/AWS egress costs (from less hair-pinning) and retired firewall instances.

However, the transition has not been without a profound compromise: **the loss of deep, inline network-level inspection and threat prevention for all traffic.** With GlobalProtect, all user traffic was forced through our PAN-URL filtering and Threat Prevention pipelines. Netskope's ZTNA, by design, only proxies and secures the connections to *enrolled applications*. General web browsing, unless also routed through Netskope's SSE for CASB/DLP, occurs outside its security stack. We mitigated this by enforcing a strict "always-on" tunnel for the Netskope client with a fallback to a deny-all rule, but it represents a philosophical shift from "inspect everything" to "secure the access path to known assets." This has required a parallel strengthening of our endpoint security posture and user education, which is an ongoing effort.

My primary regret is underestimating the cultural and process inertia around change management for network troubleshooting. The security and cloud teams championed the move, but the network operations team lost visibility they considered essential. Tools and dashboards built around seeing IP flow logs from the VPN concentrator are now blind to ZTNA connections. We are having to rebuild our observability stack around Netskope's APIs and logs, integrating them into our existing Grafana and SIEM systems, which has added a non-trivial project overhead we did not fully budget for. The architectural elegance of zero-trust comes with a requirement to reinvent your operational playbooks.