Two Layers, Two Vendors: Sourcing ISP and On-Premises DDoS Mitigation from Different Manufacturers

Executive Summary

There is near-universal agreement in enterprise DDoS defence today: a single layer is not enough. Cloud-scale scrubbing capacity positioned at the ISP must work alongside an on-premises mitigation appliance positioned at the enterprise edge. The debate begins after that point, and it usually comes down to one question: should these two layers be products from the same manufacturer, or from different ones?

The prevailing procurement reflex favours a single vendor. The reasons are familiar: easier integration, a single support contact, a single training cost, a bundle discount. None of these reasons is wrong — but all of them are line items in operational convenience. What choosing different vendors buys, by contrast, is not convenience but organisational resilience — and resilience is the entire reason DDoS defence exists.

The thesis of this article is straightforward: sourcing the ISP and on-premises DDoS mitigation layers from different manufacturers is not a cost to be tolerated but a resilience property to be deliberately purchased.

Three arguments carry the thesis, each flowing directly from the vendor choice and together forming the centre of gravity of this article: breaking the common-mode failure that arises from shared code and a shared management plane (Section 3), distributing the vendor concentration risk created by binding both layers to a single manufacturer (Section 5), and gaining carrier independence by decoupling the internal architecture from the ISP’s own procurement decisions (Section 6). Two supporting benefits — in detection coverage and in organisational capability — are added to these.

One distinction must be drawn up front, in the interest of intellectual honesty. The benefits that arise from the two layers occupying different positions with different levels of visibility — the carrier backbone stopping a volumetric flood upstream, the on-premises appliance seeing session state and application behaviour — are benefits of hybrid architecture, and they are obtained in a same-vendor hybrid deployment as well. This article does not present them as evidence for its thesis. What vendor diversity adds, within that same architecture, is that the layers fail independently of one another and that the enterprise is not locked into a single commercial relationship.

---

1. The Threat Landscape: Context for the Decision

The scale of DDoS attacks has changed in kind over the past two years, not merely in degree. Public records for the largest volumetric attack are now broken in months rather than years, and each new peak tends to be set by a botnet family that was already operating near that level shortly before. The precise figure at the top of the curve matters far less than its slope, because the record never has to reach you to be relevant. What reaches you is bounded by your own access circuit; the slope tells you how little effort it now takes for an attacker to exceed it.

More consequential than any single record is frequency. Terabit-scale events have stopped being an exceptional class of incident and have become a recurring one, generated at machine speed by botnets assembled from large populations of compromised devices, inside windows that leave no room for a human decision. Law-enforcement action against that infrastructure is real and worth having, but the pattern is consistent enough to plan around: operators are replaced faster than the capability ceiling falls, and it is the ceiling, not the current occupant, that your design has to assume.

Running in parallel is a movement toward precision at the other end of the spectrum. Application-layer and API attacks are engineered specifically to stay below volumetric thresholds. Login flows, authentication endpoints, cart and checkout paths are targeted, and the traffic is generated with browser-grade HTTP/2 requests, realistic cookies and randomised timing intervals. A campaign of that shape is effectively invisible to detection logic tuned to bandwidth saturation, which is how a defence sized entirely against volume can be fully operational and still fail. For current measurements of this shift, read the quarterly DDoS reports the large mitigation providers publish — and read each one as a sample of that provider’s own customer base rather than as a census.

The implication for decision-makers is this: DDoS defence is now the sole guarantor of the enterprise’s internet reachability, and the interval between the start of an attack and its full impact has fallen below the human decision cycle. Binding a function of that criticality entirely to one vendor’s codebase, one detection philosophy, and one commercial relationship creates an organisational risk that originates in the defence itself. The remainder of this article examines that risk and how to distribute it.

---

2. The Benefit of Hybrid Architecture vs. the Benefit of Vendor Diversity: A Clear Separation

The most common error in the multi-vendor debate is presenting the benefits of hybrid architecture as if they were benefits of vendor diversity. Drawing this distinction up front is necessary both for the honesty of the argument and for ensuring the decision is made on the correct grounds.

