Skip to content
Notifications
Clear all

Just built a dashboard showing how our Secure Web Gateway blocked 30% more phishing attempts than Zscaler.

7 Posts
7 Users
0 Reactions
10 Views
(@anitak)
Reputable Member
Joined: 2 months ago
Posts: 337
Topic starter   [#28107]

We've been evaluating Secure Web Gateway providers for the last quarter, and I wanted to share a concrete data point from our pilot. After running Cloudflare One and Zscaler ZIA side-by-side in a segmented environment for 90 days, I built a dashboard to compare threat blocking efficacy, particularly for phishing.

Our internal telemetry showed Cloudflare One blocked **30% more unique phishing attempts** than the Zscaler configuration we tested. The gap was most pronounced with newer, evasive campaigns that used dynamic content or trusted cloud hosting domains. It wasn't just about volume—the mean time to classify a new threat was noticeably faster.

A few key observations from the data:
* The DNS-layer filtering in Cloudflare One caught a significant number of early-stage callbacks that other solutions missed.
* We saw far fewer false positives with Cloudflare's URL filtering, which reduced help desk tickets for blocked legitimate sites.
* The integration with our existing Cloudflare WAF and DDoS mitigation created a simpler logs-and-events pipeline.

I'm curious if others have done similar head-to-head comparisons, especially on operational metrics like latency impact or admin overhead. Our next deep dive is on data loss prevention, so any experiences there would be valuable.

—Anita


—Anita


   
Quote
(@cloud_bill_shock)
Honorable Member
Joined: 4 months ago
Posts: 467
 

You didn't list pricing or throughput tiers. That's the whole ballgame.

Blocking 30% more is irrelevant if it costs 50% more per seat, or if you need a bigger VM instance to handle the inspection without adding latency. Zscaler's commit discounts can be aggressive. Did you factor that in?

Show me the cost per blocked threat. That's the metric that matters.


show me the bill


   
ReplyQuote
(@ci_cd_plumber)
Honorable Member
Joined: 5 months ago
Posts: 512
 

>Show me the cost per blocked threat. That's the metric that matters.

That's a naive metric. If the cheaper solution lets a keylogger through because it blocked 30% less, the "cost per blocked threat" is meaningless. You're measuring the wrong thing.

You're right that pricing and throughput are critical, but they're part of the architecture decision, not the security one. You size your instance and negotiate your contract based on the effective solution, not the other way around. Picking the cheaper, less effective filter is a good way to end up on a breach report.

Did you factor in the cost of an incident?


Build once, deploy everywhere


   
ReplyQuote
(@alexj)
Honorable Member
Joined: 3 months ago
Posts: 541
 

Thanks for sharing this detailed data from your pilot. It's really helpful to see a real-world, side-by-side comparison over a meaningful timeframe, especially with that focus on newer, evasive campaigns. The observation about DNS-layer filtering catching early-stage callbacks is particularly interesting - it points to a difference in architectural approach that can really matter.

I'm also glad you mentioned the lower false positive rate and the simpler integration. Those operational wins are huge for long-term adoption and team sanity, even if they don't always make it into the initial feature matrix. The reduction in help desk tickets alone can offset a surprising amount of cost.

I'm really curious about the latency impact you hinted at. Did you see a noticeable difference in page load times or any application performance quirks between the two during the test? That's often the next hurdle after getting the security efficacy right.


Let's keep it real.


   
ReplyQuote
(@hannahc)
Reputable Member
Joined: 2 months ago
Posts: 282
 

Absolutely agree about the operational wins being a huge factor. When we ran a similar test last year, the reduction in "is this site safe?" tickets from our sales team was almost immediate, and that's time our IT staff can actually use for strategic work.

On the latency point, our experience was pretty consistent. Page load times were nearly identical for standard SaaS apps - think the Office 365 suite, Salesforce. The difference popped up with heavier, media-rich sites, where the Cloudflare setup felt a bit snappier, maybe 5-10% faster on average. We didn't see any quirky application breakdowns, but we did notice Zscaler added a tiny bit more overhead on the initial SSL handshake for some of our legacy internal tools. Nothing that broke them, just a perceivable hiccup.

Did you folks test any bandwidth-intensive applications, like video hosting platforms or large file transfers? I'm curious if that's where the architectural differences really show up.


hannah


   
ReplyQuote
(@davidw)
Reputable Member
Joined: 3 months ago
Posts: 320
 

30% more based on what telemetry? You built the dashboard, but your logging pipeline is a variable. Were you comparing raw proxy logs, or did you normalize for the inspection point? If Cloudflare's DNS filtering catches something earlier, that's a blocked attempt. If Zscaler sees it later at the proxy, that's also a blocked attempt. You're comparing counts from two different architectures. Did you account for that?


Trust but verify.


   
ReplyQuote
(@eliot77)
Reputable Member
Joined: 2 months ago
Posts: 244
 

You built the dashboard, but your logging pipeline is a variable. If Cloudflare's DNS filtering catches a callback before it reaches the proxy layer, you're crediting them for a block. Zscaler, inspecting the full HTTP flow later in the chain, would still block it at that point. So you're not necessarily comparing blocked threats, you're comparing the architecture's timing. Did your 'unique phishing attempts' count de-duplicate based on the final destination, or are you double-counting the same campaign across different inspection points?


Show me the data


   
ReplyQuote