NetScout Arbor AED Alternatives: Options Compared

A renewal notice for a NetScout Arbor deployment rarely arrives at a convenient moment. The appliance is working. The operations team knows the console well enough to use it under pressure. Somewhere in the last contract period it absorbed something that would otherwise have become an incident report with a board audience. And yet the renewal figure — spread across whichever components make up your particular deployment — is large enough that somebody in finance asks the obvious question: is this what the market costs now, or is this what incumbency costs?

That question deserves a better answer than a feature comparison. Arbor Edge Defense is not on anybody’s shortlist by accident, and a page that opens by explaining why the incumbent is bad has already told you it is not worth reading. This guide takes the opposite approach: state precisely what Arbor gives you, then examine the handful of dimensions on which alternatives genuinely differ, and finish with a framework in which renewing is one of the legitimate outcomes.

One disclosure before anything else. This page is published by a party that stands on the alternative side of this market. The purpose here is therefore not to recommend a switch but to make the decision criteria explicit, in a form you could put in front of your own architecture board and defend. Several sections below argue directly for renewal, because in a substantial number of real cases renewal is the correct call.

What Arbor Edge Defense actually is, stated fairly

The first credibility test of any alternatives assessment is whether it can describe the incumbent in terms the incumbent’s own engineers would accept.

Arbor is the incumbent name in carrier-grade DDoS defence, and Arbor Edge Defense is its edge component. AED sits inline at the network boundary as a stateless mitigation layer, and its core strength is high-confidence filtering at the network and transport layers — the class of work where being stateless is an architectural advantage rather than a limitation, because the device cannot be exhausted by the state-table attacks that degrade firewalls. That filtering is informed by NETSCOUT’s ATLAS threat intelligence, assembled in significant part from telemetry contributed by participating service providers, which gives it a breadth of visibility that a single organisation cannot reproduce on its own. In operator environments AED pairs naturally with Arbor Sightline for network-wide flow visibility and with the Threat Mitigation System for scrubbing-centre capacity, and NETSCOUT also offers its own cloud scrubbing service for the volumetric tier.

Three properties follow from that description and should be weighed honestly. The install base is very large, which means the failure modes are well understood and the operational literature is deep. The tooling is mature, which matters more at three in the morning than any datasheet line. And the intelligence reach is genuinely wide, in a way that is difficult for a newer entrant to match on breadth alone.

The criticism in this guide is therefore not about engineering quality. It concerns commercial and architectural shape: how capability is divided across separately licensed components, how much of protection quality is delivered from a vendor-operated cloud, where support physically sits, and what the whole arrangement costs across a five-year horizon rather than a single invoice. Those are questions about how sustainable the product is in your circumstances, not about how good it is. They are not the same question, and at renewal it is the second that decides.

The dimension that decides most replacements: where application-layer depth lives

If you strip a renewal evaluation down to a single architectural axis, this is it.

AED is designed as an edge filter. Fuller application-layer analytics in the Arbor world generally involve the wider ecosystem — Sightline for network-wide visibility, TMS for scrubbing capacity — rather than the edge appliance alone. That is a coherent design: it puts stateless, high-throughput work at the edge and analytical work where the flow data and the mitigation capacity already are. For a carrier running a backbone, it is arguably the right decomposition.

Several alternatives make the opposite choice and concentrate coverage from Layer 3 through Layer 7 in a single device. Radware DefensePro spans an unusually broad range in the device itself, from volumetric floods through to encrypted application-layer attacks, using behavioural detection that generates real-time signatures rather than waiting for hand-written rules — a model whose operational cost and renewal questions differ from Arbor’s in kind rather than degree. Fortinet FortiDDoS builds behavioural baselines with machine learning on hardware-accelerated inspection in one appliance, which raises a separate question about extending one vendor’s fabric to this layer. Other single-appliance products in this segment take the same approach.

Neither shape is universally superior, and it is worth being precise about the trade. The decomposed shape gives an operator network-wide visibility that an edge box structurally cannot produce, because the edge box only sees what crosses the edge. The consolidated shape gives a smaller organisation one device, one policy model, one support relationship and one renewal date for the whole L3–L7 problem.

What the difference does mean is that comparing quotations device-for-device is meaningless. If application-layer depth in your incumbent deployment arrives through additional licensed components, and the alternative delivers it in the appliance, the correct comparison is capability-for-capability. The same discipline applies in the other direction: if there is a capability you genuinely use in the Arbor ecosystem that the alternative cannot express, that belongs on a list of things you would lose, not in a price column where it silently disappears.

