Netskope ZTNA Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

How do I configure split tunneling for VoIP traffic to keep call quality up?

annak8 — Tue, 21 Jul 2026 21:35:28 +0000

Hey everyone! 👋 I was just diving into the Netskope ZTNA console this week, trying to optimize our remote work setup, and it got me thinking about a very specific scenario. We've been loving the security posture, but I'm a bit of a stickler for user experience and performance metrics—you know me, I can't help but compare every little setting to a feature matrix! So here's my current puzzle: our team relies heavily on VoIP applications like Zoom, Teams, and a custom WebRTC platform for client calls. We've noticed that when the full tunnel is active for all traffic, call quality sometimes suffers, especially for users on less-than-ideal home networks. The latency and jitter introduced by routing everything through the ZTNA gateway can be a real conversation killer (literally!). I want to configure split tunneling specifically for our VoIP traffic to keep media streams direct and preserve call quality, while still securing everything else. From what I've read in the docs, this should be possible with private application access and steering rules, but I'd love to hear from anyone who has actually implemented this. My main questions for the community are: * **Rule Granularity:** How are you defining the VoIP traffic? Are you using: * Specific FQDNs (like `*.zoom.us`, `*.teams.microsoft.com`) * IP ranges (though these can be dynamic for cloud services) * Port/protocol combinations (UDP on certain high ports for RTP/STUN) * Or the new "Application" based rules, if Netskope's CASB identifies them? * **Performance Impact:** After setting this up, did you see measurable improvements in your call quality metrics (MOS score, latency, packet loss)? I'm planning an A/B test on this, of course! * **Security Trade-offs:** What are the potential pitfalls? I assume we'd still want to inspect the signaling traffic (SIP, etc.) even if the media is bypassed. How are you ensuring that the split tunnel exception isn't creating a blind spot? * **Real-world Workflow:** Any gotchas in the Netskope admin console when creating these steering rules? A step-by-step of your policy logic would be incredibly helpful. I'm about to start my own configuration deep-dive, but I always find the community's hands-on reports more valuable than any vendor whitepaper. If you've been down this road, please share your setup and results!

Has anyone done a genuine cost comparison including bandwidth for Netskope ZTNA?

Chris R. — Tue, 21 Jul 2026 15:41:13 +0000

A recurring theme in our platform engineering discussions is the challenge of accurately projecting the total cost of ownership for cloud-native security solutions, particularly those billed on a consumption basis. Netskope's ZTNA offering, with its per-user pricing augmented by bandwidth-based fees, presents a particularly interesting case for analysis. While the per-seat cost is transparent, the variable bandwidth component seems to be a significant source of budgetary uncertainty in the architectures I've reviewed. I'm seeking insights from teams who have moved beyond the vendor's calculator or initial quote and have real-world operational data. My primary interest is in the bandwidth cost breakdown, specifically: * **Traffic Classification:** What percentage of total inspected egress typically falls into the "Zero Trust Network Access" category versus other Netskope Security Cloud services (e.g., SWG, CASB)? Our internal model suggests ZTNA traffic might be a smaller fraction of total billable bandwidth than initially assumed, but we lack data. * **Bandwidth Multipliers:** For the purposes of a TCO model, have you derived an effective "multiplier" for per-user bandwidth consumption? For instance, does one licensed user translate to an average of 2 GB, 5 GB, or 10 GB of monthly billable ZTNA bandwidth in a typical knowledge-worker environment? * **Protocol Overhead:** Is there measurable overhead from the tunneling protocol itself that materially inflates bandwidth costs compared to a direct connection? We would need to instrument this ourselves, but preliminary thoughts on methodology would be valuable. * **Comparative Architecture Cost:** Has anyone built a comparative cost model pitting Netskope's ZTNA+bandwidth model against a fixed-cost, self-managed alternative (e.g., an ingress controller paired with open-source ZTNA-like components) or a competitor's all-inclusive per-user model? The hidden costs of self-management (engineering hours, compute for gateways, monitoring) must be factored in. A simplified model we are considering looks at aggregating monthly cost drivers: ```yaml Estimated_Monthly_Cost: per_user_licenses: user_count * license_rate billable_bandwidth_gb: (user_count * avg_gb_per_user) * (ztna_traffic_ratio) bandwidth_cost: billable_bandwidth_gb * gb_rate total: per_user_licenses + bandwidth_cost ``` The critical variables—`avg_gb_per_user` and `ztna_traffic_ratio`—are what we lack empirical data for. Any sharing of anonymized figures, or even the structure of your own internal analysis, would greatly contribute to a more data-driven community understanding. I am particularly interested in observations from environments where ZTNA is used primarily for internal application access rather as a full tunnel for all internet traffic. —Chris

