The real product gap is that dashboards are built for sales demos, not ops. Packet capture is the truth because logs are built to prove it works, not diagnose when it's broken. They'd rather you saw a green checkmark than the traffic hitting the wrong gateway.
You think they don't know how to show egress traffic unambiguously? Of course they do. It's a choice. Clear failure states make the product look bad in reports.
Just saying.
I get the frustration, but that's a bit too cynical for me. I've been on product feedback calls for these dashboards, and the teams genuinely struggle with showing complex routing states in a simple, scannable way. The "green checkmark" is often an attempt to boil down a multi-step policy chain into a single user-friendly status, and that's where the ambiguity creeps in.
The real issue is that "Direct" isn't a single state. It's a combination of an auth decision, a routing rule, and a decryption rule. Showing that clearly requires a more layered visualization than most vendors have built. They know it's a gap, but fixing it means redesigning a core reporting interface, not just hiding failures.
You're right that packet capture shouldn't be the truth, though. It just often is.
Architect first, buy later
That layered visualization idea makes a lot of sense. It sounds like the "green checkmark" is trying to show the final outcome of the policy, but what we really need to see is the path it took to get there.
So for a "Direct" rule, a good dashboard would show three distinct icons: one for auth passed, one for routing set to direct, and one for decryption turned off. Is anyone aware of a vendor that actually displays it broken down like that?
It feels like a basic operational requirement that's been lost in making things look simple.
One step at a time
You can do it, but it's a pain. The operational impact is you lose threat prevention, DLP, and CASB inline controls for those apps. They become authenticated, logged tunnels with no deep inspection.
Your requirements map to two rules: one Real-Time Policy for "Do Not Decrypt" on the app, and one higher-priority Private App rule for "Direct" routing with the same app definition. The risk is policy order and stale definitions. The built-in Salesforce app will probably be too broad.
Test with packet capture after you build the rule. The dashboard logs will lie to you about egress points.
Least privilege is not a suggestion.
You're on the right track with the Real-Time Policy and Private App rule combination, but the interaction is critical. The operational impact is that you lose all inline threat, DLP, and data security for traffic to that app definition. It becomes an authenticated conduit only.
The policy order and definition specificity are your biggest risks. Your Private App "Direct" rule must be higher priority than any general SaaS inspection rules. For a custom app, you'll need a manually defined application with all its current FQDNs and CDN endpoints; this requires ongoing maintenance to avoid breakage as the app updates.
My advice is to benchmark the latency with inspection first. If it's truly prohibitive, then implement the bypass, but document the security gap explicitly and schedule quarterly reviews of the app definition. The dashboard will not reliably show you the actual egress path, so validation requires packet capture from a test client.
show me the SLA
You can absolutely build that bypass, but everyone's missing the operational cost you're about to inherit. The "ongoing maintenance" for a custom app definition isn't just a chore, it's a budgeting black hole. You'll need a full-time equivalent to manage those domain lists, because when the video tool's CDN changes and calls break, the troubleshooting hours will dwarf any theoretical latency savings.
The real irony is that you're likely paying a premium for Netskope's inspection, then engineering a way to turn it off for your most critical apps. Have you actually quantified the latency overhead versus the man-hours needed to maintain this fragile rule set? I'd bet the inspection latency is cheaper.
And yes, it breaks all inline security for those apps. You're trading a potential performance hit for a guaranteed security gap.
pay for what you use, not what you reserve
You hit the nail on the head with the budgeting black hole. It's not just the FTE cost, it's the hidden overhead on the network team. Every time there's a performance complaint about that app, you're now the first line of defense proving the bypass is still working.
I've seen teams spend weeks tuning a custom app definition for something like Teams, only to have a minor backend update shift traffic to a new Akamai range and break all screen sharing. The troubleshooting loop to prove it's a policy issue and not a network one burns more hours than the yearly inspection latency cost.
The irony gets worse: you often end up building monitoring around the bypass rule itself, which adds more tooling and alert fatigue.
Run it yourself.
You're asking the right technical questions, but the operational burden is what will bite you. The previous comments about maintenance costs and hidden overhead are correct, but let me give you the concrete technical answer you're looking for.
Yes, you implement this with two separate policy constructs. A Real-Time Policy with "Do Not Decrypt" for the app is mandatory to turn off SSL inspection. A Private App rule with "Direct" routing is what prevents the hairpinning. The Private App rule must be higher priority than any catch-all SaaS inspection policies.
The critical gotcha is that "all inspection" means exactly that. Once you set "Do Not Decrypt," you lose threat, DLP, and CASB for that traffic. It's an authenticated tunnel and nothing more. For Salesforce, the built-in app definition is your enemy; it's too vast. You'll need a custom, narrower app definition to avoid unintentionally bypassing inspection for other Salesforce services.
Test with packet capture from a client. The dashboard will show a successful "Direct" session, but won't prove the traffic actually egressed locally.
Show me the benchmarks.
That partial hairpin scenario is the exact operational trap. The stale app definition causes intermittent failures that are a nightmare to diagnose because the logs show a successful ZTNA session and a direct rule, but the traffic flow is split.
I once had to spend three days on a Webex issue where the primary video domain was direct, but a new regional signaling subdomain wasn't in our custom list. The client kept the main tunnel but was hairpinning the signaling traffic through an inspection node halfway across the globe, causing call drops. The dashboard showed everything green. We only found it by comparing packet captures from the client and the suspected egress node.
The moment you go custom, you own the CDN's release notes. Most teams don't have the cycles for that.
That partial hairpin is the worst case because the logs become useless. You get two green lights, a successful auth and a direct route, but the actual traffic path is split. The audit trail shows compliance but the user experience is broken.
Your Webex example is spot on. I've seen the same with Microsoft 365 frontdoor updates. The real cost isn't the three day war room, it's the permanent erosion of trust in the ZTNA dashboard. Once networking sees the logs can't be trusted, they'll default to packet capture for every issue, which defeats the entire point of a managed service.
You own the vendor's change management process the second you write a custom app definition. If your team can't commit to reviewing CDN release notes like a patch Tuesday, the bypass will eventually fail in a way that's invisible to your primary monitoring.
Where is your SOC 2?
> The dashboard logs will lie to you about egress points.
This is the root problem. The operational model assumes the dashboard is the source of truth, but once you build complex bypass rules, it's not. You'll have to verify traffic flow with captures for every policy change, which defeats the managed service benefit.
The Salesforce point is also critical. The built-in definition will match too much. You'll need a custom, tighter one, which is exactly where the maintenance treadmill starts.
Show me the bill
Totally agree about the logs lying, and it's the most corrosive part of the whole setup. You start distrusting your own telemetry.
It forces you into a weird meta-monitoring situation where you're not watching the traffic, you're watching the *policy* to see if it's still watching the traffic correctly. The tool built to reduce operational load suddenly creates a whole new layer of it.
That erosion of trust is permanent. Once you've been burned by a false green light, you'll never fully believe the dashboard again. You end up building a secondary, manual verification process with packet captures, which just recreates the overhead the ZTNA service was supposed to eliminate.
Try everything, keep what works.
You're right that it's tough to enforce granularly, but I'm skeptical about the "sleep on it" advice for Salesforce. That's where the most sensitive data usually lives. The trade-off isn't just visibility versus performance, it's performance versus liability. If you can't see the data export, you can't prevent it. That's not a trade-off, that's just accepting risk because the tool is too slow.
And the universal bypass with 'any' user? That's essentially turning off the security guard for everyone because the line at the metal detector is too long. Feels like you're solving a latency problem by deleting the security policy.
Beware of free tiers
You're focusing on the right policy pieces - Real-Time for 'Do Not Decrypt' and Private App for 'Direct' routing. The interaction is tricky because order matters: that Private App rule must sit *above* your general SaaS inspection policy, otherwise it never triggers.
But you've hit the core question: yes, this *does* break inline security for those apps. The moment you check 'Do Not Decrypt', it's a pure tunnel. No threat protection, no DLP, no data loss visibility for your Salesforce exports. For video conferencing, that's maybe fine. For a CRM full of customer data? That's a big risk acceptance.
Have you measured the actual latency overhead yet? Sometimes the perceived performance hit is worse than the real one.
✌️
You can technically do it, but you're trading one problem for a bigger one. The other comments on maintenance and false logs are dead on.
Has your team actually measured the "unacceptable" latency? Every time I've pushed for a bypass, the real performance hit was under 30ms. We were about to create a permanent security gap over something users wouldn't even notice.
trust but verify