This is also where the most common scoping error occurs. Replacing AED does not automatically mean replacing Sightline. Network-wide flow visibility and edge mitigation are separable functions, and if your network team lives in Sightline daily, the honest scope of the exercise is the edge layer only. Establish that boundary before you request a single quotation, because it determines what a comparable offer even looks like.

Licensing shape, not licence price

The second dimension is structural rather than numerical, and it is the one most often skipped because it looks like procurement detail rather than architecture.

Before comparing anything, produce a line-by-line breakdown of your current agreement that separates what is licensed by throughput, what by feature, what by chassis or model, and what by tenant or subscriber count. This distinction matters because growth does not affect those categories equally. Doubling your access circuit moves the throughput-bound lines sharply and may leave the feature-bound lines untouched — or the reverse, depending on how the agreement was written. An organisation that has not made that separation cannot forecast its own renewal, let alone compare one.

Four further contract properties deserve written answers, from your incumbent and from every alternative on equal terms.

Co-termination. If components expire on different dates, renewal stops being one decision and becomes a series of small ones, each negotiated from a weaker position because the rest of the estate is already committed. Pulling every end date onto one day is a negotiating objective in its own right, independent of which vendor you end up with.

The uplift clause. Is there an annual increase provision, what is it tied to, and is it capped? Read what the text says rather than what the account team describes as normal practice.

What happens at expiry. This is the least-read clause in most agreements and the most decisive one in negotiation. If the agreement is not renewed, does the device continue forwarding packets, does it keep operating on its last known rule set, which features stop, when does the cloud feed stop, and what happens to hardware replacement rights? If you do not know the answer, the counterparty is negotiating with information you do not have.

Hardware lifecycle dates. Ask for end-of-sale and end-of-support dates for the exact model numbers you hold. Entering a multi-year term and then meeting a mandatory hardware refresh in year two means the renewal was mispriced from the outset.

Dependency on a vendor-operated intelligence cloud

The third dimension is the one that separates products most sharply once you look past the datasheet, and it is best assessed by asking what survives if the vendor relationship is interrupted.

For AED, protection quality draws on the cloud-delivered ATLAS feed, and three questions follow directly. What telemetry, if any, leaves your network when intelligence-sharing features are enabled? In which jurisdiction is it processed? And how does the appliance perform if the feed becomes stale, unavailable or restricted? These are reasonable questions to put to any vendor whose product consumes a hosted feed, and a mature vendor will answer them without difficulty.

Ask the same three questions of every alternative, because several of them also ship optional subscription feeds and hosted analytics. The relevant distinction is not whether a cloud component exists — it is whether core detection continues to function without it, and whether the product degrades gracefully or stops. A product whose behavioural detection is trained and evaluated entirely on the device fails differently from one whose classification depends on a live external lookup, and the difference only becomes visible in the scenario nobody plans for.

There is a legal dimension in some markets that should be handled by your legal function rather than your network team. Where a regulator treats the cross-border processing of traffic metadata — source addresses, headers, session identifiers — as a data protection question rather than an implementation detail, the answer to “in which jurisdiction is it processed” belongs in a transfer assessment, not in a technical appendix. Chapter V of the GDPR is the reference framework in the EU, and comparable localisation requirements exist in several other jurisdictions. The practical instruction is simply that the question be asked and the answer written down.

What no edge appliance can do, and why that bounds the exercise

Before comparing edge appliances at all, it is worth fixing the boundary of what the edge layer can contribute, because a surprising number of replacement evaluations quietly expand into a debate the edge layer cannot settle.

No appliance — Arbor’s or anyone else’s — can filter a flood larger than the circuit it sits behind. The upstream tier is therefore a separate purchase governed by separate economics, whether it is your carrier’s scrubbing service, an independent cloud provider, or the vendor’s own cloud offering. Keeping the two decisions on separate calendars is worth something in itself: it means neither renewal can be used as leverage over the other.

This bounding also disciplines the comparison. The edge layer’s genuine contribution is line-rate packet and session visibility, application behavioural context, and mitigation that is already in the path when an attack begins rather than minutes later. Those are the properties to test in a proof of concept. Raw volumetric headline numbers are the upstream tier’s business.

If your carrier also runs Arbor