Benefits derived from position — independent of vendor. Scrubbing capacity in the carrier backbone can stop an attack saturating the enterprise access circuit upstream of that circuit; the on-premises appliance cannot, because by the time the attack reaches it the pipe is already full. Conversely, the on-premises appliance sees every packet at line rate, maintains session state, and holds the behavioural baseline of the application; the carrier platform, working from sampled flow data, does not have that visibility. This complementarity is real and important — but it arises entirely from position and data source. A hybrid architecture built from two products of the same manufacturer delivers it too.

Benefits derived from independence — obtainable only with different vendors. That the two layers do not fall simultaneously to the same software defect, do not share the same detection blind spot, are not hit at once by the same supplier crisis, and that the enterprise holds a genuine alternative at every renewal — none of this comes from position. It comes only from building the two layers on different engineering teams, different codebases, and different commercial relationships.

This article argues for the second set. The first is taken as already established.

---

3. First Argument: Breaking Common-Mode Failure

One of the foundational principles of reliability engineering is that redundant components provide redundancy only when they are independent. If two components share a failure cause, the probability of both failing is not meaningfully lower than the probability of either one failing alone. This is known as common-mode failure, and it is a first-class constraint in critical system design.

The aviation analogue is instructive. Flight control computers in modern airliners are not merely redundant but dissimilarly redundant: processors from different manufacturers, running software written by independent teams and often in different programming languages. The rationale is exactly the rationale here — three copies of the same software carry the same logic error three times. Increasing redundancy is not a matter of multiplying the count; it requires diversifying the failure cause.

In DDoS architecture, choosing a single vendor produces precisely a common-mode failure. When both layers come from the same manufacturer, they share the following.

The same codebase, and therefore the same vulnerabilities. DDoS mitigation appliances are, by definition, the devices that first encounter and most deeply parse the most hostile traffic the enterprise sees. A defect in that parsing logic — a malformed header that locks the parser, a particular tunnelling combination that drives resource exhaustion — is present identically in both layers. When an attacker triggers it, both layers of the defence go down simultaneously and for the same reason. With different vendors, the probability of the same exploit existing in both manufacturers’ code is markedly lower.

An honest caveat belongs here: vendor diversity does not eliminate shared vulnerability. HTTP/2 Rapid Reset (CVE-2023-44487) demonstrates this clearly; the flaw was not in any one vendor’s code but in the protocol itself, and it affected nearly every HTTP/2 implementation simultaneously, regardless of manufacturer. Similarly, different vendors may still share the same operating system kernel, the same cryptographic libraries, the same packet-processing frameworks, and the same silicon suppliers. What vendor diversity removes is the vendor-specific vulnerability class — which accounts for the majority of incidents that actually occur. Against protocol-level flaws, protection comes not from architecture but from a fast patching process and policy flexibility at the protocol layer.

The same detection logic, and therefore the same blind spots. Every detection engine has a “statistical worldview”: what it treats as normal, which metrics it baselines from, and over what window it decides. The attack patterns that worldview misses are that engine’s permanent blind spots. Deploying the same engine twice deploys the blind spot twice.

This is visible in concrete form in the platform family most widely deployed on the carrier side. NetScout Arbor products draw a significant part of their detection quality from the cloud-delivered ATLAS threat intelligence feed. When an enterprise buys Arbor-based scrubbing from its carrier and then places an appliance from the same family on premises, the two layers share not only a detection logic but an intelligence source. If the feed is interrupted, updated late, or restricted in a given jurisdiction, both layers go blind at the same moment for the same reason. An on-premises layer that runs its own detection engine without depending on a central feed is the design choice that breaks this dependency.

The same management plane, and therefore the same lateral movement path. In single-vendor architectures the two layers are typically joined through a common management and orchestration plane, common authentication infrastructure, and a mutually trusted signalling channel. This is operationally elegant; from a security standpoint it means a compromise of the management plane on the ISP side finds a trust relationship reaching into the enterprise. With different vendors, the inter-layer bond is not a proprietary, broadly privileged trust relationship but a narrow, standards-based signalling interface.

The same supply chain and the same commercial fate. When software components, threat intelligence feeds, the support organisation, and the company’s own commercial future are identical, a problem at any link in the chain affects both layers. This dimension is treated separately in Section 5.

Stated at the executive level: a single-vendor DDoS architecture is a defence that looks like two but behaves as one bound to a single failure cause. Investing in two layers does not mean the risk has been distributed across two layers.

