Summary

  • NETSCOUT’s 1,286% figure compares 1,095 attacks that cleared either 1 Tbps or 1 Gpps in 1H 2026 with 79 in 1H 2025. The published arithmetic is consistent; it describes threshold crossings, not a 1,286% increase in traffic, outages, victims, protection spending or market revenue.
  • The count is a reason for network operators to examine bandwidth and packet-processing exposure separately. It cannot tell a buyer how often its own services were targeted, how mitigation performed, or whether the buyer needs more installed capacity.
  • NETSCOUT’s current report page says the period contained more than 9.1 million attacks and its infographic gives 9,146,021, while the live Global Highlights page displays 4,267,744 for January–June 2026 without a public explanation of the difference. The inconsistency concerns the broader total, not the separately reported 1,095 threshold count.

A large percentage, with a narrow measuring unit

The headline can be checked in one line: (1,095 − 79) ÷ 79 = 12.86, or a 1,286% increase after rounding. The new count is about 13.9 times the old one. NETSCOUT’s issue 17 infographic calls these “attacks” that cleared 1 Tbps or 1 Gpps. It does not say that the entire DDoS landscape grew thirteenfold, that every operator saw more attacks, or that the attacks became thirteen times more damaging.

The denominator matters. Seventy-nine is a small prior-year count, so a few dozen additional threshold crossings would move the percentage sharply. The 1,095 observations are still material: the report describes a class of very high-capacity attacks appearing more often in its telemetry. But the percentage is an expression of the change in one selected cohort, not a universal risk multiplier.

The word “or” also matters. One terabit per second measures the rate of data transfer. One billion packets per second measures packet-processing load. A small-packet flood can impose a different burden from a high-bandwidth stream. The infographic combines both cutoffs into one headline count and does not publish the split between attacks that crossed only the bandwidth threshold, only the packet-rate threshold, or both. Nor does the public summary explain how an attack crossing both thresholds is treated in the combined count. A buyer cannot use the single figure to size either dimension by itself.

A simple calendar average is roughly 6.0 qualifying attacks a day in the 181-day first half of 2026, compared with 0.44 a day in the 181-day first half of 2025. That arithmetic is not a daily time series. It says nothing about whether events were evenly distributed, concentrated around a few days, simultaneous, or visible on any one customer’s network. The infographic’s phrase “several times a day” is a summary of the period count, not a claim that every day carried six such events.

A threshold crossing is not a service incident

The count records attacks in NETSCOUT’s observed data. It is not a count of businesses that lost service. An event can cross a rate threshold without overwhelming a protected network; another event below either cutoff can still exhaust connection state or application capacity. The report page itself says that a link need not saturate before a service is disrupted and that traffic spread across destinations can evade per-host thresholds. Those are reasons to examine more than peak bandwidth, not evidence that the 1,095 attacks caused a corresponding number of outages.

The same report page says direct-path methods accounted for 64.40% of observed attacks, and that attacks lasting one minute or less rose from 1.6% in 2H 2025 to 3.1% in 1H 2026. These figures indicate changes in the broader observed mix. NETSCOUT does not break either measure out for the 1,095 high-capacity cohort. It would be wrong to multiply the metrics together or to say that six high-capacity attacks a day were all short, direct-path floods.

The report’s market framing is visible in its recommendations. NETSCOUT says service providers need dedicated mitigation capacity at network edges, selective response and headroom for concurrent events; it describes on-premises defenses and cloud-delivered mitigation as complementary. Those are plausible design choices for a provider or enterprise to evaluate. They are also recommendations from a company that sells DDoS intelligence and protection. The commercial position is relevant context, not proof that the telemetry is false.

The infographic also describes a DDoS-for-hire subscription ladder from zero to five figures a month and says attacks are sold on delivery rather than volume. This is a signal about how the report presents attacker supply, not a survey of executed prices. It names no representative plans, transactions or terms, and it says nothing about what a defender pays for edge capacity, cloud scrubbing, or a service-level guarantee. The price ladder cannot be turned into the revenue pool available to protection vendors.