Many enterprises buy DDoS protection from their carrier, and on the carrier side Arbor is very widely deployed. If that is your situation, the edge appliance decision carries a resilience dimension that is easy to miss.

The convenience of a single-vendor pairing is real and should not be dismissed: one policy vocabulary, one management plane, one support counterparty, and a low-friction handover at diversion time. For a thinly staffed team that is felt daily.

The cost is equally real. When both tiers share a codebase, a detection logic and a contract, a single failure cause has been deployed twice. A parsing defect exists identically in both places. A detection blind spot is present in both places. An intelligence feed interruption blinds both at the same moment. Reliability engineering has a name for this — common-mode failure — and it is the reason redundancy is only redundancy when the components are independent.

At renewal this converts into a concrete question: if the carrier layer is already Arbor, does sourcing the edge appliance from a different manufacturer buy enough independence to justify the operational friction? For organisations whose outage cost is high, it usually does. For organisations early in their maturity, configuring one layer properly matters more than diversifying two.

Regional support reach and escalation geography

Every vendor discussed here operates a documented global support organisation with defined escalation chains for severe incidents. The question at renewal is not competence. It is where a severity-one ticket raised at three in the morning actually lands, in which language the resulting packet-capture discussion happens, and in which time zone the decision to change a mitigation policy gets made.

The way to make this measurable is to read last year’s tickets rather than this year’s service commitments. Extract four numbers from your own records: actual first-response times on severe tickets, the elapsed time between first response and reaching an engineer with genuine depth on the problem, the proportion of tickets raised outside business hours, and the time for a replacement part to physically reach site. That last figure includes customs clearance in many markets, entirely independent of any contractual hour commitment — which is why whether in-country spares are held is a separate question worth asking explicitly.

For the partner layer, one question suffices: does the local team carry third-line technical capability, or is it a layer that forwards tickets to the manufacturer? Both are legitimate models with different costs and different behaviour during an incident. Renewal is the right moment to get the distinction written into the agreement rather than assumed.

Five-year renewal economics

Year-one pricing is the least informative number in this exercise. Ask every party — the incumbent included — for year one through year five including support renewals, on identical scope, and compare the totals.

Three effects shape that total, and they should be separated rather than argued about as a single figure. First, the multi-component structure: where capability is split across separately licensed pieces, the renewal surface grows with the number of pieces, and each has its own uplift behaviour. Second, growth coupling: if any line is throughput-bound, model what happens when the access circuit is upgraded during the term, because that is a scheduled event and not a risk. Third, scope that is paid for but unused: log into the management interface and establish which modules are enabled and which have produced no rule and no alert in the last twelve months.

That last exercise routinely changes the negotiation more than any competitive quotation does, because it produces a third outcome most organisations never consider — renewing with reduced scope. Dropping components you have demonstrably not used changes the commercial picture without changing vendor, migration risk or operational habit. It is worth stressing that you generally cannot obtain that outcome without a comparable second quotation in hand. A renewal discussion held without an alternative on the table is not a negotiation; it is an approval.

Treat analyst material in the same disciplined spirit. This market is covered in Gartner’s Market Guide for DDoS Mitigation Solutions, Forrester’s The Forrester Wave: DDoS Mitigation Solutions and IDC’s IDC MarketScape. Ask any party claiming a position for the current edition itself rather than a slide reproducing it, since positions move between editions. Note also that public quotation of Gartner research requires reprint rights: a provider quoting Gartner on a public page should be able to demonstrate it holds them.

The alternatives, and what each is actually for

Alternatives to AED fall into three shapes, and confusing them is the fastest way to an unusable comparison.

Single-appliance replacements occupy the same physical position and the same architectural role. Radware DefensePro is built around behavioural detection that generates real-time signatures for previously unseen patterns, covers an unusually broad span from volumetric floods to encrypted application-layer attacks, and integrates with Radware’s own cloud service for a single-vendor hybrid. Fortinet FortiDDoS uses custom processors to inspect at line rate and builds behavioural baselines with machine learning rather than relying primarily on signatures, and it slots naturally into estates already standardised on the Fortinet Security Fabric. A10 Thunder TPS is engineered for mitigation density in a compact footprint with an emphasis on volumetric and protocol-layer defence plus DNS protection, integrates with BGP and flow telemetry for out-of-path deployment, and is managed at scale through aGalaxy — a design intent that suits a scrubbing estate more readily than a single edge. Corero SmartWall focuses on automatic, sub-second inline mitigation with minimal operator intervention, and its integration with Juniper MX routers allows mitigation to be enforced in existing routing infrastructure — a genuinely distinctive architectural option for providers who would rather not add boxes.

