DDoS Stress Test: What It Is, When It’s Legal, and How a Real One Runs

Most organizations that own DDoS protection have never watched it handle an attack. The appliance was installed, the scrubbing contract was signed, the WAF rules were tuned once, and since then the whole stack has been waiting for its first real event. Cloudflare’s 2026 Threat Report counted 47.1 million DDoS attacks mitigated in 2025, more than double the year before, so the first real event is a matter of when.

A DDoS stress test is how you find out whether your defenses hold before an attacker does. It also happens to be a term with a split personality: the same words describe a legitimate, regulator-expected security exercise and a category of criminal service. This guide covers both meanings, because knowing where the line sits is the first thing a security team, a compliance officer, or an auditor will ask.

What is a DDoS stress test?

A DDoS stress test is a controlled simulation of a distributed denial-of-service attack, run against systems you own or operate, with documented authorization, to measure whether your defenses detect and absorb it. The traffic is real. The sources are distributed. The only difference from an actual attack is consent, control, and a report at the end.

That definition carries three load-bearing words. Controlled means the traffic ramps up on a schedule you set and stops the moment you say stop. Authorized means the target has proven, in a verifiable way, that the infrastructure is theirs to test. Measure means the point is evidence: which controls fired, which stayed blind, at what traffic level the service degraded, and whether anyone on your side noticed.

Remove any one of those three and you no longer have a stress test. Traffic without control is an outage you scheduled for yourself. Traffic without authorization is a crime, whoever launches it. And traffic without measurement teaches you nothing you can act on or show an auditor.

Is a DDoS stress test legal?

Testing infrastructure you own, with documented authorization, is legal. It is the same legal footing as penetration testing, and regulators have moved from tolerating it to expecting it.

DORA, the EU’s Digital Operational Resilience Act, requires financial entities to test ICT systems supporting critical or important functions at least yearly under Article 24, and its list of test types explicitly includes scenario-based testing of the kind a DDoS simulation delivers. FINMA expects Swiss-regulated institutions to demonstrate operational resilience with evidence. NIS2 extends similar testing expectations across EU essential and important entities.

Attacking infrastructure you do not own is a crime in essentially every jurisdiction, and the services that sell it get dismantled with some regularity. Booter and stresser sites, which offer to flood an arbitrary target for a few dollars, are the version of “DDoS stress testing” that ends in prosecution. Europol announced on 11 December 2024 that Operation PowerOFF, a multi-year international action against DDoS-for-hire services, had taken 27 of the most popular platforms offline across 15 countries, with three administrators arrested in France and Germany.

The part many people miss: enforcement does not stop at the operators. In that same December 2024 action, more than 300 users of the seized platforms were identified for follow-up, Dutch prosecutors charged four people for attacks run through booters, and the US Department of Justice charged platform administrators. Several national police forces even bought search-engine ads against booter-related keywords, so a person searching for one of these services now finds a warning where the storefront used to be.

The line the law draws runs through authorization and ownership, and nothing else. A bank commissioning a 200,000-request-per-second simulation against its own e-banking portal, with change-management sign-off and a signed scope, is doing what its regulator asked. An individual paying to send a fraction of that traffic at someone else’s server is committing an offense. Same packets, opposite legal categories.

This is also why the authorization step in a legitimate test is not paperwork theatre. A provider that will send traffic anywhere a customer points it is a booter with an invoice. A provider that refuses to send a single packet until domain ownership is cryptographically proven has made the abuse case structurally impossible, which is exactly the property you want to show an auditor.

How is a stress test different from a load test?

Teams often assume their load testing covers this ground. It does not, and the gap is worth spelling out because it is where budgets go wrong.

A load test answers a capacity question: how many well-behaved users can this system serve before response times degrade? The traffic is friendly by design. It follows the happy path, completes every request, reuses connections politely, and comes from a handful of cloud instances your firewall has probably been told to ignore.

A DDoS stress test answers a defense question: what happens when the traffic is shaped to hurt? Attack traffic does things legitimate users never do. It holds connections open without finishing requests, busts caches with randomized queries, burns CPU with handshakes it never uses, or arrives as complete, valid requests from tens of thousands of sources at once. Each of those behaviors targets a different layer, and none of them shows up in a load test.

The consequence is that the two tests fail in different places. A load test finds an undersized database pool or a slow endpoint. A stress test finds that your rate limiter keys on requests per second while the attack sends almost none, that your scrubbing provider needed twelve minutes to engage, or that your dashboards looked normal for the entire outage. Our post on the types of DDoS attacks walks through why each attack class defeats a different control, and the record for sheer scale keeps moving: the largest attack in Cloudflare’s 2026 Threat Report, a 31.4 terabit-per-second flood from the Aisuru botnet in late 2025, was nearly six times the biggest attack of 2024.

One more difference matters for realism. Load generators run from a few datacenter IP ranges, which per-IP limits and reputation filters catch trivially. Real attacks come from botnets of tens of thousands of residential and mobile devices. A test that comes from three cloud instances validates your defenses against three cloud instances, and nothing else.

This is the false-pass problem, and it is the single most common way a cheap check produces a dangerous conclusion. Our pillar guide on how to test your DDoS protection covers it in detail.

How does an authorized DDoS stress test actually run?

