A10 Thunder TPS Alternatives in 2026

Most searches for an alternative to a named product begin from one of two places: a renewal figure that has grown faster than the budget, or a growing suspicion that the product is solving a problem adjacent to the one you actually have. With A10 Thunder TPS, the second is far more common than the first — and it is the more interesting starting point, because it is answerable with evidence rather than negotiation.

This page is published by a party that stands on the alternative side of this market. That disclosure belongs at the top rather than in a footnote, because the purpose here is not to argue for a switch. It is to make the selection criteria explicit enough that you could put them in front of your own architecture board and defend them — including in the several cases below where the honest conclusion is that the incumbent is the right tool and the search should stop.

What Thunder TPS actually is, stated fairly

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

A10’s Thunder TPS — Threat Protection System — is built for mitigation density in a compact footprint. Its centre of gravity is volumetric and protocol-layer defence, with a distinct emphasis on DNS protection, and it is designed to be deployed either inline or out of path, integrating with BGP and flow telemetry so that traffic can be diverted into it when an attack is detected and returned to the normal path afterwards. At scale it is managed through A10’s aGalaxy platform, which is what makes a fleet of mitigation nodes across multiple sites an operable thing rather than a collection of individually administered boxes. A10 Networks is a publicly listed company headquartered in the United States, and Thunder TPS sits within a wider Thunder product family that shares a common platform lineage across A10’s other lines.

Those properties combine into a specific and coherent design intent. A high-density mitigation platform that fits in few rack units, speaks the routing and telemetry languages that operators already use, and can be orchestrated centrally, is precisely what a scrubbing centre needs. That is why Thunder TPS recurs in carrier and MSSP scrubbing-centre designs, and why service providers who have built a mitigation practice around it tend to stay.

The observations in this guide are therefore not about engineering quality. They concern fit and commercial shape: whether the operating model the product assumes matches the team that would run it, where application-layer depth sits relative to where you need it, whether support has real depth in your geography, and how capacity licensing behaves as you grow. Those are questions about whether a good product is the right product for a particular buyer. They are not the same question, and conflating them is how organisations end up owning a platform they operate at a fraction of its capability.

The question that decides everything else: scrubbing centre or edge?

Before any feature comparison, settle one architectural question, because it determines which comparison is even valid.

A scrubbing centre is a mitigation estate that traffic is brought to. Traffic is diverted into it — typically by BGP announcement — when detection fires, cleaned, and returned to the destination. The estate serves many protected properties, often many customers, and its economics are measured in capacity per rack unit, per watt, and per engineer. The people who run it work in routing daily; diversion is a routine operation, not an escalation.

An edge deployment is the opposite geometry. The device sits permanently in the path in front of a finite access circuit, protecting one organisation’s services. It is measured not on capacity density but on how invisible it is when nothing is happening and how few legitimate users it discards when something is. Nobody diverts anything; the traffic is already there.

The distinction matters commercially as well as technically. A product built for the first geometry carries capabilities that only pay for themselves at the second’s scale: fleet orchestration, multi-node capacity pooling, telemetry integration with a routing practice. Bought for a single-site edge deployment, those capabilities are still present, still licensed, and still require somebody to understand them — but nothing in the environment exercises them.

So the honest first step is not to shortlist alternatives. It is to write down, in one paragraph, which geometry you are actually building. If the answer is a scrubbing centre, the incumbent is a strong candidate and several of the alternatives below are simply not addressing your problem. If the answer is an edge, read on, because the criteria that follow are the ones that will decide.

Operational model: the criterion that is felt daily

Of the four dimensions this guide compares, this is the one that most reliably determines whether a deployment is judged a success two years later — and the one least visible in any datasheet.

A service-provider-oriented mitigation platform assumes a particular operating practice. It assumes somebody is comfortable announcing and withdrawing routes. It assumes flow telemetry is already collected and trusted. It assumes that when a mitigation policy needs changing at two in the morning, the person doing it knows what the policy was for. It assumes, in short, a network operations function with routing depth. Where that function exists, the assumption is a feature: the product speaks the team’s native language and does not force them into a parallel abstraction.

