Most DDoS threat predictions land in the last weeks of the year, and most of them are about size. Terabits per second, new records, a chart that goes up. Meanwhile, the attack that actually takes a mid-sized business offline is often four minutes long, aimed at a login endpoint or an authoritative name server, and finishes before an on-demand mitigation service has finished deciding anything at all.
That gap, between what gets forecast and what gets exploited, is the subject of this piece. Six shifts worth planning around for the coming year, each one paired with a signal that would prove it right and a decision you can actually fund: a contract clause, a monitoring change, a top-up, or nothing at all.
How to read DDoS threat predictions without being sold to
Start with the obvious conflict. Forecasts published by mitigation vendors are drawn from their own telemetry, which is a genuine asset, and they are shaped by what that vendor sells. A provider with enormous scrubbing capacity tends to predict bigger attacks; a bot management specialist tends to predict smarter bots. Neither is lying. Both are describing the part of the problem they can see and bill for.
The discipline is to separate observation from positioning. A trend is sustained and measurable across more than one source: attack duration medians shifting, a protocol being abused month after month, a sector appearing repeatedly in national warnings. A headline event is one record attack, reported once, usually by the company that absorbed it. Both are real. Only one should move your budget.
Prediction pieces are not a new genre either, as anyone who has read back through Richard Stiennon’s top ten threats for 2007 will recognise; the striking thing on re-reading old forecasts is how often the mechanism was called correctly and the business consequence was not.
So apply two questions to every prediction below, including these:
- What signal would prove it right in your environment? Not in a vendor report, in your logs.
- What control changes if it is right? If the answer is “nothing”, the prediction is entertainment.
And keep the frame consistent throughout. Protection is not one product; it covers three distinct surfaces. Network and transport (the pipe and the packets), the application layer (HTTP, APIs, the endpoints that cost money to serve), and authoritative DNS (the thing that tells the world where your service lives). Almost every prediction below plays out on one of those three, and the third is the one most often left unmanaged.
Shift 1: Record volumetric attacks keep rising, but they are not your main risk
Expect more terabit-class records. The supply of poorly secured devices and misconfigured reflectors has not meaningfully shrunk, and reflection amplification has always scaled faster than defensive purchasing cycles. The Spamhaus attack of March 2013, reported at the time by CloudFlare as peaking in the region of 300Gbps, is still the cleanest illustration: the attack method got an order of magnitude cheaper long before anyone’s procurement process caught up.
Here is the part the records obscure. Most organisations do not fail at 2Tbps. They fail at the upstream bottleneck, the firewall state table, or a single application endpoint, often at a tiny fraction of the advertised numbers.
Treat advertised scrubbing capacity as a claim to interrogate rather than a specification. Global aggregate capacity is a sum across every point of presence a provider operates; it tells you very little about the one nearest your customers. If your users are in London and Frankfurt, the number that matters is the capacity and filtering headroom at those locations, plus what happens when traffic is backhauled. That distinction is worth pressing hard, and it is covered in more detail in this breakdown of how much Tbps scrubbing capacity you actually need.
Signal to watch: published records rising while your own largest observed attack stays flat. Action: stop buying headroom and start measuring time-to-mitigate, then write it into the contract.
Shift 2: Application layer and API floods outgrow blunt packet floods
The more consequential growth is at layer seven, where a few thousand well-formed requests per second can do what a hundred gigabits of junk traffic cannot. Low-rate HTTP and API floods look like customers. They complete the handshake, they carry plausible headers, they rotate across residential address space, and they sit comfortably under any rate limit you have set per IP.
Ecommerce absorbs this first at the expensive endpoints: login, search, cart and checkout. A search query that hits the database, a login attempt that triggers a password hash, a cart operation that writes to a session store. None of it looks like an attack on a network graph, because at the network layer there is nothing to see.
Which brings up the gap that catches people out. ISP-level DDoS protection in the UK generally covers a defined slice, typically volumetric traffic heading towards your circuit, and stops short of application layer inspection and your authoritative DNS entirely. If you accept this prediction, the implication is a top-up, not a renewal of the same service.
Aggressive filtering has its own price, and it is paid in false positives: challenge pages that block legitimate mobile users, bot rules that strangle a payment partner’s callback, CAPTCHA fatigue that quietly suppresses conversion. The honest trade-off is that layer seven defence is a tuning exercise with no finished state.
Action to fund now: per-endpoint request baselines. Requests per minute, error rate and latency, broken out by route, with alerting on deviation rather than absolute thresholds. Without that, a low-rate flood is visible only as “the site feels slow”.
Shift 3: Authoritative DNS stays the most under-defended layer
If one prediction in this article is close to safe, it is this one. Attack volume growth frequently plays out not as pipe saturation but as a DNS outage, because DNS is where the dependency is total and the spend is minimal.
Your origin can be healthy. Your scrubbing centre can be clean and idle. If resolvers cannot answer for your zone, you are offline. The 2016 attack against the DNS provider Dyn, which disrupted access to a long list of well-known services in the United States and Europe, remains the reference case: one supplier’s bad day became everyone’s outage. This site covered a smaller but structurally identical event years earlier when EveryDNS came under attack and the dependent domains went dark with it.
Single-provider authoritative DNS is a concentration risk, and the fix is well understood: secondary or dual-provider DNS, with zone transfers or parallel API-driven provisioning. The cost is operational, not financial. Two providers means two sets of records to keep aligned, two failure modes for automation, and a real risk of serving stale answers if the sync breaks. Plenty of teams implement it and then let it drift, which is worse than not having it.
Time-to-live values deserve a decision rather than a default. Long TTLs blunt the impact of an authoritative outage, because resolver caches keep serving old answers; they also slow any emergency re-pointing to a mitigation provider. Short TTLs do the reverse. Pick deliberately, per record, and document why.
Questions for the DNS provider, in plain terms: how many anycast sites answer for your zone, what query rate can a single site absorb, what happens when one site is withdrawn under attack, and is there any contractual commitment to query availability at all. The NCSC’s denial of service guidance collection is a reasonable neutral reference to take into that conversation.
Shift 4: Hacktivist and extortion-driven attacks follow the news cycle
Politically motivated campaigns cluster, and they cluster predictably: around elections, around international summits, around conflict anniversaries, around a government statement that annoys someone. The NCSC’s April 2023 alert on pro-Russia hacktivist groups targeting critical national infrastructure set the template for how these warnings now arrive, and similar advisories have followed across multiple countries since.
Sector targeting has been consistent: government portals, healthcare, financial services, airlines, and increasingly law firms, where the reputational pressure of being seen to be offline is disproportionate to the technical damage.
Ransom DDoS follows a different rhythm. A short demonstration attack, an email naming a cryptocurrency wallet and a deadline, then either escalation or silence depending on whether the group has the capacity it claims. Many do not. Paying has never been a reliable way to make it stop, and it marks you as a payer.
The failure mode with both is organisational, not technical: a warning gets forwarded, read, and archived. Convert it instead into a short response plan with names against each step:
- Who confirms an attack is in progress, using which dashboard;
- Who declares the incident and has authority to trigger diversion;
- Which provider contact is called, on which number, outside business hours;
- What the holding statement says and who publishes it;
- What gets preserved for law enforcement, including netflow and timestamps;
- Who tells customers, and at what duration threshold;
- What gets reviewed within five working days afterwards.
Shift 5: Cheap booter services keep the floor of the threat low and constant
Beneath the record-breakers sits the everyday reality: short, cheap, repeated attacks bought from booter and stresser sites for the price of a takeaway. Law enforcement does disrupt this market, and Europol’s long-running Operation PowerOFF announced the takedown of 27 booter platforms in December 2024. Supply dips. It returns.
Gaming servers, schools and colleges, and small ecommerce sites see this most, frequently from a single aggrieved individual rather than any organised group. The pattern of who buys these services, and why, is set out further in this look at the UK DDoS-for-hire market.
Attack duration, not attack size, is what should drive the always-on versus on-demand decision here. Consider a four-minute booter-grade flood against an on-demand service: detection takes a minute or two, the BGP announcement goes out, routes converge, and by the time clean traffic is flowing the attack has stopped. The subscription was active throughout. The site was down for the whole event. Repeat that twice a week and the service is, in practice, decorative.
Always-on carries steady cost and a latency trade-off that matters for some workloads and not others. At this end of the threat spectrum it usually wins anyway, alongside two unglamorous controls: origin addresses that are not reachable directly, and an awareness that historical DNS records have published your origin IP to anyone who cares to look.
Shift 6: Regulation and contract language start driving spend more than fear
Resilience obligations are moving DDoS from a technical line item towards something a board is answerable for. In the UK, the Cyber Security and Resilience Bill is the piece to track, and supply chain questionnaires from larger customers are already doing similar work by asking what happens to availability when a supplier is attacked.
UK managed DDoS pricing is rarely as simple as the headline figure. Expect the quote to be structured around a clean traffic commitment measured in Mbps or Gbps, a count of protected IP addresses or prefixes, a number of included incident or diversion events, and overage charges beyond any of them. Professional services for onboarding and testing often sit outside the monthly fee. Ask which of those meters you are most likely to trip.
Build the case from downtime, not probability. Hourly revenue or service value multiplied by a realistic outage duration, set against annual spend, is an argument a finance director can test. For many online retailers, a few hours offline at peak trading costs more than a year of managed protection, and at that point the probability argument becomes irrelevant. The structure for presenting that is laid out in this board-ready DDoS protection business case.
Three clauses worth fighting for: a stated time-to-mitigate with a measurement method, an explicit scope of covered protocols and surfaces (including whether DNS and layer seven are in or out), and a definition of who can declare an incident, because a provider that requires your sign-off before diverting will not protect you at 03:00.
Turning predictions into a 12-month plan
Sequence matters more than ambition. Measure cost of downtime per hour first, because everything else is argued from that figure. Close the DNS gap second, since it is the cheapest material improvement most organisations can make. Baseline application traffic per endpoint third. Then test diversion, properly, with the provider, during a maintenance window, and record how long it took.
Set a quarterly rhythm rather than an annual panic: re-check capacity claims against the regions your customers are actually in, run one failover test, review observed attack durations, and look at the renewal date well before it auto-renews. Track your own numbers against these forecasts, because your logs will tell you faster than any report whether application layer activity is rising and whether your attacks are getting longer or shorter.
If you want to go a layer deeper on any of this, the overview of DDoS mitigation approaches is a sensible next read before you start talking to providers.
Frequently Asked Questions
What are the main DDoS threat predictions worth planning around?
Six shifts: continued growth in record volumetric attacks, faster growth in application layer and API floods, authoritative DNS remaining under-defended, hacktivist and extortion campaigns tracking the news cycle, cheap booter services keeping small attacks constant, and regulation plus contract language driving spend. Each one should map to a specific control or clause, not a general sense of unease.
Will AI-driven attacks change DDoS defence in practice?
Probably at the margins, and mostly at the application layer, where generated traffic can mimic legitimate user behaviour more convincingly and make static rate limits less useful. Volumetric attacks already scale without any help from machine learning. The practical response is the same either way: behavioural baselines per endpoint rather than fixed thresholds.
Is a bigger attack size the main risk, or is something else more likely to take a site down?
Something else, usually. Most outages trace back to an upstream bottleneck, a stateful device, an unprotected application endpoint or an authoritative DNS failure, all of which can occur far below any headline attack size. Attack duration and surface coverage predict real downtime better than peak bandwidth does.
Why is authoritative DNS so often the weak point in DDoS protection?
Because it is rarely anyone’s budget line. Scrubbing is bought for the network, a CDN or WAF is bought for the application, and DNS is left with whatever the registrar or hosting provider bundled in. The dependency is absolute, so a provider outage takes you offline even when every other component is healthy.
How should a UK business budget for DDoS protection against these predictions?
Start from cost of downtime per hour, then price the gaps across network, application and DNS separately, since one supplier rarely covers all three well. Read the quote’s meters, clean traffic commitment, protected prefixes, included diversion events and overage, before comparing headline figures. Sound DDoS threat predictions should change what you buy and what you write into the contract; if they change neither, they were just reading material.