A legitimate test has a recognizable shape. If you are evaluating providers, or building an internal case for a first run, these are the steps that should exist. Where one is missing, that is a finding about the provider.

Scoping before anything else

You define which domains and services are in scope, which simulation types will run, what traffic levels the run will reach, the time window, and who on your side is watching. You also define the abort criteria in advance: at what point does the run stop even if nobody presses the button. Regulated institutions typically route this through change management, and that paper trail is what makes the exercise auditable later.

Ownership verification, cryptographic rather than contractual

Before any traffic flows, you prove the target is yours. On the Obsidio platform this is a DNS TXT record: you place a verification token in the DNS zone of the domain under test, which only someone with administrative control of that domain can do. No token, no traffic. A signature on a contract asserts ownership; a DNS record demonstrates it. This single step is what separates an authorization-first platform from a booter, because it makes pointing the traffic at a third party impossible rather than merely forbidden.

Gradual ramp, live metrics, instant abort

A proper run does not open at full scale. It starts in a controlled window with conservative limits and ramps up as confidence grows, while you watch real-time metrics: requests per second, success rate, data transferred, and how your edge responds. Any run can be aborted live, at any second. That combination, ramp plus abort, is what turns a simulated attack into a controlled experiment. You find the level at which degradation begins without being forced to ride through it.

A report you can hand to an auditor

The run ends with evidence, not a screenshot. Obsidio generates cryptographically attested, tamper-evident reports inside Trusted Execution Environments, mapped to FINMA, DORA, and NIS2 expectations. The distinction matters more than it first appears: an attested report is an artifact a third party can verify, while an internal test log is a claim your own team has to vouch for. Auditors know the difference.

What should a stress test actually cover?

One test type is not coverage. Attacks fail in genuinely different places, and a defense tuned for one class can be structurally blind to another. A volumetric flood exercises your bandwidth and scrubbing; a slow attack like Slowloris sends almost no traffic at all and walks past every rate-based control; a TLS flood burns CPU on handshakes; a flood of real browser sessions defeats bot detection because there is no bot to detect.

Obsidio runs ten simulation types across four categories: application-layer floods, slow attacks, connection exhaustion, and protocol-specific or scripted traffic. A sensible first programme does not run all ten at once. It starts with the classes most relevant to your architecture, then expands. The attack-type overview explains which class stresses which layer, and the product page lists the full catalog.

Coverage also has a second axis that teams forget: detection. Every run should answer not only “did the defenses hold?” but “did anyone find out?” Whether your dashboards moved, whether your SIEM logged anything, and whether on-call was paged are answers that live on your own consoles, so someone on your side needs to be watching during the window. A control that fails silently and a control that works invisibly are both findings.

How often should you stress test?

A single test is a snapshot, and infrastructure does not stand still. The CDN contract gets renegotiated, an engineer relaxes a timeout to fix a customer complaint, a new API ships outside the WAF policy. Any of those can quietly undo a result that was true six months ago.

For regulated financial entities the floor is set externally: DORA expects ICT systems supporting critical or important functions to be tested at least yearly, and our guide to DORA compliance covers what evidence that testing has to produce. Treat that as a minimum rather than a target.

Beyond the regulatory floor, two triggers matter more than the calendar. Retest after you fix something, because a mitigation that was configured under pressure and never exercised is exactly the kind of control that fails twice. And retest after material changes to the edge: a new CDN, a migration, a new public-facing service. The cadence the platform is built around is a loop, “Configure. Test. Adapt. Retest.”, precisely because the second run is where you learn whether the first one changed anything.

What does a stress test find that a config review cannot?

Configuration reviews verify that settings exist. They cannot verify that settings hold under concurrency, that vendor claims survive contact with realistic traffic, or that the interaction between your CDN, your load balancer, and your origin behaves the way the diagram says. Those properties only exist under real traffic.

The typical findings from a first authorized test are rarely “the protection is missing.” They are quieter and more expensive than that.

The scrubbing service engaged, but minutes after degradation began. The rate limiter worked, and also throttled the payment callback from a partner. Failover worked, and the failover environment had a quarter of production capacity. Auto-scaling scaled, and the invoice arrived. None of those appears in a config review, and every one of them changes what you do next.

Strength is proven, not promised. Buying DDoS protection settles what you spent. A stress test settles what you can survive.

There is also the organizational finding. An attack at 3 a.m. is a people event as much as a technical one, and the first authorized run is usually the first time the escalation path gets exercised end to end. Finding out that the runbook names a person who left last year is cheap during a scheduled window. It is very expensive during a real attack.

Where to start

Start small and legitimate. Pick one service, get sign-off, verify ownership, and run one attack class at conservative scale during a window your team is watching. The first run is less about the traffic level than about proving the loop works: authorize, configure, simulate, report. Every later run gets faster and more ambitious.

Obsidio runs DDoS stress tests as controlled, authorized simulations from 100,000+ globally distributed real devices, so per-IP limits and reputation filters get tested the way an actual distributed attack would test them. Domain ownership is verified by DNS TXT record before a single request is sent, runs ramp up gradually, any run can be aborted live, and the result is a cryptographically attested report mapped to FINMA, DORA, and NIS2.

To scope an authorized stress test against your own infrastructure, see the Obsidio platform or get in touch with the team. Independent, neutral, verifiable: resilience you can prove.