---

4. Second Argument: Broader Detection Coverage

This is the second-order but concrete benefit of vendor diversity. Framing the argument correctly matters, because faulty mathematics is frequently applied in this area.

On the miss (false negative) side, the gain is real but bounded. If the miss behaviour of two detection engines were fully independent, the probability of both missing would equal the product of their individual rates. In practice, full independence does not exist: both engines observe the same attack traffic and draw on similar literature and similar commercial threat feeds. The product rule is therefore not an achievable outcome but a theoretical lower bound. The realistic expectation is that different vendors reduce — not eliminate — detection correlation, pulling total miss rate meaningfully below the individual rate. With two copies of the same engine, that gain is exactly zero.

This benefit is most concrete in the regions where the attack classes covered by the two layers do not fully overlap: short-lived bursts, unusual protocol combinations, novel reflection vectors, and low-volume multi-source campaigns. Here the differences in the two manufacturers’ research teams, sensor networks, and customer bases translate directly into detection coverage — a new vector one vendor has not yet observed may already be in the other’s feed. For this to become real value in the architecture, however, the threat feeds must not stay confined to their own layers: alerts from both layers must be consolidated into a common observability layer. That is not something the architecture provides on its own; it is a capability that must be designed in.

On the false positive side the argument runs the other way, and this should be stated plainly. The two mitigation layers are connected in series: traffic passes first through carrier scrubbing, then through the on-premises appliance. In a serial chain, a false positive from either layer is sufficient to block legitimate traffic; total false positive rate therefore accumulates above the individual rates. This is the intrinsic cost of adding a layer, and vendor diversity does not reduce it.

The correct design response is to make the aggressiveness of the two layers independently tunable. With different vendors, the enterprise can partition the problem so that the carrier layer engages only at volumetric thresholds with conservative policies, while fine-grained decisions are left to the on-premises layer that understands the application. This partitioning is possible in single-vendor architectures too; but a shared policy model naturally nudges teams toward comparable aggressiveness settings in both layers.

Vendor diversity’s real contribution on the false positive side lies not in real-time mitigation but in post-incident analysis. Comparing the decisions two independent systems produced during the same incident reveals which layer misclassified which traffic, and on what grounds. That comparison is never available in a single-vendor architecture, because there is no second independent view to compare against.

---

5. Third Argument: Managing Vendor Concentration Risk

This argument is not technical but belongs squarely to enterprise risk management, and it is the one most easily defended at board level.

Binding to a single manufacturer at both the carrier and the internal layer creates a classic vendor concentration risk. The paths by which this risk materialises are varied, and none of them is hypothetical. The manufacturer may be acquired and the product line discontinued. The licensing model may be changed unilaterally; renewal may bring steep price increases. The manufacturer may become unable to supply product or support to particular geographies because of export controls, sanctions, or geopolitical developments. A critical product may suffer a prolonged quality problem. The manufacturer itself may suffer a security breach.

In each of these scenarios the single-vendor enterprise has exactly one option: carry the risk until the migration is complete. And in DDoS defence, migration is measured in months — it requires appliance procurement, redesign of the routing and signalling architecture, re-tuning of policies, and rebuilding team capability. The multi-vendor enterprise, facing the same scenario, keeps at least half of its defence intact and executes the migration on a plan rather than under crisis pressure.

The same structure produces direct leverage in commercial negotiation. Running the two layers under separate contracts, on separate renewal calendars, with separate manufacturers means the enterprise holds a genuine alternative at every renewal. In a single-vendor architecture, the renewal negotiation is one in which the counterparty knows precisely what the enterprise’s switching cost is. The monetary magnitude of this difference varies by organisation and market; what is clear is that the decision should be made not on first-year purchase price but on total cost of ownership across the contract period and the monetised value of the outage risk being carried.

There is regulatory movement in the same direction, though it is important not to overstate it. In financial services, DORA (EU 2022/2554) explicitly requires identification of ICT third-party risk, maintenance of a register of information on providers, assessment of concentration risk, and documented exit strategies for critical services — obligations that have a specific reading for a control sitting in the traffic path. NIS2 (EU 2022/2555), while listing supply chain security among its risk management measures, does not establish a defined concentration-risk and exit-strategy regime of DORA’s kind. At the national level, information security regulations for critical infrastructure and public institutions are likewise giving increasing attention to supplier dependency.