Where it does not exist, the same assumption becomes a recurring tax. A four-person infrastructure team that also runs the firewalls, the load balancers and the VPN concentrators does not develop deep fluency in a mitigation platform’s operational model, because they touch it rarely. The consequence is not that the product fails. It is that the deployment settles into whatever configuration the commissioning engineer left behind, and stays there — which means the organisation is paying for adaptive capability it has stopped adapting.

Three questions make this measurable rather than impressionistic, and they should be answered before any vendor is contacted:

Who will change a mitigation policy under attack, and have they done it in the last twelve months? If the honest answer is “we would open a support ticket”, then support responsiveness is a more important selection criterion than any detection capability, and it should be weighted accordingly.

How many separate consoles does the team already carry? Every additional management plane is a fixed cost in attention, not just in licensing. A product that consolidates the whole L3–L7 problem into one policy model and one console is worth something concrete to a small team, and worth considerably less to a large one that already has a tooling practice.

What happens on the day the one person who understands the deployment is unavailable? This is the question that separates products which degrade gracefully into a sensible default from products which require expertise to be safe. Test it explicitly during a proof of concept by having somebody other than the vendor engineer make a routine change.

Where application-layer depth sits

The second dimension is architectural and is the most common technical reason a buyer looks past a volumetric-and-protocol specialist.

Thunder TPS concentrates on volumetric and protocol-layer defence with a distinct DNS emphasis. For a scrubbing estate that is the right division of labour: the estate’s job is to absorb and clean floods at scale, and detailed application-behaviour analysis belongs closer to the application, where the request context actually exists. A carrier cleaning traffic for a thousand downstream customers cannot reasonably hold behavioural models for each of their applications.

An enterprise defending its own services has the opposite situation. The context is right there, and the attacks that hurt most are frequently the ones that look like legitimate use: slow request floods, session exhaustion, expensive-query abuse, credential-stuffing patterns that arrive well below any volumetric threshold. For that buyer, application-layer depth is not a nice-to-have layered on top of volumetric protection — it is the part that determines whether the investment addresses the incidents they actually experience.

Several alternatives make the opposite architectural choice and consolidate coverage from Layer 3 through Layer 7 in a single device. Radware DefensePro spans an unusually broad range within the appliance, from volumetric floods through to encrypted application-layer attacks, using behavioural detection that generates real-time signatures rather than waiting for hand-written rules — depth that rewards a team with capacity to tune it. Fortinet FortiDDoS builds behavioural baselines with machine learning on hardware-accelerated inspection in one appliance, which for a Fortinet-standardised estate turns the decision into a question about extending the fabric. Others take the same approach with different emphases.

Neither shape is superior in the abstract, and the trade should be stated precisely. The specialised shape gives density and clarity of purpose: a device that does one class of work extremely well, with a smaller configuration surface and fewer ways to be wrong. The consolidated shape gives a smaller organisation one device, one policy model, one support relationship and one renewal date covering the whole problem.

What the difference does mean is that comparing quotations device-for-device is meaningless. If the application-layer depth you need arrives in your incumbent architecture through additional components or an upstream service, and an alternative delivers it in the appliance, the correct comparison is capability-for-capability. The discipline applies in the other direction too: if there is something the incumbent does that you genuinely rely on and the alternative cannot express, that belongs on a written list of things you would lose — not quietly omitted from a price column.

How capacity is licensed, and what happens when you grow

The third dimension is where evaluations most often go wrong, because it looks like procurement detail rather than architecture.

Do not begin by comparing prices. Begin by producing a line-by-line breakdown of what any candidate quotation is actually licensing, sorted into four categories: what is bound to the chassis or model, what is bound to a throughput tier, what is bound to a feature or subscription renewed on its own schedule, and what is bound to a tenant or protected-object count. Ask for that breakdown from every vendor including the incumbent, in identical form. Vendors describe their own structures in their own vocabulary, and the only way to compare is to force the answers into one shape.

