Fortinet vs Cisco for mid-market firewall: which has better throughput?

I'm Ella West, an identity and security architect for a 700-person healthcare services firm. We standardized on Fortinet three years ago and our main production NGFW is a FortiGate 601E cluster handling our MPLS edge and user VPN, so throughput under full inspection is a daily reality.

* **Real Cost of Performance:** The datasheet gap OP noted is real. Fortinet's ASICs deliver a predictable performance floor with services on. That 600E will reliably hit 800+ Mbps in production with full UTM. The comparable Cisco box, once you turn on Snort 3 with SSL inspection, often needs to be spec'd up a model to meet the same requirement, adding 15-20% to the hardware SKU cost before subscriptions.
* **Operational Complexity:** The Firepower Management Center (FMC) model is a separate appliance or VM license. For a single 1140, you'll likely use FDM (on-box). Policy changes, especially involving SSL decryption profiles, took 45-90 seconds to commit and push in my last Cisco environment. A comparable FortiGate change commits in 3-5 seconds. This matters during incident response or rapid policy tuning.
* **The Hidden Throughput Killer - SSL Inspection:** Both vendors' SSL inspection cripples throughput if not tuned. Cisco's default decryption policies historically had more overhead per session. Fortinet allows you to offload TLS 1.2 RSA to the CP7 ASIC. The practical result: with 100% TLS 1.3 traffic (which can't be offloaded), the throughput delta between the two narrows considerably. If your app mix is >50% TLS 1.3, halve the marketing number for both.
* **Support and Firmware Stability:** Fortinet's TAC gets you to an engineer quickly, but the quality tiering is real. With a 24x7 contract, we get a dedicated engineer. Their firmware release notes are honest about known issues. Cisco's support is structured, but I've seen more "blame the config" initial responses. The critical detail: you must track firmware compatibility matrices for FMC, Firepower software, and the underlying ASA OS - a three-layer dependency that complicates patching.

I'd recommend the FortiGate for any mid-market shop where a lean team needs predictable throughput with every security service turned on and can't afford speculative over-provisioning. If your primary constraint is deep integration with a Cisco ISE/AnyConnect environment already in place, or your security team has deep Cisco CLI muscle memory, then the 1140 is defensible. Tell us which specific Layer 7 inspection profiles you're mandating and whether you're already using Cisco for switching/wireless, and the call gets clearer.

Your point about policy commit times is critical and often overlooked in spec sheet comparisons. A 90-second commit delay doesn't just slow changes; it introduces a tangible risk during security incidents where rapid isolation is required. I've observed this in environments using FMC for distributed policies, where a single change queue can compound the delay across multiple firewalls.

On the SSL inspection performance hit, I'd add that the methodology for SSL inspection itself differs between the two, impacting throughput stability. Fortinet's flow-based inspection with ASIC offloading for the initial handshake tends to maintain a more consistent throughput under load. Cisco's Snort 3, while more powerful in signature depth, is fundamentally CPU-bound on most mid-range appliances, leading to variable latency and packet drops as session counts scale. This is where the need to "spec up" truly bites, as you noted.

Have you compared the resource overhead between the two when using TLS 1.3? The partial inspection methods required can further widen the performance gap.

Spot on about the commit times. That's what pushed my team to Fortinet last year. We had a minor breach drill where we needed to isolate a subnet, and the 90-second FMC delay felt like an eternity.

The ASIC advantage really shows under load. Even with our peak traffic, the performance drop with SSL inspection enabled is predictable, maybe 15%, not the 50%+ swings we saw during our Cisco proof-of-concept. It just handles the crypto differently.

You've hit on the key operational metric that often gets lost in the throughput discussion: policy commit time. The difference between 90 seconds and 3-5 seconds isn't just about convenience, it fundamentally changes how you approach network changes and security posture tuning. It encourages more iterative, low-risk policy refinement because the feedback loop is so much shorter.

Regarding the ASIC performance floor, that predictability is exactly what matters for capacity planning. With a CPU-bound architecture, you're not just looking at a performance hit, you're managing a variable load that can spike unpredictably. The FortiGate's consistent 15% drop you observed under SSL inspection is a known quantity you can design for, whereas the CPU-based alternative introduces a scaling variable that's harder to model, often requiring over-provisioning.

One caveat on the SSL inspection point is that the performance impact can also depend heavily on the cipher suites negotiated. Some modern, more complex ciphers can shift more work back onto the CPU, even with ASIC offload, so your traffic profile's specific TLS parameters are still a factor.

Your breach drill scenario perfectly illustrates the business risk hidden in operational metrics. That 90-second delay isn't just a performance figure, it directly translates to mean time to containment during an incident.

The predictable 15% drop you measured is key. I've benchmarked this repeatedly, and the consistency stems from the ASIC handling the TLS handshake and packet ciphering. On CPU-based platforms, the performance degradation isn't linear; it's logarithmic as session counts rise. You'll see minimal impact at 1,000 sessions, but at 50,000 concurrent SSL sessions, throughput can collapse by 70% or more. That's the scaling variable no datasheet captures.

It forces a different capacity planning model: with Fortinet, you subtract a fixed percentage; with others, you must model for peak concurrent encrypted sessions, which is often an unknown.

Your lab methodology is sound, focusing on the 1KB average packet size is the right call, as that's far closer to real web traffic than the jumbo frames used in marketing specs. I'd be curious about the session scale you used, as that's where the ASIC advantage becomes more pronounced.

The ~850 Mbps you measured for the 600E aligns with what I've seen in audits, but there's a caveat with the SSL inspection number. The performance hit is heavily dependent on the specific cipher suites negotiated. If your test clients favored AES-GCM, the CP7 ASIC handles that in silicon with minimal impact. If you had a significant portion using ChaCha20-Poly1305, which is still software-processed even on Fortinet's hardware, you'd see a steeper drop. Did you control for that variable?

>the performance degradation isn't linear; it's logarithmic

But you're still locked into their hardware roadmap to get that ASIC benefit. Want a new feature? Wait for the next silicon refresh. Meanwhile, a decent software platform on modern x86 will scale predictably enough for 99% of mid-market shops if you just throw more cores at it.

That session scale collapse at 50k is real, but how many firms actually see that on a single mid-range box? You'd be pushing other limits first. It's a theoretical edge case sold as a daily crisis.

That's super useful, thanks for running actual numbers. The 850 Mbps vs 620 Mbps gap is bigger than I expected for that tier.

But I'm a bit lost on the lab setup part. When you say 1KB average packet size, how do you control that across different traffic types? Is there a tool that simulates that mix automatically, or did you have to build the test profiles yourself? Asking because I'm trying to learn how to do this for our own network.

Those numbers line up with our real world benchmarks almost exactly. The ASIC advantage is real at this scale.

One caveat on your lab mix: the 10% database replication traffic might be skewing things slightly if it's large sequential transfers. That tends to be larger packets, which can inflate the overall average throughput in a way that doesn't reflect the more punishing reality of pure web traffic.

Still, the ~230 Mbps delta you found is the story. That's the headroom for growth, or the buffer for when traffic patterns inevitably change.

Your 1KB packet size is the only realistic way to test. Good on you for ignoring the jumbo frame nonsense.

But the ASIC advantage everyone's gushing over has a massive asterisk. It only matters if you're running the exact traffic it's optimized for. Throw a new protocol, a different cipher suite, or a novel attack pattern at it, and you're back to software processing on an underpowered CPU core. That predictable 15% drop can become a 60% cliff real fast.

Also, 850 vs 620 Mbps looks decisive until you price in the 5-year TCO with licensing. Fortinet's performance per dollar shrinks when you factor in the mandatory subscriptions to make the box actually useful. A lot of that Cisco delta could be spent on a bigger model instead.

That's a really clear breakdown, thanks for sharing your numbers. The 850 vs 620 Mbps gap is pretty stark.

I have a basic question though. You mention the ASIC advantage, but how does that work with software updates? If Fortinet pushes a new security feature or detection method, does it still run on that ASIC or could it fall back to the CPU and tank performance? I'm just trying to understand if that hardware benefit is locked to today's threats.

That's a really good question, and something I've wondered too. I think it depends on the type of update. For new deep packet inspection signatures, I *think* they still run on the ASIC because it's just matching patterns. But for a whole new protocol or a totally new kind of threat detection, it might have to run on the general CPU until the next hardware generation.

It makes me nervous to invest in hardware that might be outdated by a new attack method. I guess you'd have to check their update history to see how often they add features that require newer models. Does anyone have experience with that?

Interesting numbers, but I'm skeptical about that "identical conditions" claim. Did you match the IPS policy rule count and complexity exactly between platforms? Fortinet's baseline inspection might use broad signatures, while Cisco's could be more granular by default. A 20-rule policy vs a 200-rule policy will skew those results, and vendors never ship identical default configs.

Also, your traffic mix includes 20% VoIP. If you didn't have SIP ALG or specific VoIP inspection profiles enabled, you're giving the FortiGate a free pass on a chunk of traffic. That ASIC isn't breaking a sweat on those RTP streams. The delta might tighten if you force it to do full application control on the VoIP traffic too.

What was the warm-up time for each test? Cisco's software architecture sometimes needs a few minutes to stabilize performance after a policy push, while Fortinet's hardware kicks in immediately. If you measured throughput in the first 60 seconds, you might have caught the Firepower during its software tax.

The CP7 ASIC is the differentiator, full stop. That's where the extra 200+ Mbps comes from. But that advantage disappears if you're using SD-WAN or ZTNA features heavily, since those aren't offloaded the same way. You'd see the Cisco gap close fast.

Also, did you test failover? FortiGate's session pickup is faster, but Cisco's failover is more deterministic in my experience.