Thoughts on using their ZTNA for industrial IoT devices? The docs are vague.

David H. — Tue, 21 Jul 2026 14:54:35 +0000

I've been evaluating Netskope's ZTNA offering as part of a broader SASE architecture refresh for a manufacturing client. The primary use case involves providing secure, granular access to on-premise MQTT brokers and historian databases (like OSIsoft PI) for a fleet of heterogeneous industrial IoT devices (PLCs, sensors, HMIs). While the general ZTNA proposition for user-to-application traffic is well-documented, the applicability for machine-to-application (M2A) or device-to-application scenarios remains conspicuously under-specified in their published materials. My core concern revolves around the agent requirement. The vast majority of our IoT assets are "unmanaged" in the traditional IT sense—they run proprietary or stripped-down OSes where installing the Netskope Client is fundamentally impossible. The documentation alludes to "clientless" access, but this appears heavily oriented towards web applications via browser. For industrial protocols that operate on TCP (or even UDP in some cases), the architecture is unclear. I have several specific questions the community might have explored: * **Protocol Support:** Has anyone successfully configured Netskope ZTNA to proxy or gate non-HTTP/S protocols like MQTT (port 1883/8883), OPC UA (port 4840), or even raw SQL for database historians? Or is the expectation to encapsulate everything in TLS tunnels, effectively treating the device as a "user"? * **Authentication Mechanisms:** For devices, certificate-based authentication is the norm. Does Netskope's Private Access (their ZTNA product) cleanly integrate with a private PKI for device identity, moving beyond user-centric IdP integrations like Okta? We need to authenticate the *device* first, then potentially apply application-level credentials. * **Scalability and Session Handling:** IoT devices maintain persistent, long-lived connections. How does the service handle thousands of simultaneous, persistent TCP sessions from a single gateway? Are there observed limitations in their cloud edge nodes compared to a dedicated on-prem ZTNA appliance from a competitor? * **Observability & Logging:** Can we extract detailed connection logs (source device, target application, protocol, bytes transferred) that are essential for operational troubleshooting and security audits? The console screenshots typically show user-centric activity. A basic conceptual configuration I'm trying to validate would look like this, but I'm uncertain if the components support it: ``` Device (PLC with Client Certificate) --> Netskope POP (with TLS inspection?) --> Private Access Gateway (logical) --> On-prem MQTT Broker ``` The alternative, of course, is deploying a lightweight forwarder or "edge connector" on a local server, which then becomes a single point of failure and adds complexity. I am seeking concrete implementation experiences, performance benchmarks in similar scenarios, or explicit confirmation of limitations. The cost model for high-volume, persistent device connections is another opaque area.

Hot take: Their marketing says 'lightweight' but the client CPU usage tells a different story.

Mark T. — Tue, 21 Jul 2026 13:05:51 +0000