The reason this matters is that growth does not affect those categories equally. Upgrading an access circuit moves the throughput-bound lines sharply and may leave the chassis-bound lines untouched — or the reverse, depending entirely on how the agreement was written. Adding a second site may duplicate everything or may draw from a shared entitlement. An organisation that has not made this separation cannot forecast its own renewal, let alone compare two.

Four further contract properties deserve written answers on identical terms from every party:

What is bound to what. Get the four-way categorisation above in writing, from each vendor, for the exact configuration quoted.

Growth behaviour. Model an access-circuit upgrade during the contract term and ask each vendor what changes. This is a scheduled event in most organisations, not a hypothetical.

What happens at expiry. If the agreement is not renewed, does the device continue forwarding, does it continue mitigating on its last known configuration, which functions stop and when, and what happens to hardware replacement rights? This is the least-read clause in most agreements and the most decisive one in a negotiation.

Hardware lifecycle dates. Ask for end-of-sale and end-of-support dates for the exact models quoted. Entering a multi-year term and meeting a mandatory refresh in year two means the deal was mispriced from the start.

Regional support presence

Every vendor discussed here operates a documented support organisation with defined escalation paths. The question is not competence, and framing it as competence is both unfair and unhelpful. The question is geography.

Where does a severity-one ticket raised at three in the morning actually land? In which language does the resulting packet-capture discussion happen? In which time zone does the decision to change a mitigation policy get made? And how long does a replacement part physically take to reach site, including customs clearance, which is entirely independent of any contractual hour commitment?

Make this measurable using your own records rather than anyone’s service commitments. From last year’s tickets, extract four numbers: actual first-response time on severe tickets, elapsed time between first response and reaching an engineer with real depth on the problem, the proportion of tickets raised outside local business hours, and the time from RMA approval to a part in the rack. Those four numbers describe your support experience more accurately than any published target.

For products delivered largely through partners — which includes several options in this segment — one question separates the two models: does the local team carry genuine third-line technical capability, or is it a layer that forwards tickets to the manufacturer? Both are legitimate, they cost differently, and they behave very differently during an incident. Get the answer written into the agreement rather than assumed from a meeting.

There is a related question that belongs to your legal function rather than your network team. Where any part of protection depends on telemetry leaving your network, establish what leaves, in which jurisdiction it is processed, and how mitigation behaves if that channel is unavailable. In markets where a regulator treats cross-border processing of traffic metadata as a data-protection matter rather than an implementation detail, that answer belongs in a transfer assessment. Ask it of every candidate equally; a mature vendor answers it without difficulty.

The bound that no on-premise choice escapes

One constraint applies identically to every option in this comparison, and stating it early prevents a great deal of wasted evaluation.

No appliance — A10’s or anyone else’s — can filter a flood larger than the circuit it sits behind. Above that line, only capacity closer to the source helps, whether that is your carrier’s scrubbing service or an independent cloud provider. This bounds the exercise usefully: the on-premise layer’s genuine contribution is line-rate visibility, application behavioural context, and mitigation that is already in the path when an attack begins. Those are the properties to test. Raw volumetric headline figures belong to the upstream tier’s evaluation, not this one.

It also means the two decisions should sit on separate calendars and, ideally, with separate counterparties. When both tiers come from one manufacturer, a single detection blind spot or parsing defect has been deployed twice — the convenience is real, and so is the concentration.

The alternatives, and what each is actually for

Alternatives fall into three shapes, and confusing them produces a comparison that cannot be defended.

Single-appliance replacements occupy the same physical position, and the appliances that compete for it are compared side by side separately. Radware DefensePro is built around behavioural detection generating 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; realising that depth rewards a team with capacity to invest in tuning. Fortinet FortiDDoS inspects at line rate using custom processors and builds behavioural baselines with machine learning rather than relying primarily on signatures, and it fits most naturally into estates already standardised on the same vendor. 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 within existing routing infrastructure — a genuinely distinctive option for providers who would rather not add boxes. NetScout Arbor Edge Defense is a mature stateless edge filter whose strength is high-confidence network- and transport-layer work, paired in operator environments with the wider Sightline and TMS ecosystem, so the licensing shape rather than the filtering is what a comparison against it has to address.