The buyer has to translate the count into its own network

For a carrier, cloud operator or enterprise, a useful capacity review starts with where traffic enters and which services sit behind each link. The questions are practical: What is the sustained bandwidth available at the relevant edge? What packet rate can the mitigation path inspect and filter? How much clean traffic can be forwarded during an event? Which upstream or cloud service can absorb overflow, and how quickly can it be engaged? How are legitimate customers protected when filtering is tightened?

Those questions involve more than a single appliance rating. A provider may use always-on detection at its own edge, route selected traffic to a scrubbing service, or keep local equipment for attacks that cannot wait for a remote handoff. A company may rely on an upstream provider for volumetric attacks while keeping application-layer defenses near the service. The best mix depends on network topology, customer commitments, latency tolerance, concurrent demand, existing capacity and the cost of false positives. NETSCOUT’s period count does not disclose those conditions for any named buyer.

The metrics needed for procurement are therefore closer to service outcomes than to a global tally. Buyers would want to know the affected interfaces and destinations, the duration and peak bps and pps for each event, the time to detect and mitigate, the amount of legitimate traffic dropped, and whether protection remained available during simultaneous attacks. Contracts then need to specify who provides clean traffic, what capacity is committed, how overflow is priced, which response times are guaranteed, and what evidence is supplied after an incident.

Without those links, “more attacks above a threshold” can be used to sell a stronger sense of urgency but cannot determine a budget. It may justify checking whether a service depends on a single upstream path or whether packet-processing limits are documented. It does not establish that a provider should buy a fixed number of additional terabits, switch vendors, or sign a multi-year cloud-scrubbing contract.

The broader attack total is not reconciled in the public views

The high-capacity comparison is separate from a mismatch in the report’s wider attack total. NETSCOUT’s issue 17 page says ATLAS recorded more than 9.1 million attacks in the first half of 2026. Its infographic gives the exact figure as 9,146,021. The live Global Highlights page, which labels the same January–June 2026 period, displays 4,267,744 attacks and a 14.13% change from the preceding six months. The public pages do not explain why the displayed totals differ.

That gap is too large to treat as rounding. It could reflect a difference in definitions, data pipeline, page update or another scope distinction, but the public material reviewed does not identify which. Those possibilities are not a reconciliation. The article therefore does not use either total to calculate overall DDoS growth. The mismatch does not alter the explicitly stated 1,095-versus-79 high-capacity count, but it makes the reporting boundary important for anyone comparing totals across pages or periods.

This is the difference between a signal and a market forecast. The threshold count tells operators that NETSCOUT recorded more events at the selected scale. It does not show how the events were distributed among networks, what losses they caused, how successfully they were mitigated, or whether protection contracts grew. A buyer can treat the count as a prompt to test its own readiness. A market analyst still needs prices, contract activity, deployments, utilization or vendor revenue before claiming the DDoS protection market expanded by 1,286%.

What the public evidence supports

  • NETSCOUT’s issue 17 report page supports the 1H 2026 period, the more-than-9.1-million headline, the 1,286% threshold claim, the 64.40% direct-path share, the short-duration comparison and the company’s stated mitigation recommendations.
  • The official issue 17 infographic gives 1,095 attacks above either threshold, the prior-year count of 79, the exact 9,146,021 broader total, and the report’s DDoS-for-hire price-ladder graphic.
  • NETSCOUT’s Global Highlights page displays 4,267,744 attacks for January–June 2026. No reconciliation to the issue 17 report page or infographic is visible there.

The defensible reading is narrower than the press percentage: NETSCOUT recorded many more high-capacity threshold crossings in the first half of 2026 than in the comparable half a year earlier. That is a reason to ask better operational questions. It is not, by itself, a count of customer harm or a forecast of security spending.

  • The NETSCOUT 2H 2025 report supplies the prior-period context for the short-duration comparison; it does not break out the high-capacity cohort.
  • The NETSCOUT 1H 2025 report provides period context for the year-over-year comparison; it does not establish buyer outcomes or market spending.