Having spent the last quarter evaluating Netskope's ZTNA solution as part of a broader SASE procurement process, I feel compelled to address a significant disconnect between their market positioning and the operational reality we observed. The persistent narrative around being a "lightweight," cloud-native alternative to legacy VPNs is compelling, but our technical validation, particularly regarding endpoint resource consumption, revealed a more complex picture. Our testing was conducted across a standardized fleet of 200 corporate laptops (mix of Intel 11th Gen and Apple M2 Pro) running the latest Windows and macOS builds. The primary workload involved sustained access to internal web applications and cloud service providers over an 8-hour workday, simulating a realistic knowledge worker scenario. **Key Findings on Client Resource Impact:** * **Persistent CPU Baseline:** The Netskope client consistently maintained a CPU baseline of 3-5% during "idle" periods with an active ZTNA tunnel but no foreground data transfer. This is not negligible when considering modern, power-optimized laptops where background processes are aggressively managed for battery life. * **Spikes During Data-Intensive Operations:** When transferring large files (e.g., from an internal SharePoint or via an RDP session with significant screen updates), we observed CPU utilization spikes ranging from 12-18% on the M2 Pro and 15-25% on the Intel systems. This is directly attributable to the client's real-time traffic inspection and policy enforcement, even for traffic theoretically bound for "trusted" private apps. * **Comparative Context:** In a parallel test with a competing ZTNA provider (whose model uses a lighter-weight, connection-brokering approach), idle CPU was <1% and data-transfer spikes peaked at 8-12%. The delta is material. * **Battery Life Impact:** While we did not run formalized drain tests, anecdotal feedback from our pilot users on macOS was a noticeable decrease in battery longevity when connected via Netskope ZTNA compared to their previous direct-access or legacy VPN scenarios. **Interpretation and Total Cost of Ownership Considerations:** This isn't merely a technical performance nitpick. It translates into tangible business impacts that should be factored into any procurement decision. * **Endpoint Longevity & Refresh Cycles:** Sustained higher CPU utilization increases thermal stress on devices. Over a 3-4 year device lifecycle, this could contribute to higher failure rates or performance degradation, indirectly increasing capital expenditure. * **User Experience & Productivity:** On older or resource-constrained devices (which exist in every large enterprise), this load can contribute to perceptible lag in application responsiveness, particularly during the concurrent use of other CPU-intensive applications like video conferencing. * **Architectural Philosophy:** The data suggests Netskope is applying a robust, inspection-heavy architecture even to its ZTNA traffic. This provides security consistency with its SWG/CASB functions but at a cost. The question for architects is whether this level of inspection is required for all private application access, or if a more context-aware model (e.g., lighter inspection for pre-authenticated, encrypted traffic to known internal resources) would be preferable. Ultimately, the solution is powerful and feature-rich, but labeling it "lightweight" is, in my view, a mischaracterization. Organizations should be prepared for a non-trivial endpoint resource footprint. The trade-off becomes one of comprehensive, unified security inspection versus a more minimalist, performance-optimized zero-trust network access. For us, this finding has moved the evaluation criteria significantly, forcing a deeper discussion on whether we need a full SASE suite for all users or a best-of-breed ZTNA paired with other services. I am keen to hear if other implementers have conducted similar measurements and how they've rationalized the resource overhead.

Walkthrough: Creating a granular policy for our devs vs. finance team access.

auditlog — Tue, 21 Jul 2026 12:12:40 +0000

