Skip to content

Sector

DDoS Protection for Government and Critical Infrastructure

Last updated: August 2026 · You cannot block a population · Reading time ~13 min

A wide stone gateway standing open with no doors, a broad teal-green flow passing through it, amber light pressing against the wall on both sides without entering, and a small watch post set back beside the opening.

A public service cannot refuse a population to save itself, which removes the cheapest countermeasure in the field and reshapes everything above it. Add three constraints: continuity is a duty rather than a commercial target, supplier and jurisdiction dependency is itself a policy question, and evidence must survive to reach a body that will ask for it. Capacity is the easy part of this problem.

Public services face the same attacks as everyone else under constraints that remove several of the standard answers. The most important one is simple and rarely stated: a public service cannot refuse a population to protect itself.

Everything distinctive about this sector follows from that, plus the fact that its downtime is not a commercial inconvenience but a failure of an obligation.

Network topology: the internet reaches an ISP edge router, then an inline DDoS appliance, then the firewall, the core switch and the server farm. A dashed loop over the appliance marks the hardware bypass that keeps traffic moving if the unit loses power.
Sharp version (SVG)

At a glance

ApplianceConstraintWhat it removesWhat has to replace it
Cannot refuse a populationGeographic blocking as a routine responseBehavioural separation, and rate control per source
Continuity is a dutyCost-based tolerance for downtimeA stated tolerance agreed by someone accountable
Dependency is a policy matterChoosing suppliers purely on capabilityDocumented behaviour when a supplier is unreachable
Evidence reaches an authorityTelemetry that lives only in a consoleLocal retention and unassisted export

The first row is the structural one. Removing geographic blocking removes the fastest crude countermeasure and forces every other control to be better calibrated.

The countermeasure you cannot use

Geographic and network-level blocking is the fastest crude response available to most estates. A commercial service can decide that an entire country is not worth the trouble for the next four hours and act accordingly.

A public service usually cannot. Citizens travel and use foreign networks. Services are reached through carriers whose addressing does not map neatly to a territory. And a government portal that refuses a region to defend itself has produced a political problem larger than the outage.

There is a second reason, less often noticed: campaigns targeting public services increasingly originate from domestic residential addresses, so geographic filtering removes legitimate users and leaves the attack in place.

The practical consequence is that everything else has to be better. Per-source rate control, behavioural separation, and thresholds calibrated to real traffic are not refinements here; they are what remains when the blunt instrument is unavailable. Calibration discipline — measuring the legitimate peak before setting anything — matters more in this sector than in any other.

Continuity as a duty rather than a target

Commercial estates set availability targets by weighing downtime cost against defence cost. Public services often cannot express the numerator in money, which tends to produce one of two failures: an unstated requirement that everything must always work, or no stated requirement at all.

Both are unfundable. The useful move is to make someone accountable state the tolerance explicitly, per service:

  • Which services must not be interrupted at all, and why.
  • Which may degrade, how far, for how long.
  • Which may be unavailable, and what the public is told while they are.

That document does more for a procurement than any technical requirement, because it is the only thing that turns “critical” into a number a design can be built against. It is also the sixth line of the sizing record, and the one most often left blank.

Dependency becomes a policy question

In a commercial estate, supplier dependency is a risk to be priced. In public infrastructure it is frequently a policy matter, and the two produce different architectures.

The technically honest framing avoids the rhetoric. Three properties are testable, and they are what most sovereignty requirements are actually reaching for:

What stops when an external service is unreachable. Answered per function, not per product. This is the fail-operational question, and in this sector it is asked in its strongest form because the scenario includes degraded international transit rather than only a supplier outage.

Where classification data goes. Detection performed elsewhere requires traffic characteristics to travel there. What travels, in what form, to which jurisdiction, with what retention — worked through in local versus cloud-dependent detection.