Cloud-delivered services are not appliance replacements at all, and treating them as one produces a comparison that cannot be defended. They move inspection off your premises entirely, which changes the latency profile, the data-processing footprint and the failure model simultaneously. For a public web estate that is often the right answer; for latency-sensitive services, non-HTTP protocols, or environments where traffic must remain in-country, it is a different architecture rather than a substitute.

Carrier-provided mitigation is the third shape, and it is frequently already present and under-used. If you buy transit from a carrier that operates scrubbing, part of what an edge appliance renewal is being asked to cover may already exist upstream. Establishing the actual division of labour with your carrier before renewal sometimes shrinks the requirement.

Appliance	Where application-layer depth lives	Licensing question to answer in writing	Vendor-cloud question to answer in writing	Support reach	Renewal economics profile
A10 Thunder TPS	Centre of gravity is volumetric and protocol defence plus DNS protection; managed at scale through aGalaxy	Which capabilities are chassis-bound, which are throughput-bound, and how aGalaxy is licensed alongside the mitigation nodes	Which subscription or reputation services are in your quoted scope, and what mitigation looks like without them	Partner-dependent; validate third-line depth in your own geography	High capacity per dollar at service-provider scale; less efficient at enterprise sizes
Corero SmartWall	Deliberately focused inline scope; deep application analysis is expected to sit elsewhere in the stack	How mitigation capacity is licensed, and how the router-integrated deployment option is priced against the standalone one	Which analytics and reporting functions are delivered as a hosted service rather than on the device	Partner-dependent; validate third-line depth in your own geography	Lean operating cost, narrower scope; the saving is real only if the narrower scope fits
Fortinet FortiDDoS	On-device behavioural baselining with hardware acceleration; wider context comes from the Security Fabric	Which capabilities are appliance-resident and which arrive as subscription services renewed separately	Which subscription services are assumed in the quote, and how the appliance behaves if they lapse	Broad channel presence in most markets	Bundled-ecosystem economics; strongest when the estate is already standardised on the vendor
NetScout Arbor Edge Defense	Edge appliance is strongest at L3/4; fuller application-layer analytics generally involve the wider Sightline and TMS ecosystem	Which capability is licensed on which component, and whether the components co-terminate	What telemetry leaves your network when intelligence-sharing is enabled, where it is processed, and how the appliance behaves if the feed is unavailable	Established global organisation; escalation geography and language should still be confirmed	Highest of this group; the multi-component structure is what compounds it over five years
Radware DefensePro	Broad span in the device itself, from volumetric floods to encrypted application-layer attacks	How the on-premise tier and the vendor cloud service separate in the contract, and what the single-vendor hybrid actually comprises	Which feeds are optional and which the quoted protection level assumes	Established global organisation; escalation geography and language should still be confirmed	High; budget the tuning effort as a cost line, not an assumption

This table records which questions to get answered in writing at renewal, not what any product costs. Licensing structures, bundle composition and support terms vary from contract to contract and from market to market; the benchmark is the text of your own agreement and a current written quotation, not any vendor's general product narrative.

What migrates, and what quietly does not

If the evaluation moves toward replacement, the cost that is most reliably underestimated is not the appliance. It is everything that does not come with it.

Policies do not transfer as files. Thresholds, counter definitions, profile names and protection levels are vendor-specific, and a number in one product does not measure the same thing in another. What must transfer is intent, not values: for each rule, write down what it protects, which incident caused it to be written, and what happens if it is removed. Most organisations discover during this exercise that nobody remembers why several exceptions exist — which is, in itself, one of migration’s unexpected benefits.

The learned baseline does not transfer at all. Every behavioural device builds its own notion of normal from its own measurements. Plan the learning window to span a full business cycle, including month-end processing, campaign periods, and whatever seasonal peak your sector has. A learning period that excludes the peaks returns the following month as false positives.

Accumulated tuning stays behind. False positive exemptions, whitelists, partner address blocks, and allowances written for one legacy application’s unusual behaviour typically live only on the device and only in one engineer’s memory.