None of these regulations mandates a multi-vendor DDoS architecture, and claiming otherwise produces a rationale that will not survive audit. What the regulatory framework provides is not an obligation but a vocabulary and a legitimacy foundation: because concentration risk is a recognised risk category, an enterprise that carries “both layers of the same defence function are bound to a single supplier” as an explicit entry in its own risk register, and diversifies on that basis, converts the decision from an arbitrary preference into an established risk management practice.

---

6. Fourth Argument: Carrier Independence and Architectural Flexibility

This is the least contestable part of the thesis, and in practice the point enterprises most often recognise too late.

The brand of the on-premises appliance is the enterprise’s own decision and stays with the enterprise. The brand behind the ISP’s scrubbing service is not the enterprise’s decision — whatever platform the carrier operates is what the enterprise consumes. In inheriting that choice, the enterprise unwittingly binds its own data centre architecture to a supplier relationship it did not select.

The cost of that binding surfaces whenever the architecture must change. Carriers replace their scrubbing platforms; the enterprise may need to work with a second carrier; subsidiaries in different countries may use different carriers; a carrier change may arise from cost or service quality. If the on-premises layer is a vendor independent of the carrier, none of these changes resets the enterprise’s defence policy, application profiles, or the operations team’s way of working. The policy backbone stays in place.

This should not be read as “change is free.” A carrier migration is serious engineering work under any architecture: new BGP sessions, rebuilding the prefix advertisement and community scheme, re-establishing return-path tunnels, negotiating new service level commitments, re-tuning thresholds, and running the exercise programme again from the start. The difference is this: in a multi-vendor architecture that work stays confined to the upstream interface; in a single-vendor architecture, the internal layer comes up for reassessment at the same time and two separate migration projects overlap.

The flexibility is more pronounced still in multi-carrier and multi-region deployments. The only architecture that permits a single, consistent policy point at the enterprise edge while using the strongest carrier service available in each geography upstream is one in which the layers are separated by vendor. The same holds when the enterprise prefers, in a given region, to work with an independent cloud scrubbing provider rather than a carrier service.

---

7. Fifth Argument: The Discipline of Standards-Based Integration

The concern raised most often about using different vendors is integration. That concern is not entirely misplaced, but it is a manageable design task — and forcing the integration onto open standards is itself a gain.

What genuinely needs to be exchanged between the two layers is limited: notice that an attack has begun, the character of the attack, the trigger to divert traffic upstream, and status information after diversion. The available mechanisms, and their realistic maturity levels, are as follows.

Diverting traffic upstream is done over BGP, and this is the most mature and most widely supported part of the field. Two points must not be overlooked in practice: most carriers will not accept advertisements of prefixes smaller than a /24, so the enterprise’s addressing plan must suit the diversion scenario; and after diversion, a return path — a GRE or L2TP tunnel, a dedicated circuit, or virtual routing separation — must exist to bring scrubbed traffic back to the enterprise. This is precisely where multi-vendor scenarios demand the most engineering effort, and it must be designed explicitly before purchase. For web properties, DNS/CNAME-based redirection is an alternative requiring far less integration than BGP, but it protects only services reached by name.

For blunt intervention, remotely triggered black hole routing (RTBH) is widely supported and generally triggered via BGP community values the carrier defines. Its nature must be understood correctly, however: RTBH is not filtering but the complete blackholing of the target address — everything is dropped, legitimate traffic included. In other words, the defender completes the attacker’s objective on the attacker’s behalf. It is a last resort used to protect other assets, not a mitigation strategy in itself.

For finer-grained filter propagation, BGP Flowspec is technically the right tool; but its customer-to-carrier use is less widespread than commonly assumed. Many carriers do not accept Flowspec from customers; those that do impose significant limits on rule counts, match fields, and action types. Flowspec is therefore a capability to be explicitly confirmed with the carrier before contracting, not an interface that can be assumed.

The DOTS standard, designed for automated calls for help (RFC 9132/8783), conceptually addresses exactly what this architecture needs; but field adoption is limited, and most commercial solutions still use proprietary signalling. DOTS should therefore be regarded as a convenience to evaluate where available, not as a foundation for a multi-vendor architecture. In practice most enterprises build the diversion trigger through their own automation layer and the carrier’s API.

