That 80-120ms hit others are mentioning is no joke. We saw the same thing in our testing with a PACS web viewer, and the clinical feedback was instant.
Zscaler's API was definitely easier for scripting policies, but we couldn't get past the performance penalty for internal clinical apps. It forced us into planning those carve-outs, which feels like a step back from the "non-negotiable" Zero Trust goal.
How are you planning to test the actual imaging app flows? A sandbox didn't cut it for us, we had to do a limited live pilot with one clinic.
Your point about the limited live pilot being necessary resonates strongly. We observed the same limitation with synthetic sandbox testing, as it failed to capture the variable packet sizes and persistent TCP connections inherent to real PACS workflows. The latency isn't just a flat 80-120ms add, it manifests as jitter during sequential image retrieval, which is what clinicians find disruptive.
We implemented a structured pilot similar to yours, but instrumented it heavily. We deployed a lightweight exporter on the clinical workstations to capture not just ICMP latency, but TCP connection establishment time and TLS handshake duration specifically to the PACS frontends. This granular data was crucial for justifying the carve-out architecture to our security committee. It moved the conversation from subjective complaints to objective metrics showing that the Zero Trust proxy was introducing over 300ms of additional handshake time per new study retrieval.
How did you structure the success criteria for your pilot? We defined a specific performance service level objective, like "95th percentile of image load completion times must remain under 2 seconds," which created a clear binary pass/fail for the full proxy model.
That exact instrumentation is the only way to get a real answer. Everyone just talks about RTT, but the TLS handshake and session resumption penalties are what kill the user experience.
But you're just proving my point. You spent all that effort on a pilot to gather data to justify... bypassing the gateway. All this to end up back at "carve out the critical stuff."
We set a similar SLO: sub-second 95th percentile for first image in a study. Zscaler failed it. So we didn't bother with a fancy carve-out justification. We just kept that traffic local from day one. Sometimes you don't need a committee, you just need to accept that your "non-negotiable" policy is wrong for some workflows.
Simplicity is the ultimate sophistication
I can share our terraform module structure for Zscaler policies since you asked about API scriptability. We treat each major rule category - DLP, app control, URL filtering - as its own module with version pinning. The critical part for healthcare is tagging every resource with the compliance framework, so you can run a `terraform state list` and audit exactly which rules apply to PHI.
But as others have hit on, that nice automation doesn't matter if the clinical teams revolt over latency. Our PACS traffic had to be carved out via a separate forwarding profile, which means those images aren't getting "deep inspection". So much for non-negotiable.
For medical IoT, forget policy-as-code elegance. You'll be maintaining a giant, manual bypass list of static IPs that never gets inspected. Both platforms handle it poorly.
Automate everything. Twice.
The bypass list for medical IoT is the real killer. We versioned ours in a separate git repo too, but it's just a static JSON file that gets shoved into both platforms via their clumsy APIs. It's pure configuration drift waiting to happen, completely detached from any actual device inventory.
So you end up with two parallel truths: your beautiful, auditable Terraform state for the "negotiable" traffic, and a brittle mess for the things that arguably need the most scrutiny.
Build once, deploy everywhere
Both platforms will force you into those IoT bypass lists, which honestly breaks the whole "non-negotiable" premise. We manage ours in Git too, but it's just a ticking time bomb for config drift.
The real decision is which problem you want more: a slick API for your non-clinical traffic (Zscaler) versus potentially better local performance for imaging apps (Cisco). But that performance only holds if you keep that traffic local, which means it's not inspected.
Have you modeled the egress costs for Zscaler yet? That's often the hidden deal-breaker for high-volume clinical data flows, not just the latency.
Cheers, Henry