Most DDoS protection is bought on a headline capacity number and a datasheet, then tested for the first time during a real attack. Offerings range from ISP clean-pipe services and cloud scrubbing centres diverted by BGP or DNS, to CDN and web application firewall edges, API gateways with rate limiting and on-premises appliances. Each covers a different slice of the volumetric, protocol and application layer attacks that CISA, the FBI and MS-ISAC describe in their joint guidance. This vendor-neutral guide helps network, security and procurement teams write requirements, compare architectures, ask the questions that expose weak contracts and run a proof of concept that measures what the service actually does. For concepts and in-house controls, see the DDoS Protection Guide.
Key takeaways
- Buy by service, not by product. Inventory internet-facing services (web, APIs, DNS, VPN and remote access, mail, non-HTTP applications) and the layer each needs protecting at; no single deployment model covers them all.
- Always-on versus on-demand is a time-to-mitigate decision. On-demand diversion is cheaper but leaves a gap while traffic is rerouted; always-on adds latency and dependency every day. Decide per service using its tolerable outage.
- Capacity claims are not a test result. Ask for per-site and per-customer limits in Gbps, packets per second and requests per second, then verify them with an authorised test and contractual SLAs.
- Layer 7 is where most services fail. Request floods against search, login and API endpoints exhaust back ends long before bandwidth runs out, so evaluate bot handling and rate limiting as seriously as scrubbing capacity.
- The provider becomes part of your attack surface. A CDN or proxy holds your TLS keys and controls your routing, and its API tokens and portal accounts are privileged identities you have to govern.
Define requirements
NCSC frames DoS preparation as understanding your service, understanding upstream defences, creating a response plan and testing it. Turn that into written requirements before talking to providers:
- Service map: for each service record IP prefixes, whether you own a /24 or larger (needed for BGP diversion), DNS hosting, protocols, origin locations and the upstream ISPs. Include High Value Assets, as CISA's federal DDoS supplement advises.
- Tolerable outage: minutes of degradation the business accepts per service. This drives always-on versus on-demand and the time-to-mitigate SLA.
- Threat profile: volumetric floods and reflection amplification (MITRE ATT&CK T1498.001, T1498.002), state exhaustion and service exhaustion floods (T1499.002) and application exhaustion floods (T1499.003).
- Traffic constraints: data residency for decrypted traffic, whether you can share TLS private keys, IPv6 and non-HTTP protocols, and latency budgets.
- Operating model: self-managed rules, co-managed or fully managed with a provider security operations centre, and the hours your own team can actually respond.
Capability areas
| Model | How traffic reaches mitigation | Strengths | Watch for |
|---|---|---|---|
| ISP clean pipe | Filtering in the carrier network, often with remotely triggered blackholing (RTBH) | No routing change, simple contract | Single upstream; RTBH using the BLACKHOLE community (RFC 7999, 65535:666) drops all traffic to the prefix, completing the attack for you |
| Cloud scrubbing, BGP diversion | Provider announces your prefix, scrubs, returns clean traffic over GRE tunnels or interconnects | Protects whole networks and non-HTTP services | Needs a /24 (IPv4) or /48 (IPv6); diversion and convergence time; return tunnel MTU |
| Cloud scrubbing, DNS diversion | DNS record points to provider, which proxies to origin | Fast to deploy for named services | Origin IP exposure; DNS TTLs; direct-to-IP attacks bypass it |
| CDN or reverse proxy edge | Always-on anycast proxy for web and API traffic | Absorbs volume, caches, layer 7 rules and bot controls | Holds TLS keys; HTTP and HTTPS mainly; origin must be locked to the edge |
| On-premises appliance | Inline or out-of-path device in your data centre | Low latency, fine-grained stateful protection | Cannot stop floods that saturate the upstream link; usually paired with cloud signalling |
| Cloud provider native protection | Built into the hyperscaler network for its public IPs | Always on, no diversion | Scope limited to that cloud; advanced tiers and cost protection vary. See the Microsoft Azure Security Guide |
Hybrid designs combine an appliance or edge with cloud scrubbing and signal between them. The IETF DDoS Open Threat Signaling architecture (DOTS, RFC 8811) defines a client in the target network that requests mitigation from a provider's server over a signal channel designed to work while links are saturated. Ask whether a provider supports DOTS or a proprietary equivalent. BGP Flow Specification (RFC 8955) lets a provider or ISP push rate-limit, discard or redirect rules for matching flows, a finer tool than blackholing. DNS deserves its own line: if authoritative DNS falls, every service falls with it. See the DNS Security Guide. For APIs, rate limiting and quota enforcement address OWASP API4:2023 Unrestricted Resource Consumption. See the API Security Buyer's Guide.
Evaluation criteria
Weights are illustrative; adjust them to your service map and tolerable outage.
| Criterion | Weight | What good evidence looks like |
|---|---|---|
| Time to mitigate | 20% | SLA in minutes from detection or from your request, for each attack class, with how it is measured and credited |
| Usable capacity | 15% | Per-region and per-customer limits in Gbps, Mpps and requests per second, and how capacity is shared between customers under concurrent attacks |
| Layer 7 and API protection | 15% | Rate limiting by path, method, key and session; bot detection; challenge options that do not break API clients |
| Coverage | 10% | IPv6, non-HTTP protocols, DNS, multi-cloud and on-premises prefixes |
| Detection and false positives | 10% | Baseline learning period, tuning controls, ability to run rules in log-only mode |
| Visibility and reporting | 10% | Real-time dashboards, flow and request logs, SIEM export, post-attack reports with dropped versus passed traffic |
| Operations and support | 10% | 24x7 response, named escalation, run books, joint exercises |
| Commercials | 10% | No surprise billing for attack traffic, clear overage terms, exit and termination terms |
In framework terms the purchase supports NIST SP 800-53 SC-5 Denial-of-service Protection and SC-7 Boundary Protection, CP-2 Contingency Plan for the response, and NIST CSF 2.0 PR.IR-04 (adequate resource capacity to ensure availability is maintained). NIST SP 800-189 covers the routing side: source address validation, uRPF, RTBH and Flowspec.
Questions to ask vendors
- Is mitigation automatic, and will you notify us when it starts and stops? NCSC lists this, with the next four questions, as points to agree in advance with providers.
- Will you throttle our bandwidth above a limit, and can you terminate the service or sinkhole our traffic during a large attack? Will you contact us first?
- How long does it take to enable extra mitigations, and how quickly is a shut-down service re-enabled?
- Will we be billed for attack traffic or excess resource usage, including at the origin cloud?
- For on-demand: what is the measured time from our request, or your detection, to traffic being scrubbed, and who can trigger diversion (portal, API, DOTS, phone)?
- What is the largest attack you have mitigated for a single customer, and what is our contracted share of capacity when several customers are attacked at once?
- How do you handle encrypted traffic without our private keys, and if we share keys, how are they stored and who can access them?
- Do you share backbone, data centres or a reseller relationship with our other providers? NCSC warns that multiple providers only help without shared dependencies.
- How are portal accounts and API tokens for rule changes protected, scoped and logged? These are privileged non-human identities. See the API Key Management Guide.
- What is your process and notice period for an authorised load test?
Red flags
- A single "network capacity" figure with no per-customer limit, no packets-per-second figure and no layer 7 throughput.
- SLAs that start the clock at "mitigation initiated" rather than at detection or your request, or that exclude attacks above a size.
- Blackholing presented as mitigation: it makes the target unreachable.
- No way to lock origins to the provider's ranges, so attackers can bypass the edge by hitting the origin IP directly.
- Refusal to permit any authorised testing, or no post-attack report showing what was dropped.
- Contract terms that allow the provider to drop you during a large attack with no notice.
Proof of concept
NCSC advises testing both network and application layer defences because thinking you are prepared is not the same as knowing, and using legitimate testing providers. CISA also recommends at least one DDoS tabletop exercise.
- Agree written test authorisation with the provider, your ISP and any cloud host before generating traffic; use an authorised testing service and a test prefix or hostname, never production without sign-off.
- Onboard one web application, one API and one non-HTTP service. Lock the origin to accept traffic only from the provider and confirm a direct-to-origin request fails.
- For on-demand services, trigger diversion and measure time to clean traffic, BGP convergence and any session loss; then withdraw and measure the return path.
- Run controlled volumetric, SYN or state exhaustion, and HTTP request flood tests at agreed rates. Record time to detect, time to mitigate and the percentage of legitimate synthetic transactions that still succeed.
- Test layer 7 rules on login, search and an API endpoint, first in log-only mode, then enforcing, and measure false positives against real client traffic.
- Confirm alerts reach your SIEM and on-call team, and that the post-test report matches your own monitoring from external locations.
- Run a tabletop using the provider's escalation path and your Incident Response Plan Template, including the decision to fail over or accept degradation.
- Agree go-live metrics: time to mitigate per attack class, legitimate transaction success rate under attack, false positive rate, percentage of internet-facing services onboarded and origins locked, and exercises completed per year.
Primary sources used here: the CISA, FBI and MS-ISAC guide Understanding and Responding to Distributed Denial-of-Service Attacks, NCSC Denial of Service (DoS) guidance, NIST SP 800-189, IETF RFC 8811 DOTS Architecture, IETF RFC 8955 Flow Specification, IETF RFC 7999 BLACKHOLE Community and MITRE ATT&CK T1498 Network Denial of Service.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: DDoS Protection Guide · DNS Security Guide · API Security Buyer's Guide · Business Continuity and Disaster Recovery Guide · Cyber Resilience Guide