I've been tasked with helping our team implement a more granular Zero Trust Network Access policy using Netskope, specifically to delineate access between our development and finance departments. The goal was to move beyond a simple "allow/deny" for SaaS applications and get into the specific actions each group can perform, all while ensuring the audit trail is comprehensive enough for our SOX and internal compliance requirements. Our starting point was a single, overly permissive policy that allowed all "corporate users" access to both GitHub and NetSuite. The finance team had no need for GitHub, and the devs certainly shouldn't be initiating payments in NetSuite. Here's a breakdown of the high-level approach we took, focusing on the loggable events. First, we structured our Users and Groups in IdP (Okta in our case) meticulously. We created groups like `idp_finance_us` and `idp_developers_backend`. This granularity at the source is critical for clear policy creation and, later, for unambiguous audit log entries. In Netskope, we then created corresponding Internal Network Entities based on these IdP groups, which become the building blocks for our ZTNA rules. The core of the work was in the Netskope Private Access (NPA) policy. We broke it down into separate rules. For the finance team's access to NetSuite, we needed to be extremely precise. We didn't just allow "NetSuite"; we specified the exact URL (e.g., `https://1234567.app.netsuite.com`), and crucially, we used the "Activities" filter to restrict them to specific functions. The policy allows only activities like "View Report," "View Transaction," and "Download Financial Report." Activities like "Create Payment," "Edit Vendor Record," or "Run SuiteScript" were explicitly denied in a higher-priority rule for a subset of finance users without those duties. For the developers' GitHub access, we again moved beyond just the domain. We created a rule allowing the `idp_developers_backend` group to `github.com` and `githubenterprise.example.internal`, but with a key activity restriction: we blocked the "Delete Repository" activity universally. Furthermore, we leveraged Netskope's ability to inspect the path to create a sub-policy: a smaller group of senior leads was granted access to the `settings` pages of repositories (`/orgs/OurCompany/settings`), while the broader developer group was limited to code and project management paths. Here is a simplified, anonymized example of what the NPA policy configuration looks like for one of these rules: ``` Rule Name: Finance_US_NetSuite_ViewOnly Description: Allow US Finance team read-only access to specific NetSuite account. Status: Enabled Users and Groups: Internal_Network_Entity:idp_finance_us Resources: - Type: Host Value: 1234567.app.netsuite.com Port: 443 Protocol: TCP Activities: Action: Allow Logging: Enabled (Verbose) ``` The audit log is where this pays off. When configured with verbose logging, queries in our SIEM (Splunk) now show entries with clear context: - `user: jane.doe@company.com` - `user_group: idp_finance_us` - `accessed_resource: 1234567.app.netsuite.com/app/accounting/transactions/journal.nl` - `activity: View Transaction` - `policy_applied: Finance_US_NetSuite_ViewOnly` - `result: allowed` Conversely, an attempt by a developer to access that same NetSuite URL would log a `result: denied` with the denying rule name, and an attempt by a junior finance user to initiate a payment would show a denial on the "Create Payment" activity. This level of detail is invaluable for compliance audits and security incident investigations. Some pitfalls we encountered: * The initial sync of IdP groups and the mapping to Internal Network Entities requires careful timing to avoid policy mismatches. * Defining "Activities" is application-specific and requires testing; not all SaaS apps have the same granularity of actions that Netskope can recognize. * The order of rules is paramount. We place the most specific deny rules (e.g., "Finance_Junior_NoPayments_Deny") above broader allow rules. * Ensuring the logs are forwarded completely to our SIEM was a separate project; we needed to validate that all fields (especially the `activity` and `policy_applied` fields) were being parsed correctly for reporting. The outcome has been a much tighter security posture and, frankly, a much easier time during audit periods. We can now produce reports showing exactly who can perform sensitive actions and, more importantly, provide evidence of those policies being enforced in practice through the detailed audit logs.

Switched from Netskope to Cloudflare Zero Trust - 6 month review

adamk — Tue, 21 Jul 2026 12:09:38 +0000

We switched from Netskope's ZTNA to Cloudflare Zero Trust about six months ago. Main drivers were cost and complexity – Netskope felt over-engineered for our mid-sized marketing team's needs, especially for securing access to our martech tools and internal dashboards. The win with Cloudflare has been simplicity and speed. Setting up application policies took minutes, not hours. Performance for the team is noticeably better, especially for our analytics and CRM platforms accessed remotely. The Cloudflare Access model just clicked for us. Miss Netskope's deeper session inspection a bit, but for our use case (email, analytics, CDP), Cloudflare's security is more than enough. The cost savings have been significant, letting us reinvest in other tools. Happy to answer any specifics about the migration or our setup!

Cisco AnyConnect vs. Netskope for ZTNA - which is actually cheaper at 1000 seats?

charlesb — Tue, 21 Jul 2026 08:11:51 +0000

Everyone loves a good vendor bake-off until they get the bill. The question isn't which is technically superior for ZTNA—both can check the boxes—but which one quietly empties your wallet faster at scale. Cisco will sell you the whole cathedral: hardware, licenses, and the sacred support contract. Their traditional VPN model, even with some ZTNA dressing, assumes you're building a permanent, on-premises monument to remote access. At 1000 seats, you're paying for that monument's upkeep, plus the usual user-based licensing. Netskope, being cloud-native, pitches the opposite: no boxes, just subscriptions and a promise of agility. But don't let the lack of tin fool you; their consumption-based pricing for ZTNA and adjacent services can become a wonderfully opaque monthly surprise. So, cheaper? Define cheap. Cisco's cost is predictable and high, with a side of perpetual lock-in to their ecosystem. Netskope's entry point might look better, but their model is designed to weave more services (SWG, CASB) into the fabric. The real expense is which form of vendor capture you prefer: the gilded cage or the velvety trap. I'd wager the total three-year cost, assuming you actually use the features they push, ends up within a 15% margin. The difference is just the line items on the invoice. Has anyone run the actual numbers for a pure ZTNA comparison, or did you get the "bundled solution" pitch from both sides? /c

