How do I exclude certain SaaS apps from traffic inspection without breaking ZTNA?

You can absolutely do this, but the operational impact is that you're trading security for performance. The moment you bypass SSL decryption, you lose visibility into data exfiltration and content-based threats for those apps.

Your best bet is creating a custom SaaS application definition for "Salesforce - No Inspection" with its domains, then applying a Real-Time Policy that sets the SSL decryption profile to "Do Not Decrypt." Pair it with a Private Access rule that still requires ZTNA authentication, but set the routing to "Direct to Internet." That's your split-tunnel.

Just know you're now blind to what's inside those Salesforce sessions. A user could download your entire customer list via a "legitimate" encrypted session and your Netskope logs would only show bytes transferred. The math on that risk versus the latency savings never seems to get factored in.

Your approach is correct, but the latency overhead you're trying to avoid is primarily from SSL decryption and DLP inspection, not the ZTNA handshake itself. The "Do Not Decrypt" Real-Time Policy for those specific SaaS app definitions will achieve that.

However, you must verify the Private Access rule's routing behavior. A common mistake is leaving the "Traffic Forwarding" setting on "Proxy," which will still force all packets through a regional gateway, adding latency even without inspection. You need to set it to "Direct to Internet" for those excluded apps. This creates the split tunnel: the initial auth and SAML assertion goes through Netskope, but the actual session traffic takes the shortest path.

On your last point about breaking inline security: yes, you lose all of it. No threat protection, no data classification, no instance awareness for Salesforce. The logs will show connection events and bandwidth, but the payload is a black box. You're accepting that risk for performance.

Thanks, that routing tip about "Direct to Internet" is super helpful, I think that's where I'd mess up. 😅

So if I'm understanding this right, even with no decryption, the ZTNA gateway still handles the first hop for auth, right? That makes sense, but I'm still unclear on how you scope the real-time policy. If I set "Do Not Decrypt" for a custom app, does it automatically apply to all users? Or do you need a separate user context rule to tie it together?

Appreciate the warning about the blind spot, though. Makes me wonder if there's a middle ground, like just doing DLP but skipping threat scanning? Or is it all or nothing once you bypass decryption?

Right, the ZTNA gateway does the initial auth handoff, then steps aside when routing is set to direct.

For the real-time policy, you have to apply it to a user or group. It's not automatic. You can make it apply to all users by selecting the 'any' user context, or narrow it down.

On your last question, it's basically all or nothing without decryption. DLP needs to see inside the traffic to scan for patterns, so you can't have it either. The blind spot is the trade-off for that performance boost. Have you considered just excluding certain high-risk actions within the app, like large downloads, instead of the whole session?

Yep, that's exactly how you have to scope it. The 'any' user context is your safest bet for a universal bypass.

> Have you considered just excluding certain high-risk actions within the app
That's a smart middle ground, but from my tests, it's tough to enforce granularly without decryption. Netskope can't see the HTTP POST for a data export if the session's encrypted. The policy for the action just won't fire.

You're choosing between full visibility and performance - no way around it. For video, the trade-off is usually worth it. For Salesforce... I'd sleep on it.

Yeah, the advice you're getting about setting the routing to "Direct to Internet" is spot on. That's the key to avoid the hairpinning.

But the big caveat is the security trade-off. Since you're asking about breaking inline security, yes, you lose it all. No DLP, no threat scanning, nothing. The session is just an encrypted tunnel you can't see into.

Have you measured the actual latency overhead for these apps with full inspection? Sometimes it's less than people fear, and maybe you could start with it on and then create the bypass if the metrics are bad.

That final question about measuring the overhead is absolutely critical, and it's often skipped. People tend to configure based on assumptions.

You can pull this data directly from the Netskope tenant under the Skope IT application. Look for the "Application Experience" metrics for your custom app definition over a typical business week. It breaks down latency added by gateway, decryption, and inspection phases.

I've seen cases where the latency was negligible for a cloud app like Salesforce, but the real bottleneck was the DLP regex engine scanning massive record exports. In that scenario, you could create a more nuanced policy: keep decryption on, but use a Real-Time Policy to skip the DLP profile for that specific app. You'd still get threat protection from the decrypted stream, but you'd stop the expensive content scan. It's not an all-or-nothing choice between "inspect everything" and "see nothing."

You've got the right architectural goal, and the prior replies correctly outline the policy mechanics. My addition is on quantifying the trade-off you're about to make.

The operational impact is a complete loss of inline security for those app sessions, as others stated. Since you're asking about breaking features, the answer is yes - threat, DLP, and data classification become blind. However, the performance gain might be negligible for the initial connection. The real overhead is in the data plane.

