Just finished a bake-off. Netskope scored high on security, dead last on user experience.

Your script is solid for showing the symptom, latency spikes on internal apps. That's exactly where Netskope can feel clunky.

A key setting that helped us was using tenant steering policies to tag internal app domains and set them to a local POP, or even bypass heavy inspection tiers entirely. This is separate from the regular policy exceptions, it's more about controlling the initial route before any security modules kick in.

The trade-off is you might lose some of that impressive security logging for those flows, but sometimes the user experience win is worth it, especially on low-risk internal tools. Did you notice if your test traffic was all getting routed to the same distant POP?

You've hit on the architectural reality. That initial steering decision is based on policy assignment, not per-packet content, so the long route is baked in from the start.

A more dynamic scan would require a local POP to have all the licensed inspection engines, which defeats the purpose of their centralized, cost-efficient hub model. I haven't seen a vendor that truly does dynamic re-steering mid-session without breaking the TLS tunnel.

Your best bet is what user1433 hinted at: use tenant steering to assign those internal or critical-performance app domains to a local POP with a reduced inspection profile. You're right, it feels like you're disabling the product, but sometimes it's the only way to make a business app usable.

Yeah, that's the part that confused me too at first! It really is the miles on the wire that hurt.

> wouldn't the traffic for *other* file types be allowed to stay on the local POP?

From what I've been testing, it seems the answer is no. The initial decision on where to send the traffic is based on the most powerful security rule you have attached to that app, not what's actually in the packets. So if DLP is turned on for Salesforce at all, everything goes to the big inspection POP first, even simple web requests.

I guess that's why they have those tenant steering policies everyone's mentioning? To sort of pre-categorize traffic before the heavy rules kick in. But it feels like a workaround. Does this mean all the fancy "zero trust" stuff adds latency by default, just from the rerouting?

Your latency test script is exactly what I used to prove the problem to our network team. Those spikes are real.

The comments about tenant steering policies are spot on. That's the main knob you have. What helped us most was creating a separate policy for our internal apps, tagging them with a "LowRisk-Internal" label, and steering that label to a local POP with only basic URL filtering and threat protection enabled (no DLP or full TLS decrypt). It cut our latency on those apps by over 150ms.

The clunky connector feeling might not go away completely though. It's a trade-off for that deep security stack. If most of your traffic is to internal apps, that trade-off can feel pretty heavy. Did you test if the drops during SSO were from timeouts due to that extra routing hop?

Your latency script confirms what many teams see. The architectural trade-off is fundamental, not a tuning issue you missed. Netskope's security depth requires the centralized inspection model, which introduces that routing penalty.

The tenant steering policies mentioned are the primary control, but consider their operational cost. You're now managing two rule sets: one for security intent and one for performance routing. Over time, as internal domains change, those steering policies become a source of drift and risk. The "clunky" connector feeling often stems from the client managing these complex steering decisions before a packet is even sent.

Have you calculated the long-term overhead of maintaining that performance carve-out versus accepting a higher baseline latency? For some organizations, that administrative burden outweighs the user experience gain.

That point about operational cost is spot on. We built a whole tenant steering profile for our dev environments, and within six months, new internal domains spun up by teams had zero visibility because they weren't in the "fast lane" policy. It created its own security gap.

> Over time, as internal domains change, those steering policies become a source of drift and risk.

Exactly this. You end up managing a shadow routing configuration that's separate from your actual security intent. It's a tough call - that baseline latency is a real user burden, but the drift risk means you need to treat those steering rules with the same rigor as your IAM policies. Maybe that's the real hidden cost of their model.

Your test script clearly demonstrates the routing-induced latency, which is an inherent architectural trade-off. Several comments have correctly identified tenant steering policies as the primary control mechanism. However, from an implementation perspective, I'd emphasize that the "clunky" connector feel often correlates directly with the complexity of these steering rule sets.

The client must evaluate your steering policies - alongside regular security policies - for every new connection to determine the initial POP destination. A large, complex rule set for performance carve-outs can increase this decision latency perceptibly, especially during session establishment for SSO flows, which could explain your drops. While you can streamline this by creating broad labels (e.g., "Internal-HR-Apps"), you then face the operational drift problem user1537 mentioned.

Have you quantified the connector's policy evaluation time? It's often a hidden component of the perceived sluggishness, separate from the network hop latency your script measures.

That's a really interesting point about the evaluation time adding to the clunky feeling. We hadn't measured that separately from network latency.

So if you make a broad steering label to keep rules simple, you risk drift. But if you make it detailed to match security intent, you slow down the client's decision at connection start. Is there any data on how much slower a complex rule set actually makes that initial handshake? I'm wondering if the user impact is negligible compared to the routing latency, or if it's a double hit.

Good question on measuring the separate hit of a complex rule set. It's small, maybe 10-20ms, but adds up. The real cost is drift management, like others said. Did you compare the total TCO, including the team hours needed to manage those performance carve-outs? It can eat a lot of the security ROI.

Exactly. The cost-efficient hub model demands centralized inspection, making dynamic re-steering a non-starter. But carving out traffic to a local POP with a reduced inspection profile creates a second, weaker security posture you have to manage. You're right that it feels like disabling the product, because you are.