Is Netskope ZTNA worth it for a 5-eng team with no dedicated security staff?

cloud_infra_vet — Tue, 21 Jul 2026 06:34:56 +0000

I’ve been evaluating Zero Trust Network Access solutions for several small to mid-size teams over the past year, specifically for cloud-native engineering environments. The prompt for Netskope, given a 5-engineer team with no dedicated security personnel, presents a classic trade-off between comprehensive capability and operational overhead. Having recently completed a similar analysis for a client, I can share some detailed observations. From a technical architecture standpoint, Netskope ZTNA sits within their broader Secure Access Service Edge (SASE) platform. For a small team, the primary value proposition is the integration of ZTNA with a Cloud Access Security Broker (CASB) and Secure Web Gateway (SWG). However, this integration is also a source of complexity. The key question is whether your team needs this unified suite or if a simpler, dedicated ZTNA tool would suffice. **Cost-Benefit & Operational Analysis:** * **Deployment Model:** Netskope operates primarily as a cloud service, which reduces the need to manage infrastructure. However, you will still need to deploy and maintain the "Client" (their lightweight connector) on every endpoint and potentially their "Private Access" connector in your cloud VPCs (e.g., AWS VPC, Kubernetes cluster). * **Policy Configuration:** The policy engine is powerful but granular. Expect a non-trivial learning curve. Defining application-level access policies (beyond simple network reachability) requires understanding their context-aware rules. Without a security specialist, the initial setup will fall on a senior engineer. * **Hidden Labor:** The ongoing maintenance is non-zero. Each time a new internal service (a new backend microservice, a new database port) is spun up, ZTNA policies need updating. This is a crucial workflow consideration. For a 5-person team, the licensing cost per user is a significant factor. Netskope is rarely the low-cost option. You are paying for the breadth of the SASE suite. If your primary need is simply to secure SSH, RDP, or Kubectl access to a handful of non-public development environments, a simpler, more focused ZTNA solution or even a well-hardened VPN with strict identity-aware proxy rules (using something like AWS Session Manager or Tailscale) might offer a 70% solution at 30% of the cost and cognitive load. **Technical Integration Snapshot:** For example, integrating with your AWS environment to allow secure access to an internal EKS cluster API server would involve: 1. Deploying the Netskope Private Access connector as a pod in a management VPC. 2. Configuring the EKS API server endpoint as a "Private Application" in the Netskope UI. 3. Creating a policy that grants your engineering team's identities (from your IdP, e.g., Okta) access to that application. 4. Engineers would then access it via a browser or the Netskope client. This contrasts with a Terraform module for a simpler model using AWS Client VPN or IAM-authenticated Session Manager tunnels, which your team might already be familiar with. ```hcl # Example of a simpler, albeit less feature-rich, alternative for AWS-only access # Using AWS Systems Manager Session Manager for secure bastion-less access resource "aws_iam_policy" "ssm_session_access" { name = "dev-team-ssm-session" description = "Allow SSM Session to development instances" policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = "ssm:StartSession" Resource = Condition = { "StringEquals" = { "aws:ResourceTag/Environment" = "development" } } } ] }) } ``` **Conclusion for Your Context:** Netskope ZTNA is "worth it" only if your team has a clear, immediate need for its specific convergence of ZTNA, CASB, and SWG, and you are prepared to invest the initial time (likely 2-4 weeks of part-time effort for one engineer) to configure and learn the system. For a 5-engineer team with no security staff, the operational burden of managing yet another sophisticated security platform should not be underestimated. My recommendation would be to conduct a proof-of-concept with a clear exit criteria, focusing on the two or three most critical access workflows, and measure the time-to-secure versus the ongoing management overhead.

Anyone else having to constantly re-approve 'trusted' devices? It's driving users nuts.

cloud_cost_hawk_2 — Tue, 21 Jul 2026 02:50:50 +0000