Automation and reporting bindings stay behind. Scripts written against the vendor’s interface, automated enable and disable flows, management report templates, and historical trend data. Historical data matters more than teams expect: the new device starts from zero, so old reports need archiving separately if year-on-year comparison is to survive.

Scope beyond DDoS filtering stays behind. If you have enabled indicator-based inspection of outbound traffic on the incumbent appliance, inventory it explicitly. A purpose-built DDoS mitigation appliance is not a substitute for that function, and discovering the gap after cutover is an avoidable failure of scoping.

What does transfer is worth stating too, because it is the cheapest part of the project: the network design — inline position, bypass units, TAP and mirror points, cabling and optics — carries over largely unchanged; your own NetFlow or sFlow history, traffic profile studies and attack records belong to you and can seed the new device’s expectations; standards-based upstream arrangements survive a device change; and the acceptance criteria and test harness you build become a permanent institutional asset reusable at the next renewal.

Sequence the migration so that risk falls at every step: document policy intent before speaking to any vendor; run the new device out of path on mirrored traffic while the incumbent stays inline; compare the two devices’ decisions over a defined window rather than their counters; go inline on a single low-risk segment behind hardware bypass; define written roll-back criteria and name the person authorised to invoke them without waiting for a meeting; keep incumbent support live through at least one attack season and show that dual-running cost openly in the business case; and decommission only after log continuity and audit trails are resolved. Timing is a risk line of its own — a migration begun three weeks before contract expiry has already decided its own outcome in favour of renewal.

Standards-based signalling as a portability test

There is one technical criterion that deserves disproportionate weight, because it determines how expensive your next renewal will be.

Ask whether the candidate appliance talks to the upstream tier over open standards or a proprietary interface. In practice this means BGP Flowspec for filter propagation, remotely triggered black hole routing for blunt intervention, and the DOTS signalling framework for inter-organisational calls for mitigation help. Flowspec support from carrier to customer is less universal than commonly assumed and should be confirmed with your carrier before contracting rather than presumed. DOTS is the standardised answer to the signalling problem and worth asking about explicitly, though field adoption remains limited and most commercial deployments still use proprietary channels.

The value of a standards-based interface is not only that it eases today’s migration. It is that both tiers remain independently replaceable at every future renewal — which is precisely the property that gives a buyer leverage. A proprietary bond between the edge appliance and the upstream tier is a commercial arrangement wearing technical clothing.

Questions to put to both sides

The discipline that makes an evaluation defensible is applying identical scrutiny in both directions. The following lists are deliberately symmetric.

To the incumbent. Break the renewal down line by line rather than quoting one figure: what is licensed by throughput, what by feature, what by chassis? If the agreement is not renewed, what does the device do — which features stop and when, what happens to the feed, does it continue on its last rule set? What exactly is fixed by a multi-year term, and what rights of scope reduction or early exit exist? What is the uplift clause tied to and is it capped? Where does a severity-one ticket land at three in the morning, in what language, and are third-line capability and spare parts held in our region? If we drop the components we do not use, what is the price and precisely what capability do we lose — in writing? What telemetry leaves our network when intelligence sharing is enabled, where is it processed, and how does the appliance behave if the feed is cut? What are the end-of-sale and end-of-support dates for our exact models?

To every alternative. The same line-by-line breakdown, the same five-year horizon, the same scope. Does detection run entirely on the device, and what changes if the vendor’s cloud is unreachable? Which of our current policies can you express and which can you not — reviewed rule by rule, in writing? How long is the learning window and how does protection behave during it? Is upstream signalling standards-based: Flowspec, black hole routing, DOTS? How does logging map onto the fields our SIEM expects, and can the device summarise per event rather than per packet? Will you accept a proof of concept run on our traffic, against our acceptance criteria, starting in out-of-path monitoring? Same-time-zone support, in-region third-line capability, in-region spares: which of the three do you have and which do you not? Can we speak to a reference in our sector without you in the room? And finally: what will we lose by leaving the incumbent that you cannot replace?

The answer to that last question tells you more about an alternative’s seriousness than the other nine combined. A vendor who answers “nothing” has either not understood the question or has understood it and declined to answer.

Assessed against exactly those criteria, HARPP DDoS Mitigator is one candidate worth including on a shortlist: detection runs entirely on the appliance with no dependency on a vendor-operated intelligence cloud, L3 through L7 coverage is consolidated in a single device rather than distributed across separately licensed components, and support is delivered regionally rather than from a single global hub. As with every other candidate, that is a claim to be tested against your own traffic, not accepted.