Cloud-delivered services are not appliance replacements and should not be compared as such. They move inspection off your premises entirely, changing the latency profile, the data-processing footprint and the failure model at the same time, which is why coming back from a cloud-first posture is a change of default rather than a migration. For a public web estate that is frequently 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 is often already present and under-used. If you buy transit from a carrier that operates scrubbing, part of what an appliance purchase is being asked to cover may already exist upstream. Establishing the actual division of labour with your carrier before you shortlist sometimes shrinks the requirement enough to change the answer.

Appliance	Operational model it assumes	Where application-layer depth sits	Capacity licensing question to answer in writing	Regional support reach	The use case it is genuinely built for
A10 Thunder TPS	Service-provider practice — BGP diversion, flow telemetry, fleet management through aGalaxy	Centre of gravity is volumetric and protocol defence plus DNS protection	Which capability is bound to the chassis, which to throughput, and how the management platform is licensed alongside the mitigation nodes	Partner-dependent; validate third-line depth in your own geography	High-density scrubbing centres and carrier or MSSP mitigation estates
Corero SmartWall	Deliberately low-touch inline operation for teams without a dedicated DDoS desk	Deliberately focused inline scope; deep application analysis is expected elsewhere in the stack	How mitigation capacity is licensed, and how the router-integrated option is priced against the standalone one	Partner-dependent; validate third-line depth in your own geography	ISPs and hosting providers wanting automatic mitigation with minimal operator intervention
Fortinet FortiDDoS	Familiar to any team already operating the vendor's other products; unfamiliar otherwise	On-device behavioural baselining with hardware acceleration; wider context via the Security Fabric	Which capabilities are appliance-resident and which arrive as separately renewed subscriptions	Broad channel presence in most markets	Enterprises already standardised on the same vendor's estate
HARPP DDoS Mitigator	Single appliance, single policy model, single console; aimed at lean teams	Full L3–L7 in one appliance, including per-protocol application-layer classification	How multi-tenancy and throughput are licensed on one chassis	Delivered regionally rather than from a single global hub	Telcos, data centres, ISPs and enterprises in sovereignty-sensitive markets
NetScout Arbor Edge Defense	Edge filter within a wider operator toolchain; assumes the ecosystem is used	Edge appliance is strongest at L3/4; fuller analytics involve the Sightline and TMS ecosystem	Which capability is licensed on which component, and whether the components co-terminate	Established global organisation; confirm escalation geography and language	Large carriers and enterprises invested in the wider ecosystem
Radware DefensePro	Deep platform that rewards a staffed security team and sustained tuning	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	Established global organisation; confirm escalation geography and language	Automation-focused enterprises with capacity to invest in tuning

This table records the shape of each option and the questions to get answered in writing, not what anything costs or how any product performs. Licensing structures, bundle composition and support terms vary by contract and by market; the benchmark is a current written quotation and your own test results, not any vendor's general product narrative.

Assessed against exactly the four criteria set out above — an operational model sized for a lean team, application-layer depth consolidated in the same device as volumetric and protocol defence, support delivered regionally rather than from a single hub, and capacity and multi-tenancy licensed on one chassis — HARPP DDoS Mitigator earns a place on the shortlist. As with every other option here, that is a claim to be tested against your own traffic rather than accepted.

Where the incumbent is simply the right tool

This is the section most likely to be skipped and the one that determines whether the rest of the page is worth trusting.

If you are genuinely running a high-density scrubbing estate, a platform engineered for mitigation density in a compact footprint is not a compromise you are tolerating — it is the reason the estate fits in the space and power budget you have. Several of the alternatives above are not designed for that geometry and would not improve it.

If your operating practice is built around diversion and fleet management, the assumption that so often becomes a tax for a small team is, for you, a match. A product that speaks BGP and flow telemetry natively and orchestrates a fleet centrally is doing work you would otherwise script yourself, badly.

If DNS is the service you are actually defending, weight the emphasis accordingly. DNS infrastructure protection is a distinct discipline with its own failure modes, and a product that treats it as a first-class concern rather than one protocol among many is answering a real question.