Whether the arrangement can be exited. A dependency that cannot be unwound is a concentration, and supply-chain security is an explicit obligation under NIS2 rather than a preference.

Where equipment is manufactured is a separate argument with separate merits, and conflating it with these three testable properties weakens all four. The jurisdictional dimension is treated on its own terms in vendor jurisdiction risk, and the extreme case — no external path permitted at all — in air-gapped and restricted networks.

Visibility attacks and the communications problem

A substantial share of attacks on public services aim at visibility rather than damage. A public-facing page unavailable for twenty minutes is the objective, because the outage itself is the message and will be screenshotted.

This changes the response calculus in a way that is worth planning for rather than discovering. The operational impact may be modest while the reputational impact is not, which means communications preparation is part of the defence rather than an afterthought.

Two cheap measures do most of the work:

A static fallback. A read-only version of essential public information, hosted separately from the systems under attack, on different infrastructure with different addressing. It keeps the public informed and removes the pressure that produces bad decisions at 03:00.

A pre-drafted statement with a named owner. Written before the incident, because the version written during one is always worse and always later.

The structural analysis of these campaigns — how they organise, and what that means for defenders — is in hacktivist DDoS campaigns.

Evidence reaches an authority

Under NIS2 an essential entity reports on a staged timetable, and the report requires material that exists by then or does not.

The requirements are the same ones any regulated estate needs — local retention beyond the reporting window, export your own staff can perform unassisted, synchronised and demonstrable timestamps — with one addition specific to this sector: the recipient may be a national authority whose format expectations differ from a commercial insurer’s. Establish the format before the incident.

What to specify

  • Full function with no external connectivity, stated per function.
  • Local classification, with what leaves the estate documented.
  • Local evidence retention covering the reporting deadline, and unassisted export.
  • Per-source rate control and behavioural separation, since geographic blocking is unavailable.
  • A stated continuity tolerance per service, agreed by someone accountable.
  • A static fallback on separate infrastructure, tested.
  • Exit terms with a period, because dependency is a supervisory concern.

Nothing on that list is a capacity figure. Capacity is the part of this problem with a straightforward answer, and it is arithmetic rather than judgement.

Frequently asked questions

Why not just block traffic from outside the country?
Because citizens travel, use foreign networks, and reach services through carriers that do not resolve neatly to a territory — and because a public service refusing an entire population to protect itself has usually caused a larger problem than the attack. It is also a countermeasure that fails against the attacks most likely to target public services, which increasingly use domestic residential addresses.
Does sovereignty require domestic equipment?
That is a policy question this page cannot answer for any jurisdiction, and the honest technical statement is narrower: what matters architecturally is whether the defence keeps working when external services are unreachable, and where classification data goes. Those are testable properties. Where equipment is manufactured is a separate question with separate arguments.
What about hacktivist campaigns aimed at public sites?
They are common, usually modest in size, and aimed at visibility rather than damage — a brief outage of a public-facing page is the objective, because the outage is the message. That changes the calculus: the reputational cost of the outage may exceed its operational cost, and communications preparation matters as much as capacity.
Is a static fallback page worth building?
For most public services, yes, and it is one of the cheapest measures available. A read-only version of essential information, hosted separately from the systems under attack, keeps the public informed and removes the pressure that produces bad decisions. It needs to exist before it is needed and be tested like anything else.

Sources

  1. Directive (EU) 2022/2555 (NIS2)

    EUR-Lex · 2022-12-14 · regulator · accessed 2026-08-17

    Essential-entity obligations, supply-chain security, and staged incident reporting.

  2. The NIST Cybersecurity Framework (CSF) 2.0

    NIST · standard · accessed 2026-08-17

  3. SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security

    NIST · standard · accessed 2026-08-17

    Relevant where the critical infrastructure in question is operational rather than administrative.

  4. RFC 4732 — Internet Denial-of-Service Considerations

    IETF · 2006-11 · standard · accessed 2026-08-17

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors