FortiDDoS vs Dedicated DDoS Appliances: When a Firewall-Family Product Is and Isn't Enough

An enterprise that has standardised on the Fortinet Security Fabric approaches the DDoS question from a position most organisations would envy. The firewalls are consistent, the team is trained, the support relationship is established, and the procurement path is short. When a DDoS requirement appears — from a regulator, from an incident, or from a board that has read about a competitor’s outage — the obvious move is to extend what already exists rather than introduce a new manufacturer into the perimeter.

That instinct is frequently correct. This article is not written to talk anyone out of it. It is written because the decision is usually taken on the wrong grounds: either as an uninspected default (“we’re a Fortinet shop”), or on the back of an argument about firewall state tables that does not actually apply to the product being evaluated. Both routes can reach the right destination, and neither survives a serious architecture review.

What “extending the fabric” actually means

The phrase covers three materially different purchases, and the first task is to separate them, because they do not carry the same risk.

Turning on what you already own. FortiOS includes DoS policies and anomaly-protection features on the FortiGate itself — thresholds for connection rates, half-open sessions and malformed traffic. Every serious firewall vendor ships equivalent controls. They should be enabled, they are free, and they are not a DDoS mitigation layer.

Buying FortiDDoS. This is a separate appliance line, not a licence key on the firewall. It uses Fortinet’s custom silicon to inspect traffic at line rate and builds behavioural baselines with machine learning rather than relying primarily on static signatures. It is a purpose-built DDoS product built by a firewall vendor — which is a different thing from a firewall feature, and the difference is the whole substance of this comparison.

Buying a purpose-built appliance from another manufacturer. A separate device with an independent codebase, an independent detection engine, an independent support organisation and an independent contract.

Most of the debate in the market conflates the first and the second. Vendors selling against Fortinet find it convenient to do so, because the arguments against the first are strong and easy to make. They are also, when aimed at FortiDDoS, dishonest.

The stateful argument, and where it does not apply

The case against defending yourself with the firewall alone is well established and we have made it at length elsewhere, in the context of what it does to total cost of ownership. In short: a stateful firewall’s value comes from tracking sessions, state-exhaustion attacks target exactly that memory, and the firewall’s defences against exhaustion — SYN cookies, aggressive session ageing, connection-rate limits — consume the same CPU budget as the inspection work the device was bought to perform. A firewall that survives by shedding traffic indiscriminately has protected itself, not the estate.

That argument is sound, and it is an argument about the first purchase in the list above. It is not an argument against FortiDDoS.

FortiDDoS is engineered on the other side of the line. It is a dedicated device that sits in front of the stateful perimeter, uses hardware acceleration rather than general-purpose CPU to make per-packet decisions, and is designed to discard anomalous traffic without constructing a full session record for every flow. Fortinet’s investment in custom silicon is real, and its behavioural baselining approach — learning what normal looks like rather than waiting for a signature — is the same architectural philosophy the strongest purpose-built competitors use. An evaluation that treats FortiDDoS as though it were a firewall feature is evaluating a product that does not exist.

So the honest position is this: the stateful objection eliminates one option and does not distinguish between the other two. Whatever separates FortiDDoS from an independent purpose-built appliance, it is not the question of whether a dedicated layer is needed. Both answers agree that it is.

Where the architectural question actually lives

Once the firewall-feature option is set aside, the remaining differences are not primarily about packet processing. They are about what the two tiers of your defence share.

Almost every mature DDoS architecture is two-tiered: capacity upstream, in a carrier or cloud scrubbing service, for floods that would saturate the access circuit; and an always-on appliance at your own edge for everything below that line, where state exhaustion, protocol abuse and application-layer campaigns live. The upstream tier is usually not a free choice — it is whatever your carrier operates, or whichever cloud provider you contracted with.

The question that decides this purchase, therefore, is not “is FortiDDoS good?” It is: given what the upstream tier already is, does adding FortiDDoS produce two independent layers or one failure cause deployed twice?

This reframing has a consequence that vendors selling against Fortinet rarely acknowledge: for a large number of enterprises, adding FortiDDoS creates heterogeneity rather than removing it. If your carrier’s scrubbing service runs on a different manufacturer’s platform — which, in most markets, it does — then an on-premise FortiDDoS gives you two tiers built by different engineering teams on different codebases with different detection philosophies and different support organisations. That is precisely the property multi-vendor architecture exists to buy, and in that shape the Fortinet-standardised enterprise gets it for free while also keeping single-vendor operations at its own edge.

Conversely, if the plan is to source both tiers from the same manufacturer — whichever manufacturer that is — the resilience argument collapses regardless of how good the individual products are. That is a statement about architecture, not about Fortinet.

What a shared management plane buys

The operational case for extending the fabric is stronger than sceptics allow, and it should be stated without qualification before the costs are examined.

Correlated telemetry without an integration project. When the DDoS layer and the perimeter come from one vendor, the events they produce are designed to be read together. Attack traffic seen at the edge and its effect on the firewall behind it appear in one narrative rather than in two consoles with two clocks and two field naming conventions. Building that correlation across vendors is achievable — it is standard SIEM work — but it is work, and it has to be maintained through both vendors’ release cycles.

One skill set under pressure. The most under-priced factor in this decision is who is awake at three in the morning. An engineer who already understands one vendor’s policy model, log format and console conventions makes fewer mistakes during an incident than one switching between two. For a small operations team, this is not a convenience; it is a material reduction in the probability of a self-inflicted outage during mitigation.

Procurement and lifecycle economy. One support contract, one renewal calendar, one escalation path, one set of hardware lifecycle notices, one channel partner who already knows the estate. Multi-vendor advocates tend to treat these as trivial. They are not trivial to the people who administer them.

No inter-vendor blame. When something behaves unexpectedly at the boundary between two devices from different manufacturers, establishing whose problem it is consumes real hours. A single vendor removes that failure mode from the operational model.

None of these is a marketing claim. They are the ordinary reasons standardisation exists, and an organisation that has already standardised has already decided they are worth something.

What a shared management plane costs

The costs are of a different kind — lower frequency, higher consequence — which is exactly why they are systematically under-weighted.

Shared trust is shared exposure. The integration that makes the fabric convenient is a privileged trust relationship between devices. If it is compromised, it is compromised across the estate rather than at one device. This is the security cost of every management plane that spans multiple control types, and it applies to any vendor’s fabric, not Fortinet’s specifically.

Coupled change windows. Shared platforms tend toward shared upgrade cycles. A defect that forces an emergency patch, or an advisory that forces an unplanned window, touches more of the estate at once. The convenience of upgrading everything from one console is the same property that makes an upgrade problem broader.

Correlated commercial fate. Licensing model changes, renewal pricing, roadmap decisions, acquisition activity and export or sanctions exposure all land on the whole estate at once rather than on part of it. Fortinet is a United States company, so US export licensing and sanctions instruments apply to it — a fact of jurisdiction rather than a judgement about the company, and one that applies equally to several of its competitors. We treat that class of exposure separately in our vendor jurisdiction analysis; the point here is only that concentrating more of the estate under one legal regime concentrates that exposure too.

Negotiating position. At renewal, the counterparty knows your switching cost. This is the most reliably underestimated line in the single-vendor model, because it never appears as an incident — it appears as a price you accept.

The right way to weigh these is not to declare them decisive. It is to ask how much of the estate is already committed. An organisation whose firewalls, SD-WAN, endpoint agents and analytics platform are all from one manufacturer is not making a marginal decision when it adds the DDoS layer; it is deciding whether the last independent control becomes dependent too. An organisation running Fortinet firewalls alongside other vendors’ controls is making a genuinely marginal decision, and should treat it as one.

What neither option changes

One limit applies identically to both candidates, and stating it prevents a category of wasted evaluation.

Neither FortiDDoS nor any independent appliance can filter traffic that has already saturated the circuit delivering it. Above your access capacity the only thing that helps is capacity closer to the source. This is physics, not product differentiation, and any vendor conversation that blurs it should be treated as a warning sign. The comparison in this article concerns everything below that line, which is where state exhaustion, protocol abuse and application-layer campaigns actually operate.

How to test the difference instead of arguing about it

The architectural debate is worth having once. After that, it is a substitute for measurement. Four tests separate the candidates in ways no datasheet can.

Test the multi-vector case, not the single-vector case. Any credible product stops a clean SYN flood. What discriminates is a sustained state-exhaustion attack running simultaneously with a low-rate application-layer campaign that looks like real users. Run both at once, from separate sources, for long enough that behavioural baselines have to adapt under pressure rather than in laboratory conditions.

Measure legitimate completion, not attack blocking. The metric that matters is the proportion of genuine transactions that complete during mitigation — logins, checkouts, API calls, whatever your business actually does. “Percentage of attack traffic dropped” is close to meaningless, because dropping everything scores perfectly. Replay your own application traffic; synthetic floods alone will not surface the false-positive behaviour that decides whether your users notice the attack.

Test the failure of the thing that is shared. For a fabric extension, this means answering explicitly: what happens to mitigation if the shared management or analytics plane is unavailable? Does the appliance keep deciding on its own, or does it degrade? Ask the same question about any external intelligence feed a candidate uses: how does detection behave when the feed is stale, unreachable or restricted in your jurisdiction? Both questions have good answers in many products, but they are answers to obtain in a lab, not to accept in a meeting.

Count the events. During the attack, measure how many log lines each candidate generates and how many its downstream neighbours generate. An appliance that summarises an incident reports a manageable number; one that emits a line per dropped packet has moved your problem into the logging contract rather than solved it. This is measurable in an afternoon and it frequently changes the ranking.

Two procedural notes make these tests worth the effort. First, run the candidates against the same traffic on the same day with the same instrumentation — sequential tests against different backdrops produce numbers that cannot be compared. Second, write the results into the contract as acceptance criteria. A test that does not create an obligation is a demonstration.

Who should extend the fabric

The case for FortiDDoS is strong, and should be taken, when most of the following hold.

Fortinet is genuinely the estate standard rather than merely present, and the operations team’s fluency in it is real. The upstream scrubbing tier is provided by a carrier or cloud vendor that is not Fortinet, so failure independence already exists at the layer boundary where it matters most. The operations team is small enough that a second policy model is a meaningful burden rather than a rounding error. The organisation’s DDoS exposure is dominated by sub-saturating floods, protocol abuse and state exhaustion rather than by adversaries with a specific interest in your application logic. And no regulator or internal risk register currently tracks supplier concentration as an exposure requiring documented mitigation.

An organisation in that shape that buys a second manufacturer’s appliance is paying real operational cost for a resilience property it already possesses. That is a bad trade, and architectural purity is not a reason to make it.

Who should not

The case runs the other way when the following are true.

The upstream tier would also be Fortinet, or is likely to become so — in which case the two-tier architecture looks like two layers and behaves like one. Concentration risk is already a documented obligation, as it is for financial entities under DORA, where ICT third-party risk, a register of providers and documented exit strategies are explicit requirements. The Fortinet footprint across the estate is already broad enough that a supplier problem would be an outage rather than an inconvenience, making the DDoS layer the increment that tips the balance. The requirement is multi-tenant — a service provider protecting customers under separate profiles on shared hardware and billing for it — which is a distinct architectural need rather than a scaling of the enterprise case. Or the deciding requirement is application-layer depth delivered in the same device that handles volumetric and protocol floods, without adding further ecosystem components to reach it.