If no alternative demonstrates equivalence on a replay of your own traffic, the test result outranks every commercial argument. A comparison that always concludes “switch” is not a comparison.

If the team has no capacity and the calendar is against you, do not move. Migration consumes senior engineering time for months, and a migration begun three weeks before a contract expires has already decided its own outcome. Renewing one more term and scheduling the work into a suitable window is better in every dimension.

What a proof of concept should actually measure

If the evaluation does proceed, the design of the test matters more than the length of the shortlist, because most proof-of-concept exercises measure the wrong thing.

Run the candidate out of path on mirrored traffic while the incumbent stays in place, and compare the two devices’ decisions over a defined window rather than their counters. Counters agree far more often than decisions do. Replay your own application traffic, not synthetic floods alone — synthetic volumetric tests are the part every product passes. Define the false-positive threshold you will accept before you see any results, in writing, because a threshold set after the fact is not a threshold. Have somebody other than the vendor’s engineer make a routine policy change, and time it. Include a full business cycle in any behavioural learning window: month-end processing, campaign peaks, and whatever seasonal shape your sector has, because a learning period that excludes the peaks returns them the following month as false positives.

Then note what will not migrate, and cost it honestly. Thresholds and profile names are vendor-specific and do not transfer as files. A learned behavioural baseline does not transfer at all. Accumulated false-positive exemptions and partner allowances usually live only on the device and in one engineer’s memory. Scripts written against a vendor’s interface, report templates and historical trend data stay behind. What does transfer is the network design, your own flow and attack history, standards-based upstream arrangements, and the acceptance criteria you write — which become a permanent asset reusable at the next evaluation.

Standards-based signalling as a portability test

One technical criterion deserves disproportionate weight, because it determines how expensive your next evaluation will be.

Ask whether each candidate talks to the upstream tier over open standards or a proprietary interface. In practice that means BGP Flowspec for filter propagation, remotely triggered black hole routing for blunt intervention, and the DOTS framework for signalling a request for mitigation help between organisations. Flowspec support from carrier to customer is less universal than commonly assumed and should be confirmed with your carrier rather than presumed. DOTS is the standardised answer to the inter-organisational signalling problem and is 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 change. 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 on-premise device and the upstream tier is a commercial arrangement wearing technical clothing.

A decision framework

Three axes, assessed together rather than in sequence.

Geometry. Are you building a scrubbing centre or defending an edge? If the former, the incumbent’s design intent is aligned with yours and the burden of proof sits with any alternative. If the latter, ask whether the capabilities you are licensing are ones your environment will ever exercise.

Depth. Do the incidents you actually experience live at Layers 3 and 4, or above them? Answer from your own incident records, not from industry threat reports. If your last four incidents were application-layer, a volumetric-and-protocol specialist is solving an adjacent problem well.

Operations. Who runs it, with what fluency, using how many consoles, and what happens when that person is unavailable? Where this axis is weak, weight consolidation and support geography heavily, because they are what you will rely on.

Where all three favour change, the decision is straightforward. Where only the commercial axis favours change, attempt a scope negotiation first — establishing which licensed capabilities have produced no rule and no alert in twelve months changes more negotiations than a competitive quotation does. 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, with its signal channel in RFC 9132 and its data channel in RFC 8783. IPFIX, the flow export protocol, is RFC 7011. General denial-of-service considerations are surveyed in RFC 4732, network ingress filtering in RFC 2827 (BCP 38) and RFC 3704 (BCP 84), and DNS-specific operational guidance in RFC 9210 and the DNS security considerations of RFC 3833.

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 a diversion-based 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; Regulation (EU) 2016/679 (GDPR), particularly Chapter V, governs transfers of personal data to third countries and is the correct framework for assessing what any mitigation tier processes outside your jurisdiction.

Vendor documentation. Request current product and support programme documentation directly from each manufacturer rather than from a sales presentation — for A10, the Thunder TPS and aGalaxy documentation; for the alternatives, the equivalent product and support documents. The clauses you will negotiate are defined in those texts, not in datasheets.

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 rather than a slide reproducing it, since positions move between editions. 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.