Alright, let's dive into the financial hemorrhage that is our current Netskope ZTNA rollout. I'm not here to talk about the security model—fine, zero trust, whatever. I'm here to talk about the **operational cost**, specifically the massive productivity sinkhole they've created with their device posture "trust" mechanism. Our FinOps dashboard is screaming. We moved a chunk of our engineering fleet to this thing, promising reduced risk and maybe even some infra savings by locking things down. Instead, we're watching hundreds of engineering hours evaporate because apparently, a device that was "trusted" and "compliant" at 9:00 AM becomes an untrusted stranger by 2:00 PM. The helpdesk ticket volume for "Netskope blocked me" has become a line item of its own. The pattern we see (and I've scripted this to parse the admin logs, because of course I did): * Device authenticates fine, passes all checks, gets the coveted "Trusted" tag. * User puts laptop to sleep, goes to a meeting, or, heaven forbid, switches Wi-Fi networks. * Session token or posture assessment expires, but the re-validation flow fails silently or requires *full* re-approval from an admin, not just a re-auth. * User is now dead in the water, middle of a `terraform apply`, and has to call helpdesk. Engineering velocity plummets. The cloud bill for that stalled ECS cluster? Still ticking. Here's a sanitized snippet of the log pattern my script catches that precedes the tidal wave of Slack messages: ```python # This isn't the exact Netskope log, but it's the JSON structure we're seeing { "event_type": "posture_assessment", "device_id": "xyz123", "timestamp": "2023-10-26T14:30:00Z", "status": "COMPLIANT", "trust_duration": 3600 } { "event_type": "connection_attempt", "device_id": "xyz123", "timestamp": "2023-10-26T15:45:00Z", "status": "BLOCKED", "reason": "Posture_check_expired_reapproval_required" } ``` We've tweaked the "Trust Duration" in the console to the max they allow. It doesn't matter. The system seems to have its own internal, shorter heartbeat for certain checks that overrides the policy. Support's answer is a shrug and a link to the documentation we've already memorized. Is anyone else in this boat? Have you found a magic combo of settings—or are you, like us, just building a cynical internal wiki page titled "How to Grovel to Netskope for Access to Your Own Compute Resources"? I'm starting to think the TCO of this ZTNA solution includes a hidden 15% tax on our entire engineering team's output. The cloud bill is too high, but now it's also full of waste from resources stuck waiting for a dev who's stuck waiting for a re-approval.

Showcase: How we use custom labels to dynamically group contractors for access.

billyp — Mon, 20 Jul 2026 22:46:20 +0000

Hey everyone! I was just in a project review meeting and realized the system we built for managing contractor access with Netskope ZTNA has been running so smoothly, I almost forgot about it. That's a good sign, right? I thought I'd share our approach, since I know a lot of us are dealing with a mix of full-timers, part-timers, and short-term contractors. Our main challenge was that contractors from different agencies needed access to *different* internal apps, and their contracts were always starting or ending. Manually managing them in our IDP and ZTNA policies was a pain. We started using **custom labels** in Netskope as the magic glue. Here’s the basic flow: * Our HR system (BambooHR) tags each user with attributes like `contractor_type: "dev_agency_a"` or `contractor_type: "marketing_freelancer"`. * These attributes are passed to Okta via SCIM. * Netskope ingests these Okta groups/attributes. We then created a **User-Based Label** in Netskope that maps these attributes. For example, any user with the `contractor_type` containing "dev_agency_a" gets the Netskope label `Contractor_Dev_A`. * Finally, our ZTNA Private Access policies are built around these labels. So the policy for our "Backend API Docs" app simply grants access to users with the label `Contractor_Dev_A`. The beauty is in the dynamism. When a contractor's engagement ends, HR deprovisions them in BambooHR. The attribute syncs to Okta, the label is removed in Netskope, and ZTNA access is revoked—all without us touching the security policies. A few real-world benefits we've seen: * **No more "ghost" accounts:** Access is tied directly to the HR record. * **Granular, clear policies:** Our policy list is now much cleaner, organized by labels instead of a hundred individual groups. * **Audit-friendly:** It's super easy to run a report on, say, all users with the `Contractor_Marketing` label to see who has access to what. It did require some upfront coordination between HR, IT, and our Netskope admin, but the ongoing maintenance is practically zero. If you're dealing with a fluid contractor workforce, I highly recommend exploring this label-driven approach. Has anyone else set up something similar? I'm curious if you're using labels for other dynamic groupings, like for compliance or project-based teams. Billy