Where those conditions hold, the criteria to put in the RFP are the ones already stated above rather than a brand: an independent codebase and detection engine, no dependence on a vendor-operated intelligence cloud for core detection, full Layer 3–7 coverage in a single device, and a commercial and jurisdictional exposure that differs from the upstream tier’s. Appliances built to that specification exist — HARPP DDoS Mitigator meets those four criteria, and others can be assessed against the same list, which is deliberately vendor-neutral and should be written into the RFP in that form.

For organisations already committed

Most readers of this article are not making a first purchase. They already run Fortinet at the perimeter and are deciding whether to extend or diverge, often under time pressure from an incident.

The wrong move is to dismantle a working architecture in haste. The right move is to establish which tier is more exposed to the concentration problem, and to change that one at its next renewal rather than immediately. In most enterprise estates the on-premise tier is the one the organisation actually controls — the upstream tier is inherited from the carrier — so if divergence is warranted, that is where it belongs, and the renewal calendar tells you when.

And if the analysis says extend, extend without apology. The single most common failure in this decision is not choosing the wrong vendor; it is spending two quarters debating architecture while the estate remains defended by flood thresholds on a firewall. Either dedicated layer is dramatically better than that, and the difference between them is smaller than the difference between having one and not.

Sources and further reading

We do not paraphrase paywalled analyst research or attribute figures to it. The list below is what to read, and what to ask a vendor to produce.

Vendor documentation. For any specific claim about FortiDDoS capability, deployment mode, fabric integration, licensing or capacity, the authoritative source is Fortinet’s own Document Library — the administration guide and release notes for the exact model and firmware version being quoted, not a datasheet or a partner summary. Product capabilities change between releases; a claim that cannot be located in the documentation for the version you would deploy should not enter the evaluation.

Standards and public technical guidance. RFC 4987 on TCP SYN flooding attacks and common mitigations, for the mechanics of the state-exhaustion class. RFC 9132 and RFC 8811 for DOTS — the signal channel specification and the architecture respectively — which define how a mitigation request is passed between tiers when both ends support it. RFC 8955 and RFC 8956 for BGP FlowSpec, and RFC 5635 for remotely triggered black hole routing, for the upstream signalling mechanisms most carriers actually accept. NIST SP 800-189 for resilient interdomain routing practice.

Regulation. DORA (EU 2022/2554), in particular the provisions on ICT third-party risk, concentration risk and exit strategies, which give the concentration argument a vocabulary auditors recognise. NIS2 (EU 2022/2555) for supply chain security among its risk management measures — noting that it does not establish a concentration-risk and exit-strategy regime of DORA’s kind, and claiming otherwise produces a rationale that will not survive audit.

Analyst coverage of the category. Gartner covers this market in its Market Guide for DDoS Mitigation Solutions; Forrester has published The Forrester Wave: DDoS Mitigation Solutions; IDC publishes an IDC MarketScape for the segment. Request the current edition directly rather than accepting a screenshot. Note that Gartner restricts public quotation of its research: a vendor quoting it on a public web page should hold reprint rights, and it is reasonable to ask to see them.

The three options, side by side

Appliance	What it actually is	Behaviour under state exhaustion	Independence from the rest of the estate	Operational load	Where it fits
FortiGate DoS policies alone	Self-protection features on the stateful firewall you already own	The device defending itself is the device under attack	None — it is the same box	Lowest; no new platform	A baseline, not a mitigation layer
FortiDDoS	A separate purpose-built appliance with its own hardware acceleration and behavioural baselining	Designed to absorb the attack in front of the firewall	Separate device; shared vendor, roadmap and commercial relationship	Low if the team already runs Fortinet	Fortinet-standardised estates whose upstream tier is a different vendor
Purpose-built appliance from another manufacturer	A separate appliance with an independent codebase and detection engine	Designed to absorb the attack in front of the firewall	Independent code, detection logic, support organisation and contract	Higher; a second policy model and console to learn	Estates where both tiers would otherwise share one failure cause, or where concentration is already on the risk register

The first row is not a criticism of Fortinet — every stateful firewall vendor ships equivalent self-protection features, and they are worth enabling. The point is that they are a different category of control from the second and third rows.