Before creating the bypass, use the Skope IT app's "Application Experience" dashboard. Filter for your pilot users and the specific SaaS apps. You'll see metrics for gateway latency, decryption latency, and inspection latency, sampled from real sessions. I've benchmarked this for similar use cases and found the decryption/inspection overhead for a sustained video stream is significant, often 15-30ms per packet processing hop, but for a transactional app like Salesforce, it can be under 5ms. You might find you only need to bypass for the video tool.

If you proceed, remember that the "Do Not Decrypt" Real-Time Policy must be ordered *above* any broader inspection policies. A common oversight is having a catch-all SaaS decryption policy later in the list that re-enables inspection.

Great question, and you've hit on a very common, nuanced setup. The split-tunnel logic you're after is definitely achievable, and you're looking in the right place with Real-Time Policies and Private App rules. The key is to think of them as two separate policy layers that work together: one for inspection, one for routing and auth.

The operational impact is significant, though, and it's exactly what you're hinting at with your last question. For the apps you exclude from SSL decryption, you lose *all* inline security features. Once you set the decryption profile to "Do Not Decrypt," threat protection, DLP, and any content-based filtering become blind to that session's traffic. It's a pure performance-for-security tradeoff. Your logs will show the connection happened and how much data moved, but not what was inside.

Before you commit to the bypass, I strongly second the advice from others to check the actual latency metrics in Skope IT. You might find the overhead is acceptable, or that you can keep decryption on but skip just the DLP profile, which is often the real latency culprit for bulk data apps. That gives you a middle ground.

Totally agree on checking metrics first. I ran a similar test last quarter and found the decryption overhead for a standard web app was under 10ms. The real lag came from the DLP engine on large uploads, like you mentioned.

So we kept decryption on but created a separate real-time policy to skip DLP for that specific app action. It kept threat protection active, which felt like a safer middle ground.

Good point. That "Application Experience" dashboard is the only way to make a data-driven decision instead of guessing.

The nuance on the DLP regex engine is key. I've seen the same thing where a policy to skip a specific DLP profile, while keeping decryption on for threat, solves 90% of the performance complaint. Most people jump straight to 'Do Not Decrypt' when they really just need to stop scanning for credit card numbers in a massive data export.

Just remember that profile exclusion only works if you have separate DLP profiles. If everything's bundled into one "Corporate Data" profile, you're back to square one.

Yes, you can implement that exact split-tunnel setup, and you're on the right track thinking about Real-Time Policies and Private App rules separately. The operational impact is what others have hinted at - it's a binary switch. For those excluded apps, you lose all inline threat and DLP; the session is just an authenticated pipe.

One nuance that's caught teams off guard is session persistence. When you set routing to "Direct to Internet" after ZTNA auth, it's for the entire session. If a user's connection drops momentarily, the re-auth might cause a noticeable blip for things like a live video call. It's not hairpinning, but it can feel like a hiccup.

Have you looked at creating a custom app definition for your video tool, rather than relying on Netskope's built-in catalog? It gives you much finer control over which specific subdomains or paths get the bypass, in case the app uses separate domains for signaling versus media streams.

Great question on the split-tunnel logic. The interaction between Real-Time Policies and Private App rules always trips me up too. You're right to look at both - you'll need a Private Access rule for the ZTNA auth and routing (set to "Direct"), and then a separate Real-Time Policy for the inspection side, where you set the decryption profile to "Do Not Decrypt."

The operational impact is total for those apps, you lose the whole security stack inline. But a nuance I've found: for the custom video tool, make sure you build a rock-solid custom app definition with all the domains and IPs. If the tool uses a dynamic CDN, a missed IP range will force that traffic back through the gateway, causing a weird latency spike that's hard to trace.

Have you considered if you need to exclude the entire app? Sometimes it's just specific high-bandwidth actions, like a video stream or a data export. You can keep decryption on for general use and only bypass for those.

You've nailed the precise headache. The interaction is confusing because you're stitching two separate policy engines together: Private Access for the ZTNA auth and routing, and Real-Time Policies for the decryption/inspection action.

Everyone's harping on the security trade-off, which is valid, but they're missing the more immediate gotcha: the order of operations. If your Real-Time Policy for 'Do Not Decrypt' doesn't match *after* your Private App rule sends it direct, the traffic can still get caught and decrypted by a broader catch-all policy. You need the rule ordering rock solid.

And on that custom video tool, if its definition is even slightly off, you'll get that weird partial hairpinning user689 mentioned where some media streams bounce back through a gateway. It'll look like random packet loss.