On the telemetry and event data side the picture is comfortable: IPFIX, NetFlow, and sFlow for flow data; syslog, standard REST APIs, and SIEM integrations for alert and event data are mature and widely available options. Consolidating both layers’ data into a common observability layer is the basic precondition for operating a multi-vendor architecture.

What this list shows is that the integration surface is narrow but not entirely frictionless. The genuine engineering work lies in the diversion trigger, the return path, and the threshold definitions — and that work should be done before purchase, during proof of concept. In exchange, the enterprise ends up with a defence architecture whose behaviour under attack it understands line by line, documented and exercised. In single-vendor architectures this exchange is established with less effort over a proprietary channel — where thresholds are, in fact, also customer-defined and visible in the console; the real difference is not transparency but that the channel binds the enterprise permanently to the vendor.

---

8. Sixth Argument: Organisational Capability

An often-overlooked benefit accrues in the team. A team exposed for years to a single product’s interface and vocabulary gradually begins to think about DDoS defence in that product’s concepts. A team working with two different products is compelled to move up one level of abstraction: it learns to distinguish what is product-specific from what belongs to the nature of the problem.

This makes a concrete difference during an incident. A team that thinks in the language of attacks rather than the language of a product can rearrange the tools at hand when it meets a vector it has never seen. From an organisational standpoint, the most valuable consequence is that defence knowledge accumulates in the team’s shared understanding rather than in one product’s certified specialist; resilience to staff turnover follows from that.

The cost of this gain should be acknowledged plainly: working with two products demands more learning effort from the team. That effort is real; this article treats it as a cost line in Section 9. The claim here is not that there is no price, but that the price buys a measurable capability gain.

---

9. Counter-Arguments and Their Realistic Weight

An honest assessment must also show the costs of a multi-vendor architecture. These costs are real; but all of them are manageable and none is structural.

“Two separate interfaces, two separate operational loads.” True. Most of that load is resolved by consolidating event and telemetry data into a common SIEM/observability layer; that common layer should already be where the operations team looks day to day. Product consoles are tools for exceptional, in-depth investigation. And in single-vendor architectures, the ISP-side portal and the internal console are frequently managed separately anyway.

“Training and learning load increases.” True, and as noted in Section 8 this is a cost the thesis accepts. Saying the load doubles would be an overstatement, since the team’s longest learning curve is not the product but the enterprise’s own traffic profile; nevertheless, two policy models, two release calendars, and two support processes must be learned. The return is the capability gain described in Section 8.

“When something goes wrong, the two sides blame each other.” This is the classic objection to any multi-supplier architecture, and its remedy is contractual rather than technical. When it is defined measurably which layer is responsible for which attack class, up to which threshold, and within what time, the space for blame largely closes; the responsibility split in Section 10 provides the skeleton of that definition. Moreover, in single-vendor architectures the ISP service and the appliance typically run under different contracts, different service levels, and different support organisations in any case; the “single throat to choke” expectation frequently fails to materialise.

“We lose the bundle discount.” True for the first year, and this is the most concrete cost line in the decision. The assessment should be made not on one-time purchase price but on total cost of ownership across the contract period and the monetised value of the outage risk carried (Section 5).

“Integration risk.” As Section 7 shows, the integration surface is narrow but not entirely frictionless. The way to manage the risk is to test the diversion scenario end to end — including the return path — during proof of concept before purchase, and to write that test into the contract as an acceptance criterion.

---

10. Reference Architecture and Responsibility Split

The one thing a multi-vendor architecture requires in order to work is a clear demarcation of responsibility between the two layers. The following split is the one that works best in practice.

Dimension	ISP / Cloud Layer	On-Premises Layer
Primary role	Stop volumetric attacks that saturate the access circuit, upstream of that circuit	Stop attacks below circuit capacity that require state and application awareness
Typical vectors	UDP amplification/reflection, volumetric floods, carpet bombing, multi-source surges	TCP state exhaustion, low-volume L7/API attacks, slow-request attacks, authentication and session-targeted campaigns
Detection data	Sampled flow and backbone telemetry, global intelligence	Line-rate packet and session visibility, application behavioural baseline
Mitigation data	Full packet inspection in the scrubbing centre after diversion	Continuously inline (or post-redirection in out-of-path deployments)
Realistic response target	Detection to full mitigation: typically minutes, including BGP convergence and policy activation; seconds in always-on mode	Seconds from attack onset
Scale limit	Carrier backbone and scrubbing centre capacity	Access circuit capacity
Contractual metric	Scrubbing capacity, diversion time, mitigation effectiveness	False positive rate, latency impact, session capacity, availability