When renewing is the right answer

This is the most important section in the guide and the one most likely to be skipped. In each of the following situations, renewal is not merely defensible — it is correct.

When you genuinely use the ecosystem. If network-wide flow visibility is a daily operational tool, if a scrubbing-centre architecture is built around it, and if your team works inside those tools, a single edge appliance does not replace them. The right question then is not “should we switch” but “what does the price become if we drop the components we do not use”.

When the team has no capacity. Migration consumes senior network engineering time for months. If that time is already committed to a data-centre move, a core network refresh or a compliance programme, running two projects concurrently increases risk rather than distributing it.

When the calendar collides. Audit season, a peak trading period or a major campaign is the wrong window. Renewing one more term and scheduling the migration into a suitable window is better in every dimension than a migration done in a hurry.

When no alternative demonstrates equivalence on your own traffic. If false positive behaviour in a test that replays your real application traffic sits above your acceptance threshold, no commercial advantage compensates. The test result precedes the quotation.

When the difference does not cover the cost of moving. If the commercial gap across the contract term does not cover migration effort, the dual-running period, elevated risk during the learning window and a margin for error, renewing is the rational decision. Assuming the saving is certain while assuming the migration cost is optimistic is how security teams lose credibility for their next request.

A decision framework

Do not make this decision on a single axis. Three should be assessed together.

Utilisation. How much of the scope you pay for do you actually use? High utilisation points toward renewal; low utilisation points first toward a scope-reduction negotiation rather than a vendor change.

Architecture. Does application-layer depth need to be at the edge in your environment, or is the decomposed shape correct for you? Is your upstream tier already from the same manufacturer, and does that concentration matter given your outage cost? Is the upstream interface standards-based or proprietary?

Operations. Do you have the capacity, the calendar window and a written roll-back plan to execute a migration? If not, the correct decision is to renew one more term and plan the migration properly.

Where all three axes favour change, the decision is straightforward. Where only the commercial axis favours change, attempt the scope-reduction negotiation first. Where the operational axis is against it, do not move regardless of the commercial gap — a badly timed migration returns the entire saving in a single incident.

Sources and further reading

We do not reproduce the content of paid analyst research or attribute figures to it. The list below identifies documents worth reading, and worth requesting from any party that cites them.

Standards. BGP Flowspec is specified in RFC 8955 and, for IPv6, RFC 8956. Remotely triggered black hole filtering is described in RFC 5635. DOTS — the standardised mechanism for signalling a request for mitigation help between organisations — is defined architecturally in RFC 8811 and its signal channel in RFC 9132, with the data channel in RFC 8783. IPFIX, the flow export protocol, is RFC 7011. General denial-of-service considerations are surveyed in RFC 4732, and network ingress filtering in RFC 2827 (BCP 38) and RFC 3704 (BCP 84).

Guidance. NIST Special Publication 800-189, Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation, is the most directly relevant public guidance on the routing-layer aspects of this architecture.

Regulation. For EU-regulated entities, Directive (EU) 2022/2555 (NIS2) covers risk-management measures including supply chain security; Regulation (EU) 2022/2554 (DORA) sets out ICT third-party risk, concentration risk and exit-strategy requirements for financial entities, and is the most useful vocabulary available for arguing a concentration-risk case internally; Regulation (EU) 2016/679 (GDPR), particularly Chapter V, governs transfers of personal data to third countries and is the correct framework for assessing what a mitigation tier processes outside your jurisdiction.

Vendor documentation. Request current product documentation and support programme definitions directly from each manufacturer rather than from a sales presentation — for NETSCOUT, the Arbor Edge Defense, Sightline and TMS documentation; for the alternatives, the equivalent product and support documents. The clauses you will negotiate are defined in those texts.

Analyst publications. Gartner’s Market Guide for DDoS Mitigation Solutions, Forrester’s The Forrester Wave: DDoS Mitigation Solutions and IDC’s IDC MarketScape cover this market. Ask any party claiming a position for the current edition itself. Public quotation of Gartner research requires reprint rights; a provider quoting Gartner publicly should be able to demonstrate that it holds them.

Public attack data. The quarterly DDoS reports published by large cloud and CDN providers are the most commonly cited open sources for volume and vector distribution. Read them with the sampling caveat in mind: each is compiled from its publisher’s own customer base.