The UK's National Cyber Security Centre keeps a standing alert urging organisations to review their denial-of-service defences. The numbers bear it out: Cloudflare mitigated 23.2 million network-layer DDoS attacks in the first half of 2026, around 5,300 an hour. Most were small and brief, with 96.6% under 500 Mbps and nine in ten over within ten minutes. Small is relative, though. A 100 Mbps attack will saturate an unprotected server, and a half-minute burst leaves no time for anyone to pick up a phone.
Everything that follows is decided before that half minute. Protection is not about preventing the attack; it is about cutting what it costs you.
What is a DDoS attack, and why is the firewall too late?
A distributed denial-of-service (DDoS) attack floods a service with traffic launched from thousands of sources at once, typically a botnet or misconfigured third-party servers that amplify the requests. There are three families: volumetric attacks, which exhaust bandwidth; protocol attacks, which exhaust intermediate equipment such as load balancers or firewalls; and application-layer attacks, which drown the server in legitimate-looking requests.
The volumetric family is the one that defeats the instinct to solve this in-house. If your Internet link carries 1 Gbps and the attacker sends ten, everything downstream of the flood, firewall included, is left staring at a saturated link. Mitigation has to happen before the traffic reaches you: in the carrier's network, or in a filtering service with more capacity than the attack. Hence the term “upstream defence”.
The 2026 numbers add an important shift. Reflection and amplification are gaining ground: DNS-based attacks accounted for 34.3% of network-layer activity over the half-year, and CLDAP (Connectionless LDAP) floods, which abuse domain controllers exposed over UDP, grew 580% in a single quarter to become the third most common vector, according to Cloudflare's half-year report.
The contracts to sign before the attack
There are three layers to negotiate, calmly, while the service is still standing. First, the carrier: know what mitigation your connectivity contract includes, at what thresholds and how fast. Second, a cloud traffic-filtering service able to absorb what your link cannot. Third, for web services, a CDN with a web application firewall, which keeps traffic away from your origin and soaks up layer-7 attacks. The UK NCSC's denial-of-service guidance adds a recommendation as sensible as it is uncommon: consider more than one provider for the functions that cannot go down.
Then there is the choice between always-on and on-demand protection. Cloudflare has documented a record-volume attack that lasted just 35 seconds: by the time an alert reaches an analyst, it is over. Mitigation switched on by phoning someone cannot make that deadline; for a service that cannot afford downtime, protection has to run permanently and decide on its own.
DNS deserves a contract of its own. If your authoritative DNS goes down, the website stops being findable as soon as resolver caches expire. DNS floods reached 40% of network-layer attacks in the second quarter of the year, so your DNS provider needs an anycast network and dedicated protection, and your records need time-to-live (TTL) values long enough to ride out an interruption.
Which part depends on your architecture?
Some decisions no provider can take for you. The central one is what gets sacrificed first. Separating critical flows from dispensable ones, serving from cache whatever needs no session and defining a minimal service mode: that turns a complete outage into an inconvenience. The hierarchy is decided in a meeting room, with time to think, and built into the architecture; when the attack comes, all that remains is to carry the plan out.
The second front is elasticity. The NCSC advises designing to scale quickly for whatever filtering lets through, whether via cloud APIs or reserve capacity in the data centre. Against raw volume, scaling loses; it earns its keep against protocol and application-layer attacks, where it buys you minutes.
You also owe the rest of the Internet one thing: not becoming ammunition. A domain controller with port 389/UDP exposed to the Internet is precisely the reflector that feeds CLDAP floods. Hardening exposed services, open DNS resolvers included, keeps your infrastructure from amplifying an attack on someone else.
Who launches these attacks, and why?
Across the EU, DDoS was the dominant incident type in the latest period analysed by ENISA: 77% of reported incidents, hacktivists behind most of them, though only 2% of their actions caused real service disruption. The trigger is usually geopolitical and the reaction immediate: after the military operation Israel and the United States launched against Iran in late February (Epic Fury), researchers recorded 149 hacktivist DDoS claims against 110 organisations within 72 hours, as Cloudflare's report notes. The NCSC alert cited at the top of this article singles out the same sustained campaign by pro-Russia groups against local government and critical infrastructure.
The other engine is the market: attack capacity is for hire. Operation PowerOFF, the Europol-coordinated police action against DDoS-for-hire services, took down 53 domains and uncovered databases holding more than three million user accounts. And when real disruption falls on a service a country depends on, the result looks like what Norway went through this summer, as The Record reported: three attacks in three months on the state identity gateway, the last one running past thirty hours.
How is it detected, and who responds?
A ten-minute attack is not managed: it is absorbed. What is managed comes afterwards, because a short DDoS leaves TCP retransmissions, timed-out connections and cascading degradation that can take hours to clear, as Cloudflare documents. Detection requires a baseline of normal traffic, your mitigation provider's alerts wired into your own alerting, and a security operations centre (SOC) that treats availability as one more security signal. At Hard2bit we keep coming back to that point because it is where incidents drag on: the attack ends and nobody watches the aftershocks.
The response is written in advance: you need an incident response plan that covers the denial-of-service scenario, a status page hosted away from the affected infrastructure and an incident-response retainer already signed with your response provider, so you are not negotiating rates while the service is down. Communication with users and authorities starts in the first hour. Then comes the yearly exercise: the NCSC recommends testing your defences to learn what volume and which attack types they withstand, rather than finding out in production.
Does regulation require anything specific?
NIS2 treats severe operational disruption of a service as a notifiable incident, even if not a single record is lost: the alert and notification clocks also run when what fails is availability. DORA is stricter with financial entities and turns rehearsal into an obligation: operational resilience is demonstrated through periodic testing, not asserted in writing.
Promising the right thing
Guaranteeing that no attack will come is an impossible commitment: with 128,000 mitigated daily on Cloudflare's network alone, whether one will come is no longer the relevant question. What can be promised, and measured, is the outcome: a DDoS costing minutes of controlled degradation instead of days of downtime and weeks of aftershocks.
The cost asymmetry is the best news in this guide: a mitigation contract is reviewed in an afternoon and an exercise fits in a morning, while the third round of Norway's summer cost the country more than a day of degraded services. At Hard2bit we do that work with organisations that cannot afford an outage, and the most expensive part is usually discovering too late that a piece was missing.
This article combines analysis of public sources (Cloudflare, ENISA, NCSC, Europol) with general architecture and procurement recommendations. Figures relate to the periods stated by each source and may evolve. No measure should be applied without assessing it against each organisation's architecture, contracts and regulatory obligations; changes to exposed services, such as closing ports or migrating DNS, should be planned and tested before being made in production.