How the diversion decision is made is the most critical design point in this architecture, and it cannot be reduced to a single rule. A sound design contains three mechanisms working together. First, the on-premises layer automatically signals upstream when access circuit saturation reaches a defined percentage or when a particular vector signature is observed. Second — and vital in volumetric scenarios — an independent automatic trigger threshold is defined on the carrier side as well; because when the circuit fills completely the enterprise’s own signalling channel may be affected too, and the defence cannot be left dependent on the enterprise’s ability to send a signal. Third, the operations team retains manual trigger authority under all conditions, and an out-of-band communication path through which that authority can be exercised — a connection independent of the primary circuit, or a pre-agreed emergency channel with the carrier — is established in advance.

The thresholds for these triggers, the fail-back conditions, and the maximum diversion time must be documented and validated through regular exercises.

In practice: if the carrier side is Arbor, what should sit on premises?

This is where the decision most often comes to a head. On the carrier and telco side, NetScout Arbor (Sightline/TMS, with AED at the edge) is the de facto incumbent; many enterprises already buy DDoS protection from their carrier on that infrastructure. Choosing an appliance from the same family for the on-premises layer is then the path of least operational resistance — and produces exactly the common-mode failure described in Section 3: same codebase, same detection logic, same intelligence feed, same commercial counterparty.

The heterogeneous choice is to leave the carrier’s Arbor service untouched and deliberately source the on-premises layer from a different manufacturer. Five questions should govern that second choice:

1. Are the codebase and detection engine genuinely independent? A product that is a thin layer over the same open-source packet-processing framework does not deliver the independence you are buying.
2. Does it depend on a centralised intelligence cloud? If the carrier layer already relies on such a feed, the on-premises layer must be able to decide on its own — including when that feed is unavailable.
3. Does its coverage profile overlap the carrier layer or complement it? The carrier layer’s centre of gravity is volumetric and protocol-level; the on-premises layer’s real contribution is session state and application behaviour visibility. Full L3–L7 coverage in a single device establishes that complementarity without adding a second product.
4. Is the inter-layer link standards-based? The discipline described in Section 7 is only obtained when the layers are joined by a narrow signalling interface rather than a proprietary, broadly privileged trust relationship.
5. Is the commercial and geographic exposure different? Two layers that do not depend on the same company’s commercial future, the same export regime and the same support organisation are what actually distributes the concentration risk described in Section 5.

An appliance that answers all five — an independent codebase and detection engine, a fully on-premises operating model with no dependency on a centralised intelligence cloud, L3–L7 coverage in a single device, and a commercial relationship entirely separate from the carrier’s — makes the architecture heterogeneous in practice rather than on paper for an enterprise whose carrier runs Arbor. Score every candidate against the five questions; the criteria are vendor-independent and belong in the RFP in that form.

---

11. Decision Framework: Who Is This Right For?

A multi-vendor architecture is not equally necessary for every organisation. The decision should be proportionate to the enterprise’s outage cost and maturity level.

For organisations with high hourly outage costs, online revenue generation, regulatory obligations, or critical infrastructure status, a multi-vendor architecture is effectively a requirement; here the additional operational load is negligible against the risk being carried. For mid-sized organisations whose online channel is important but not the sole revenue source, a multi-vendor structure is strongly recommended; a practical, low-cost starting point in this segment is to retain the carrier’s existing service while deliberately sourcing the on-premises layer from a different manufacturer. In practice that means leaving the carrier’s Arbor-based scrubbing service exactly as it is and buying the edge appliance from a manufacturer with an independent detection engine and a self-sufficient on-premises operating model, so the architecture gains its independence property without disturbing the existing contract. For smaller organisations, or those still early in maturity, the priority is not increasing the number of layers but configuring and measuring the single layer correctly; a multi-vendor structure should be planned as the next maturity step.

