<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Netskope ZTNA Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 10:37:18 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Our results after enforcing device posture: 12% of &#039;managed&#039; laptops actually failed.</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/our-results-after-enforcing-device-posture-12-of-managed-laptops-actually-failed-2/</link>
                        <pubDate>Sun, 27 Sep 2026 08:11:02 +0000</pubDate>
                        <description><![CDATA[We just finished a device posture rollout for our ZTNA access gates. The requirement was simple: only managed, encrypted, and patched (&gt;30 days) corporate laptops get access to internal a...]]></description>
                        <content:encoded><![CDATA[We just finished a device posture rollout for our ZTNA access gates. The requirement was simple: only managed, encrypted, and patched (&gt;30 days) corporate laptops get access to internal apps.

Ran the check against our entire "managed" fleet of 5,000+ macOS/Windows devices. Netskope Client pulled data from our MDM (Jamf/Intune) and local checks.

**Results:**
*   12% (600+) of devices were flagged as non-compliant.
*   Top failure reasons:
    *   Disk encryption disabled (user-initiated).
    *   MDM agent unexpectedly missing/unresponsive.
    *   OS build version not reported (often due to pending reboot).
    *   Local admin changes (unauthorized software, disabled security services).

**Takeaway:**
Your "managed" inventory is a lie until you enforce continuous, pre-authentication checks. We blocked all non-compliant devices at the ZTNA gateway. The help desk queue exploded, but it exposed real security debt.

**Config snippet for the posture check (simplified):**
```json
{
  "rule_name": "corp-laptop-compliance",
  "conditions": {
    "os": ,
    "encryption": "required",
    "mdm_status": "enrolled",
    "max_patch_age_days": 30
  },
  "action": "allow"
}
```

The noise was painful but necessary. Now we have a real-time map of device trust. Next phase: integrating with our EDR for active threat checks.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>Daniel Kim</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/our-results-after-enforcing-device-posture-12-of-managed-laptops-actually-failed-2/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: Intermittent &#039;connection reset&#039; errors for users in APAC.</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/troubleshooting-intermittent-connection-reset-errors-for-users-in-apac/</link>
                        <pubDate>Sat, 26 Sep 2026 09:16:19 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been wrestling with a particularly pesky issue for the last few weeks and I&#039;m hoping some of you might have run into something similar or can spot something I&#039;ve missed. W...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been wrestling with a particularly pesky issue for the last few weeks and I'm hoping some of you might have run into something similar or can spot something I've missed. We've been rolling out Netskope ZTNA for our global team, and while the EMEA and NA regions are humming along nicely, our users in APAC—specifically Singapore, Sydney, and Tokyo—are reporting intermittent "connection reset" errors when trying to access internal web apps. It's not consistent for everyone at the same time, which is the really frustrating part. One minute, everything's fine; the next, a user gets booted mid-transaction.

I've been down a pretty deep rabbit hole trying to isolate the variables. Our setup uses the Netskope Client with the ZTNA connector profile, steering traffic through the nearest Netskope POP. I've confirmed the users are hitting the correct regional POPs (Singapore for most, Sydney for AU). We're not using any custom client steering rules that would force a suboptimal path. Latency to the POPs looks normal, and the Netskope Client shows a healthy "Connected" status when these resets happen.

So far, I've ruled out local machine firewalls (we have a standard config) and general internet instability on the user's end—it happens across different ISPs and even on corporate MPLS links. The errors in the browser dev tools are just generic `ERR_CONNECTION_RESET` or sometimes `NET::ERR_SSL_PROTOCOL_ERROR`, which points to something happening at the transport layer after the handshake. My hunch is that it's somewhere between the Netskope POP and our private app connector, maybe related to session timeouts or a specific routing hiccup in the APAC backbone.

I'm curious if anyone else has faced this regional intermittency? Specifically:
- Did you find any particular ZTNA connector configuration (like idle timeout, TCP keep-alive) that made a difference for high-latency paths?
- Are there any known issues with specific APAC POPs or backend routing that Netskope support might not flag immediately?
- Has anyone implemented a workaround, like adjusting MTU settings on the client or tweaking TLS parameters on the origin?

I love the elegance of ZTNA when it works, but these ghost-in-the-machine issues really test the tinkerer in me! I'm compiling logs and packet traces from a few affected users to open a support case, but the community's real-world experience is always gold. Any anecdotes or diagnostic steps you found useful would be massively appreciated.

hugo]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>hugo_b</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/troubleshooting-intermittent-connection-reset-errors-for-users-in-apac/</guid>
                    </item>
				                    <item>
                        <title>Just finished our 90-day POC. Here&#039;s the raw data on session timeouts and user complaints.</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/just-finished-our-90-day-poc-heres-the-raw-data-on-session-timeouts-and-user-complaints-2/</link>
                        <pubDate>Fri, 25 Sep 2026 23:10:56 +0000</pubDate>
                        <description><![CDATA[Our procurement team was sold the &quot;seamless, invisible security&quot; story by Netskope. After a 90-day POC across 500 users, the data tells a different one. The biggest operational headache, by ...]]></description>
                        <content:encoded><![CDATA[Our procurement team was sold the "seamless, invisible security" story by Netskope. After a 90-day POC across 500 users, the data tells a different one. The biggest operational headache, by far, was session persistence. Or rather, the lack of it.

We logged every timeout-related helpdesk ticket during the trial. The average user session, as enforced by the ZTNA gateway, dropped connections after 15 minutes of *inactivity*. Not idle on the network, but inactivity in the specific app being proxied. A user switching from a CRM tab to check email for 10 minutes would get booted from the CRM. Re-authentication prompts, lost work, the usual chaos. Complaint volume spiked 300% in the first month. The vendor's response was to point us to a "keep-alive" configuration that essentially requires constant, low-level traffic pings from the endpoint agent—a workaround that feels like defeating the purpose.

The cost of this "security" is measurable productivity loss. We benchmarked it against our legacy VPN. Simple task completion times for cloud apps increased by an average of 18% due to re-auth and reconnection latency. Their sales engineering team calls this a "minor adjustment period." I call it a direct hit to ROI before we even discuss the premium price tag. The security model might be sound, but the user experience implementation is brittle. Anyone else seeing this, or did we just get a bad config template?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>gareth_h</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/just-finished-our-90-day-poc-heres-the-raw-data-on-session-timeouts-and-user-complaints-2/</guid>
                    </item>
				                    <item>
                        <title>Just built a Grafana dashboard to track Netskope tunnel health. Sharing the config.</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/just-built-a-grafana-dashboard-to-track-netskope-tunnel-health-sharing-the-config-2/</link>
                        <pubDate>Fri, 25 Sep 2026 04:55:48 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;m new to monitoring in AWS and we just started using Netskope ZTNA. I wanted a quick way to see if our tunnels were healthy, so I built a simple Grafana dashboard.

I used Te...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I'm new to monitoring in AWS and we just started using Netskope ZTNA. I wanted a quick way to see if our tunnels were healthy, so I built a simple Grafana dashboard.

I used Terraform to set up a CloudWatch dashboard, but it wasn't great for quick glances. So I pulled the metrics into Grafana. Here's the main panel query for tunnel status:

```json
{
  "datasource": "CloudWatch",
  "queryMode": "Metrics",
  "region": "us-east-1",
  "namespace": "Netskope/ZTNA",
  "metricName": "TunnelStatus",
  "statistics": ,
  "period": "300",
  "refId": "A"
}
```

It's basic but super helpful for me to learn. Shows green/red for up/down. Next I'm trying to add alerts for when a tunnel flips. Anyone else done this? Would love to see other config examples &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>cloud_infra_newbie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/just-built-a-grafana-dashboard-to-track-netskope-tunnel-health-sharing-the-config-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Zscaler to Netskope - 6 month report for a 1200-user org</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/migrated-from-zscaler-to-netskope-6-month-report-for-a-1200-user-org-2/</link>
                        <pubDate>Fri, 21 Aug 2026 15:06:00 +0000</pubDate>
                        <description><![CDATA[Hi everyone. We completed our migration from Zscaler Private Access (ZPA) to Netskope Private Access about six months ago for our ~1200 user base, primarily remote and hybrid. I wanted to sh...]]></description>
                        <content:encoded><![CDATA[Hi everyone. We completed our migration from Zscaler Private Access (ZPA) to Netskope Private Access about six months ago for our ~1200 user base, primarily remote and hybrid. I wanted to share a concrete, mid-term report since detailed, real-world transitions are so valuable in this space.

The decision was driven by a need for tighter integration with our existing cloud security posture and a more unified dashboard. Our stack is heavily SaaS-based, so seeing SWG and ZTNA traffic in one place with Netskope has been a genuine operational win. The initial migration was smoother than expected, largely because our app inventory was well-documented. User onboarding via the client was straightforward, and we saw fewer initial help desk tickets for connectivity issues compared to our Zscaler rollout years ago.

A few specific observations:
*   **Performance:** Application performance, especially for our internal development tools, is noticeably better. Latency feels lower, though that's subjective. The biggest win is in connection stability—fewer random drops.
*   **Policy Management:** We find the policy logic in Netskope more intuitive. Creating rules based on user groups, device posture, and application risk scores has streamlined access reviews.
*   **The Trade-off:** The admin interface is powerful but dense. It took our team a good two months to feel fully proficient. Zscaler's interface felt simpler, if sometimes less granular.
*   **Cost:** For our specific bundle (SWG + ZTNA), we're seeing cost neutrality over our previous setup with separate vendors. The real ROI for us is in reduced admin overhead and consolidated reporting.

I'm particularly interested in hearing from others who made a similar switch on long-term user experience and any nuanced pitfalls in policy scaling. How has your team's workflow adapted?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>Alex Garcia</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/migrated-from-zscaler-to-netskope-6-month-report-for-a-1200-user-org-2/</guid>
                    </item>
				                    <item>
                        <title>Help: Client update failed silently and left half our fleet unprotected.</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/help-client-update-failed-silently-and-left-half-our-fleet-unprotected/</link>
                        <pubDate>Wed, 19 Aug 2026 15:21:00 +0000</pubDate>
                        <description><![CDATA[Hey folks, hoping someone here has run into this before and can point me in the right direction. &#x1f613;

We pushed a client update to our Netskope ZTNA agents last week, and it seems to h...]]></description>
                        <content:encoded><![CDATA[Hey folks, hoping someone here has run into this before and can point me in the right direction. &#x1f613;

We pushed a client update to our Netskope ZTNA agents last week, and it seems to have failed silently on about half of our Windows endpoints. The console showed the deployment as "successful," but those machines never actually got the new client version. Worse, the old client stopped checking in properly, so those users have been essentially unprotected for days without any alerts firing.

Here’s what we’ve checked so far:
*   No consistent pattern in the failures—it’s a mix of Windows 10 and 11, different departments.
*   Local logs on a few affected machines show the installer started but then exits with a generic error code (nothing helpful).
*   Our firewall logs show outbound connections to Netskope were blocked *after* the failed update, which points to the client service being broken.

Has anyone dealt with a silent failure like this? Specifically:
1.  Is there a better place to look for detailed installer logs than the standard AppData temp folder?
2.  Any known issues with recent client versions conflicting with other security software (we use CrowdStrike)?
3.  What’s the safest rollback procedure to get protection back quickly—should we manually push the previous version, or is there a config fix?

Really worried about the gap in coverage, so any tips on troubleshooting or a stopgap would be a lifesaver.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>blakev</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/help-client-update-failed-silently-and-left-half-our-fleet-unprotected/</guid>
                    </item>
				                    <item>
                        <title>Anyone else find Netskope&#039;s &#039;continuous validation&#039; too aggressive for our remote developers?</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/anyone-else-find-netskopes-continuous-validation-too-aggressive-for-our-remote-developers/</link>
                        <pubDate>Wed, 19 Aug 2026 11:45:57 +0000</pubDate>
                        <description><![CDATA[We&#039;ve been evaluating Netskope&#039;s ZTNA solution for the last quarter, specifically for a segment of our workforce comprising approximately 250 remote software engineers and DevOps personnel. ...]]></description>
                        <content:encoded><![CDATA[We've been evaluating Netskope's ZTNA solution for the last quarter, specifically for a segment of our workforce comprising approximately 250 remote software engineers and DevOps personnel. Our primary goal was to secure access to internal development environments and tooling without the overhead of a full VPN. While the core connectivity and policy engine function as advertised, we are encountering significant pushback regarding the 'continuous validation' feature, which appears to be causing material disruptions to developer workflow and productivity.

Our configuration enforces posture checks at session initiation and then at a continuous validation interval, which we initially set to the recommended 60-minute heartbeat. The checks themselves are not trivial; they verify the presence and status of our EDR agent, specific registry keys for approved security configurations, and the absence of certain blacklisted processes commonly associated with vulnerability testing tools.

The issue manifests in two primary ways:
1.  **Session Termination During Long-Running Operations:** Developers executing builds, data pipeline jobs, or lengthy integration tests that exceed the heartbeat interval are being abruptly disconnected when the validation check occurs, even if their posture state has not changed. This kills the active session to the internal resource, often ruining the operation.
2.  **Performance Overhead on Developer Machines:** The validation checks themselves are resource-intensive, causing noticeable CPU and I/O spikes on developer laptops. During these spikes, which occur like clockwork every hour, IDE responsiveness and local test execution are degraded. We have quantified this with basic monitoring, observing a consistent pattern.

```
// Example of a simple script to log CPU during a suspected check (Windows)
Get-Counter -Counter "Process(*)% Processor Time" -SampleInterval 5 -MaxSamples 12 | Where-Object {$_.Readings -like "*nsZTNA*"} | Format-Table -AutoSize
```

Our internal cost-benefit analysis is starting to tilt negative. The theoretical reduction in breach risk (which is valuable) is being offset by:

*   Tangible productivity loss, measured in tickets for failed deployments and anecdotal reports of workarounds (e.g., engineers splitting tasks artificially to fit under the heartbeat window).
*   Increased support burden on our IT help desk for "access interrupted" tickets.
*   The intangible but real cost of developer frustration, which impacts morale and, indirectly, velocity.

We are exploring configuration adjustments, but the options seem limited. The trade-offs we've identified so far are:

*   **Increasing the heartbeat interval to 120 or 180 minutes:** Reduces frequency but amplifies the "blast radius" of a compromised machine that goes undetected within that window, partially negating the "continuous" promise.
*   **Making checks less intensive:** Removing the process enumeration or deep registry checks diminishes the security value of the posture assessment.
*   **Creating a separate, less restrictive policy for developers:** This seems to violate the zero-trust principle of uniform policy enforcement and creates an administrative headache.

Has anyone else deployed Netskope ZTNA in a similar environment for technical staff? Specifically:

*   What have you found to be the maximum tolerable validation interval for users with long-lived, stable connections?
*   Are there methods to make the validation checks more efficient or less intrusive, perhaps by staging them (a light-weight heartbeat with occasional deep checks)?
*   How are you quantifying the operational trade-off between security rigidity and user productivity in your FinOps or SecOps calculations?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>brianw23</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/anyone-else-find-netskopes-continuous-validation-too-aggressive-for-our-remote-developers/</guid>
                    </item>
				                    <item>
                        <title>How do I handle RDP over Netskope ZTNA without killing performance?</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/how-do-i-handle-rdp-over-netskope-ztna-without-killing-performance-2/</link>
                        <pubDate>Wed, 19 Aug 2026 04:40:56 +0000</pubDate>
                        <description><![CDATA[Just started testing Netskope ZTNA for our internal tool access and hit a snag with RDP. The tunnel feels like it adds just enough latency to make some graphical tasks (think image editing r...]]></description>
                        <content:encoded><![CDATA[Just started testing Netskope ZTNA for our internal tool access and hit a snag with RDP. The tunnel feels like it adds just enough latency to make some graphical tasks (think image editing remoted into a design VM) really sluggish. Lags and artifacts are driving the creative team nuts &#x1f605;

I know ZTNA adds hops, but there's gotta be a tuning trick. Are you adjusting any specific RDP settings (like bandwidth auto-detect or compression) client-side? Or is there a Netskope policy tweak that helped you? Really want to make this work without falling back to the old VPN.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>amy_w</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/how-do-i-handle-rdp-over-netskope-ztna-without-killing-performance-2/</guid>
                    </item>
				                    <item>
                        <title>Moved from Netskope to Cato Networks - which one is better for AWS-heavy workloads?</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/moved-from-netskope-to-cato-networks-which-one-is-better-for-aws-heavy-workloads-2/</link>
                        <pubDate>Tue, 18 Aug 2026 21:45:53 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m pretty new to networking and cloud security stuff. My team recently switched from Netskope ZTNA to Cato Networks. The main reason was cost, but I&#039;m not sure if it was the r...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm pretty new to networking and cloud security stuff. My team recently switched from Netskope ZTNA to Cato Networks. The main reason was cost, but I'm not sure if it was the right move for our setup.

We run almost everything on AWS: EC2, Lambda, RDS, the usual. Our old Netskope setup had Terraform modules that looked like this:

```hcl
module "netskope_connector" {
  source = "internal-modules/netskope-aws"
  vpc_id = aws_vpc.main.id
  subnet_ids = aws_subnet.private.id
}
```

It was integrated pretty deep. Now with Cato, I feel like I'm manually configuring more things in the Cato console, and our Terraform code just handles the EC2 instance for the socket. Is this normal? For those with heavy AWS workloads, which platform gave you less overhead? I'm worried about complexity as we scale.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>cloud_infra_newbie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/moved-from-netskope-to-cato-networks-which-one-is-better-for-aws-heavy-workloads-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using Netskope in production for a 2000-user org?</title>
                        <link>https://communities.stackinsight.net/community/cyber-netskope-ztna/anyone-actually-using-netskope-in-production-for-a-2000-user-org-2/</link>
                        <pubDate>Tue, 18 Aug 2026 15:46:19 +0000</pubDate>
                        <description><![CDATA[Alright, let’s set the scene. It’s year three of my current CRM tenure, which means I’m already mentally drafting the migration plan for next year. But this isn’t about CRMs. This is about t...]]></description>
                        <content:encoded><![CDATA[Alright, let’s set the scene. It’s year three of my current CRM tenure, which means I’m already mentally drafting the migration plan for next year. But this isn’t about CRMs. This is about the other vendor relationship I’m contractually obligated to resent: our ZTNA platform.

We’re a 2000-person shop, fully remote, with the usual parade of SaaS apps, legacy on-prem holdouts, and a sales team that will click on absolutely anything in a convincing email. We went all-in on Netskope about 18 months ago, replacing a traditional VPN. The sales pitch was, as always, flawless. The reality, as always, is… a mixed bag.

I’m not here to regurgitate the datasheet. I want to talk about what actually *broke*, what *improved*, and where I’m already side-eyeing the exit clause.

**The Good (or, "Why We Haven't Lit It On Fire Yet")**

*   User experience, post-onboarding, is genuinely better than the old VPN. No more "turn on the tunnel to check Salesforce." The direct-to-app model works for probably 80% of our daily tools. The help desk tickets for "I can't get into the network" have plummeted.
*   The visibility into SaaS app usage and risk is staggering—almost uncomfortably so. We caught several shadow IT instances and some… interesting… uploads to personal cloud storage that would have otherwise gone unnoticed.
*   For a cloud-first workflow, performance is a net positive. No more backhauling all traffic through a data center just for web filtering.

**The Bad (or, "The Devil's in the Policy Configuration")**

*   The initial rollout was a special kind of hell. The client deployment was smooth, but the policy logic is a beast. It’s powerful, but with great power comes great opportunity to accidentally block your entire finance team from their ERP system. We did that. For an hour.
*   The "non-standard" or legacy applications. Don’t believe the hype that it’s seamless. If you have any quirky, home-grown, or ancient client-server apps, be prepared for a long, painful process of creating granular policies, fiddling with client settings, and possibly maintaining a small VPN bastion for those holdouts. We still have one.
*   The admin console feels like it was designed by a team of brilliant security engineers who have never met a UI/UX designer. Finding specific things, tracing policy hits, and generating readable reports has a steep learning curve.

**The Ugly (or, "The Cost of Commitment")**

*   The licensing model feels like a trap. Once you're in, adding new features or scaling certain protections gets eye-wateringly expensive. It feels very "platform lock-in," which, given my CRM-hopping tendencies, sets off all my alarms.
*   Support is… variable. When it’s good, it’s very good. When it’s not, you’re stuck in a loop of requesting escalations while your sales team in APAC can’t access their demo environment.

So, my core question for anyone else in the 1000-3000 user bracket: Are you seeing the same? More specifically:

*   How are you handling those **truly legacy internal apps** that just don't play nice with ZTNA principles? Did you bite the bullet and refactor, or is there a Netskope trick I'm missing?
*   Has anyone done a genuine **TCO comparison** post-implementation versus a more modular approach (e.g., separate SWG, CASB, and a smaller VPN)?
*   Does the **performance gain** for cloud apps hold up under scrutiny, or are we just trading one bottleneck (data center) for another (their nearest POP)?

I’m documenting my findings for the inevitable "next thing" review, and frankly, I’d rather learn from your scars than create new ones.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-netskope-ztna/">Netskope ZTNA Reviews</category>                        <dc:creator>crm_hopper_2027</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-netskope-ztna/anyone-actually-using-netskope-in-production-for-a-2000-user-org-2/</guid>
                    </item>
							        </channel>
        </rss>
		