For organisations already running a single-vendor architecture, the right move is not to dismantle a working deployment in haste. The right move is to shift one of the layers — usually whichever contract expires first — deliberately to a different manufacturer at the next renewal, and to write that transition into the budget plan from the outset.

---

12. Measuring Success

Whether the architectural choice was correct can only be established by measurement. The core indicators to track are: time to detection and time to full mitigation from attack onset; the proportion of legitimate traffic lost during mitigation; time to divert upstream and service impact during diversion; a comparative record, per incident, of which vectors each layer detected and missed; and the criticality distribution of findings from annual exercises.

The most valuable of these is a data set the multi-vendor architecture generates by its own existence: which layer saw what first in each incident, and what it never saw at all. After a handful of incidents this record maps the blind spots of both engines and gives the enterprise a form of self-knowledge no vendor’s marketing material can supply. In a single-vendor architecture this data never comes into being, because there is no second independent view to compare against.

It is essential that these measurements be produced through planned, controlled DDoS exercises rather than desk analysis. The experience of organisations that run such exercises is unambiguous on this point: engagement data published by firms that sell DDoS testing indicates that the large majority of findings surfaced in testing are of severe or critical severity. That data should not be read as a general industry statistic — organisations that commission DDoS testing do so because they already expect problems, and the data is compiled by the party selling the test. But the direction of its message is reliable: configuration errors, missing thresholds, non-functioning diversion triggers, and stale policies do not become visible until a real attack occurs. Exercises are also the only realistic way to validate the diversion logic and return path of a multi-vendor architecture.

---

13. Conclusion

A two-layer architecture in DDoS defence is no longer a preference but a necessity imposed by the threat landscape. The genuine strategic decision lies not in the number of layers but in how independent those layers are from one another.

This article has not used the benefits arising from the two layers occupying different positions — volumetric attacks stopped above, application attacks stopped below — as evidence for its thesis; those are obtained with a single vendor as well. What vendor diversity adds is different, and falls under three headings. First, the two layers do not fall simultaneously to the same code defect, the same detection blind spot, or the same management plane compromise. Second, a commercial, legal, or geopolitical problem at a single manufacturer affects at most half of the defence rather than all of it. Third, the enterprise does not bind its own data centre architecture to its carrier’s supplier preference.

The price of this choice is clear and should not be concealed: serious design work on the diversion trigger and return path, management of two separate contractual relationships, learning two policy models within the team, and forgoing the first-year bundle discount. In sum, a few weeks of design effort and a modest ongoing operational load.

What is obtained in return is an architecture in which no single software defect, no single supplier crisis, and no single detection blind spot can black out the enterprise’s internet presence in its entirety.

Summarised from the executive’s perspective: vendor diversity in DDoS defence is not an inconsistency but a deliberately designed resilience property. Rather than an architecture that deploys the same failure cause twice, build one in which two different failure causes back each other up.

---

Sources and Notes

Where to get current figures. This article deliberately carries no attack volumes, growth rates or event counts. Any number printed here would be stale before you finish a procurement cycle, and the argument it supports does not depend on one. Take the numbers from the primary reporting instead, and note in each case whose traffic was measured:

• Quarterly DDoS threat reports — Cloudflare Radar and Akamai State of the Internet. Each is compiled from that provider’s own customer base, so both are samples, not censuses, and they will not agree with each other.
• Findings from structured DDoS exercises — Red Button, which is the testing vendor’s own engagement data; the caveat in Section 12 applies.

Standards:

• BGP Flowspec: RFC 8955 / RFC 8956 · RTBH: RFC 5635 · DOTS: RFC 9132 (signal channel) / RFC 8783 (data channel) · IPFIX: RFC 7011
• HTTP/2 Rapid Reset: CVE-2023-44487

Regulation:

• DORA — EU 2022/2554, in particular the provisions on ICT third-party risk, concentration risk, and exit strategies
• NIS2 — EU 2022/2555, risk management measures relating to supply chain security

Architectural assessments:

• Cloud, Hybrid or On-Prem DDoS Protection Options — Corero
• For Enterprise DDoS Defense, Cloud Doesn’t Cut It — A10 Networks
• Inline vs Cloud vs Hybrid DDoS Protection — HostDime