Belnet's 2021 DDoS Outage Made Shared Public-Network Resilience

Summary

Belnet's 2021 annual report says the organisation was hit by a major volumetric distributed denial-of-service attack on 3 and 4 May. Its live status record documents customer connectivity problems, successive attack waves, alternate traffic paths, mitigation rules, stabilisation work and longer-term protection planning. [1][2]
An official federal parliamentary transcript says roughly 200 connected organisations, including universities, public authorities and research institutions, experienced varying degrees of internet-access disruption on 4 May. It records that Belnet activated its crisis procedure, contacted the Centre for Cybersecurity Belgium and had the situation under control by the evening. [7]
Belgian public broadcaster VRT reported practical effects on government sites, parliamentary work, remote access and a vaccination-reservation service. Those examples demonstrate public-service dependency, but they do not prove that every connected institution suffered the same failure or duration. [8]
Belnet operates a national research and public-service network with IP and optical infrastructure, points of presence, backbone connections and optional redundant access. Its own mission statement calls the network a crucial building block for federal digital services. [9][10][11]
Public sources do not establish a named attacker, political motive, exact traffic volume, protocol mix, botnet size, saturated link, exploited vulnerability or complete customer-by-customer timeline. Accountability analysis must preserve those unknowns.
Later Belnet records provide useful evidence of change. The operator explicitly connected a point-to-point addressing control to resilience after the 2021 attack, and a 2022 monitoring article said an external cloud scrubbing centre was implemented in May 2021 when attack traffic threatened network uplinks. [3][6]
Belnet's current Advanced DDoS Security pages describe router filtering, an internal scrubbing centre and an external cloud layer. They are evidence of later or current controls, not proof that the full architecture existed before the incident. [4][5]
IETF documents on denial of service, ingress filtering and DDoS Open Threat Signaling provide a vocabulary for mitigation readiness, upstream coordination and telemetry. They do not prove Belnet used a particular protocol or configuration in 2021. [12][13][14][15][16][17][18][19]
Accountability follows practical control. Belnet controlled backbone operations, mitigation, rerouting, crisis escalation and network-wide evidence. Connected institutions controlled local failover, secondary access and application continuity. Upstream and last-mile providers controlled contracted paths and capacity. Government authorities controlled continuity requirements and oversight.
A credible closeout should show where legitimate traffic became constrained, when mitigation and alternate paths took effect, what collateral filtering occurred, how customer recovery was measured, and whether later controls were tested against the actual failure class.

The outage turned shared connectivity into shared public-service risk

A distributed denial-of-service attack is easy to describe badly. The simplified version says that attackers sent too much traffic, a network became unavailable, engineers filtered the traffic, and service returned. That sequence can be technically true while hiding the accountability questions that matter most.

Belnet was not merely hosting one public website. It provided connectivity used by government departments, universities, research organisations and other public institutions. Belnet's mission statement describes a national research network and a crucial component of federal digital services. Its service pages describe a hybrid IP and optical network that connects institutions to Belgian and international internet and research networks. [9][11]

That role changed the meaning of the May 2021 incident.

An attack that constrained shared network capacity could affect institutions with unrelated applications, administrators and missions. A parliamentary commission did not need to share an application database with a university for both to suffer. A vaccination-booking service did not need to run on the same server as a tax website. Shared reachability was enough.

The federal parliamentary record says about 200 connected organisations experienced varying levels of internet-access disruption. [7] VRT described government sites that were slow or unavailable, cancelled or interrupted parliamentary work, remote-access problems and a period when a vaccination-reservation service could not operate normally. [8]

These effects should be reported carefully. The evidence does not show that every organisation lost all connectivity for the same period. It does not show that every Belgian government service failed. It does not establish that the .be domain itself became unavailable. The institutions had different access designs, application dependencies, local networks and fallback options.

The common fact is narrower and more important: one network incident propagated into several sectors because those sectors relied on a shared connectivity control surface.

That makes concentration measurable.

How many critical services depended on one Belnet access path? How many institutions had a secondary path through a different point of presence, fibre route or provider? Which services could fail over without changing DNS, authentication, firewall or application state? Which institutions knew that a shared provider incident could interrupt both public access and staff remote access? Which continuity plans had been tested with the primary research and public-service network unavailable?

The answers determine whether shared infrastructure produces efficient resilience or hidden common-mode risk.

Centralised network protection can be valuable. A national research network can aggregate expertise, capacity, monitoring and procurement. It can coordinate with upstream providers more effectively than every institution acting alone. It can provide redundant optical and IP infrastructure and make specialist mitigation available to organisations that could not operate it independently.

The same concentration raises the stakes of under-provisioned mitigation, slow escalation or incomplete customer failover. If hundreds of institutions depend on shared uplinks and mitigation systems, the operator's technical decisions become part of public-service continuity.

That is the accountability boundary exposed by the outage. The attackers controlled malicious traffic. Belnet and its partners controlled how shared infrastructure detected, absorbed, redirected and documented that traffic. Connected institutions controlled how much of their own service continuity depended on the common path. Public authorities controlled the resilience requirements attached to services whose interruption had social consequences.

Responsibility therefore cannot be reduced to the identity of the attacker. It has to follow the distribution of practical control.

What the public record establishes, and what it does not

The most reliable analysis starts by separating three records: Belnet's operational status updates, its later annual reporting, and external institutional or journalistic accounts.

Belnet's annual report places the incident on 3 and 4 May 2021 and calls it a major volumetric DDoS attack. It says the event fundamentally changed the organisation's approach to cyber defence. [2]

The live status record begins on 4 May. It says some customers were experiencing connectivity problems because of a DDoS attack. Later updates describe successive waves, continued mitigation work, alternate paths for traffic, implemented mitigation rules, stabilisation, residual incidents and work on longer-term protection and escalation paths. [1]

The federal parliamentary transcript gives an official government account. The prime minister described a large-scale DDoS attack on 4 May, said the network could not process the demand, and said connected institutions were affected to different degrees. The transcript records activation of Belnet's crisis procedure and contact with the Centre for Cybersecurity Belgium. It says the situation was under control by the evening. [7]

VRT provides independent contemporaneous impact reporting. It identified government websites, parliamentary proceedings, remote-work or student access and vaccination reservations among the affected functions. [8]

Together, these sources support several conclusions.

First, the event was a denial-of-service incident against shared network infrastructure, not merely a compromise of one application.

Second, impact varied. The official account explicitly describes different degrees of disruption.

Third, response was iterative. Belnet was not applying one static rule to one unchanging flood. Its status updates describe waves, alternate paths, mitigation rules, stabilisation and residual issues.

Fourth, the operational endpoint was not one universal timestamp. A statement that the situation was under control by the evening does not prove that every customer, site, application and remote-access path was fully restored then.

The public record leaves important gaps.

It does not provide a verified peak in bits per second or packets per second. It does not provide a protocol distribution. It does not say whether source spoofing was material. It does not identify the exact ingress paths, saturated links, constrained routers or mitigation capacity. It does not publish the complete timing of detection, escalation, rerouting, filtering and customer restoration.

It also does not establish a named attacker or motive. A government account described botnet-driven traffic at a general level, but the frozen record does not identify the botnet controller, device population or attribution chain. Political speculation would be irresponsible.

The absence of those facts is not an excuse to fill the gaps. It is a reason to distinguish findings from evidence requests.

For example, ingress filtering is an important network control, but the source set does not establish that spoofed source addresses caused the Belnet flood. It would be wrong to claim that universal adoption of one filtering practice would necessarily have prevented this event.

Likewise, an external scrubbing centre can absorb a large flood, but the public sources do not disclose the exact capacity available before the incident or the contractual conditions for invoking it. Later Belnet material says an external cloud service was introduced in May 2021. [6] That is evidence of change, not a complete reconstruction of the pre-incident architecture.

A rigorous article should make the unknowns visible because they define the remaining accountability questions:

What traffic characteristic created the constraint?
Which shared links or devices became bottlenecks?
Which mitigations were automatic, and which required human approval?
How long did each escalation take?
Which customers were protected individually?
Which institutions had independent paths?
What legitimate traffic was filtered or delayed?
How did Belnet and customers decide that service was restored?

Those questions are more useful than an unsupported theory about the attacker.

Belnet was a network control surface, not a generic cloud dependency

The target of this article is network infrastructure. That distinction matters because the incident could otherwise be flattened into a generic story about cybersecurity or government IT.

Belnet's public service description says its network combines IP and optical connections and provides access to commercial internet and research networks. [9] Its technical FAQ describes direct connections at Belnet points of presence, third-party last-mile options, backbone interfaces and the possibility of a second connection through another point of presence and a separate fibre path for critical needs. [10]

These details identify several different control domains.

Belnet controls the backbone and the service delivered at its points of presence. It can observe traffic entering its network, configure routers, establish mitigation rules, redirect traffic and coordinate network-wide response.

A last-mile provider controls the circuit between an institution and Belnet when that institution is not directly present at a Belnet point of presence. A failure or capacity limit there is not automatically under Belnet's sole control.

The connected institution controls its local network, firewall, DNS dependencies, application exposure and use of secondary connectivity. Belnet can offer redundant access, but an institution still has to procure, configure and test it.

Upstream transit and mitigation providers control capacity and filtering outside Belnet's administrative domain. Their effectiveness depends on pre-arranged authority, routing and operational contacts.

Those boundaries matter during DDoS response because the place where traffic must be filtered is often outside the application owner's direct control.

If malicious traffic saturates an access link before it reaches a local firewall, filtering at the institution is too late. If a flood threatens a provider's uplink, the provider may need to redirect traffic to a scrubbing service or ask an upstream network for help. If mitigation requires routing changes or customer prefixes, the entities need authority and tested procedures before congestion makes communication difficult.

Belnet's current Advanced DDoS Security pages describe precisely this kind of layered network response. They refer to router-based filtering, an internal scrubbing centre and an external cloud scrubbing centre. The technical FAQ says traffic is normally kept out of the scrubbing path and redirected when detection indicates an attack. It also describes manual rerouting to the external service when the network risks saturation. [4][5]

The current design cannot be projected backward without evidence. It does, however, clarify the practical decisions an operator must govern:

Which anomaly triggers router filtering?
Which destination is redirected?
What legitimate traffic remains reachable?
When is internal capacity limited public evidence?
Who authorises external redirection?
Which routes and communities are used?
How is the action reversed?
What evidence demonstrates that the mitigation worked?

These are network operations questions. They concern traffic paths, control authority, shared capacity and observable service. The incident belongs in network-infrastructure accountability because public harm followed the behaviour of those controls.

Volumetric attacks are capacity contests with incomplete solutions

RFC 4732 describes an uncomfortable architectural fact: almost any internet service can be denied if an attacker can assemble enough traffic or exploit enough state. [12] This does not make resilience impossible. It means that claims of prevention must be specific.

A volumetric attack attempts to consume a constrained resource. The resource might be an internet link, router forwarding capacity, a firewall state table, a load balancer, a DNS service or an application. The right mitigation depends on where the constraint occurs and what traffic can be distinguished.

If the bottleneck is an uplink, adding a local firewall rule may not restore service because attack packets have already consumed the link. If the bottleneck is stateful processing, moving filtering into stateless router policy may help. If traffic is distributed across many real sources and resembles legitimate demand, simple source blocking can be ineffective or harmful.

The public Belnet record calls the incident volumetric and says attack waves threatened connectivity. [1][2] It does not disclose the exact resource that failed first.

That uncertainty changes how controls should be evaluated.

Capacity is one control. An operator can provision headroom and diverse upstream paths. Capacity alone cannot guarantee survival against any conceivable flood, but it can raise the threshold and create time for mitigation.

Detection is another control. Flow telemetry, router counters and service probes can identify unusual traffic, affected destinations and saturation. Detection must continue working when the network is under stress.

Filtering is another. Access-control lists, flow specifications, null routes, rate limits and scrubbing systems can remove malicious traffic. Each can also block legitimate traffic if scope or matching is wrong.

Redirection is another. Traffic can be sent through internal or external scrubbing capacity. That requires routing authority, prefix acceptance, return-path design and enough clean capacity.

Customer segmentation is another. If a flood against one destination can threaten shared uplinks, the provider must decide when and how to protect the rest of the network, even if the targeted customer has not purchased an individual mitigation service.

Communication is another. Operations teams need a path to customers, upstreams and authorities while production connectivity is impaired. Belnet's status page and crisis procedure were part of this control plane. [1][7]

None of these is complete by itself. RFC 4948 discusses filtering, access lists, null routing, provisioning and the incentives that can slow deployment of controls whose benefits are distributed across the internet. [14] The accountability problem is therefore not whether an operator owns a product called DDoS protection. It is whether the technical, contractual and human controls form a tested sequence.

A useful resilience statement would identify:

the resources monitored for exhaustion;
the thresholds that trigger action;
the mitigation authority;
the internal and external capacity available;
the routes used for redirection;
the treatment of legitimate traffic;
the fallback if the primary mitigation path fails;
the evidence retained for review.

Without that sequence, "we have DDoS protection" is a product description, not a resilience result.

Concentration can amplify harm even when applications are separate

The institutions affected through Belnet were not one organisation. They included entities with different governance, technology and public duties. [7][11]

Shared connectivity connected those differences.

A government department might host public websites in one environment and rely on Belnet for staff access. A university might use the network for research traffic, identity federation, remote learning and external services. A hospital or research centre might have specialised data flows. A parliamentary body might depend on video, documents, authentication and public communications.

The applications do not need to share code for a network outage to correlate their failures.

This is why dependency registers should include external network controls, not only software suppliers.

A conventional service map may list an application, database, identity provider and cloud host. It can still omit the path by which users and staff reach those components. If primary and backup applications depend on the same access circuit, DNS resolver, provider prefix or upstream route, apparent redundancy may disappear under a provider incident.

Belnet's technical FAQ says institutions with critical connectivity needs can obtain a second connection through another point of presence and, where available, a separate fibre path. [10] That is an important option. It is not proof that every affected institution had such diversity or that every secondary path was independent of the same DDoS control plane.

True path diversity requires more than two cables.

The paths should avoid common ducts, access devices and power where feasible. They should terminate at distinct points of presence. Routing policy should allow traffic to move when the primary path is impaired. Firewalls and identity services should accept the alternate path. Public DNS and remote-access configuration should not require manual changes that cannot be made during the outage.

There is also a procurement issue.

Redundant connectivity costs money. Public institutions may optimise for ordinary availability while assuming the national network operator will absorb extraordinary traffic. The operator may offer basic connectivity and optional individual mitigation, while retaining responsibility for the stability of the shared backbone. Customers may not know whether their service is protected proactively or only receives reactive assistance.

Belnet's 2022 monitoring article makes this distinction explicit. It says some organisations bought a mitigation service with monitoring, while others could receive reactive help. It also says external cloud scrubbing could be invoked when an attack against a customer threatened the network's uplinks. [6]

That creates at least three accountability layers:

individual protection for the targeted customer;
protection of shared provider infrastructure;
continuity arrangements for each institution's critical services.

The layers should not be confused. A provider can protect its backbone by blackholing a target, while the target remains unavailable. A customer can buy scrubbing, while another dependency fails. An institution can maintain a second circuit, while both circuits rely on the same upstream mitigation decision.

The public-interest question is whether critical services know which outcome they are buying.

The response sequence reveals where authority mattered

Belnet's live status updates are useful because they show response as a sequence rather than a single declaration. [1]

The early message identified connectivity problems and active mitigation. Later updates said the attack continued in waves. Engineers worked to stabilise the situation and build alternate paths. They implemented mitigation rules and monitored the network. The situation became more stable, but residual incidents remained. Belnet then described longer-term protection mechanisms and escalation paths.

Each step required a different kind of authority.

Monitoring required access to network telemetry and customer reports.

Alternate paths required control over routing and available connectivity.

Mitigation rules required authority to change forwarding or filtering behaviour, along with judgment about collateral impact.

External help required established contacts and permission to exchange routing or mitigation information.

Customer remediation required coordination with institutions whose traffic and applications Belnet did not fully control.

Longer-term change required procurement, architecture and governance decisions beyond the incident team.

The federal account adds crisis coordination with the Centre for Cybersecurity Belgium. [7] That step matters because a network operator cannot independently determine the public-service consequence of every customer outage. Government coordination can prioritise critical dependencies, consolidate impact and support communication.

Accountability should examine whether these authorities were clear before the attack.

Who could declare a network-wide incident? Who could redirect traffic? Who could invoke external capacity? Could one engineer make a high-impact routing change, or was dual approval required? How was speed balanced against change risk? Were emergency contacts reachable out of band? Did customers know where to report residual failures after aggregate metrics improved?

These questions do not imply that the response was slow or improper. Public evidence is not sufficient for that conclusion. They define the operational controls that should be reviewable after an event of this scale.

The phrase "under control" also needs a measurable definition.

It could mean attack traffic was no longer increasing. It could mean shared uplinks were no longer saturated. It could mean most customers had connectivity. It could mean critical institutions were reachable. It could mean no new attack wave was producing material impact.

Those are different conditions.

An accountable status process should connect the public phrase to internal evidence. It should also separate network stabilisation from full customer restoration. Belnet's status record continued to discuss residual issues and longer-term work after reporting stability. [1] That sequence supports a more precise model:

containment;
network stabilisation;
customer recovery;
residual incident closure;
remediation;
verification.

Combining them into one timestamp hides operational truth.

Later controls are evidence of learning, not proof of the earlier design

Post-incident evidence is often weaker than the incident record. Organisations announce investments without explaining which failure they address. Belnet's later material is more specific than that, although it still requires careful dating.

The point-to-point addressing FAQ says Belnet wanted to strengthen network resilience following the major 2021 DDoS attack. It explains that point-to-point addresses should be used only for interconnection and routing, with customer configurations brought into compliance where necessary. [3]

This is a concrete control boundary. Address discipline can simplify protection because infrastructure addresses are not treated as general customer addresses. It can reduce ambiguity in routing and filtering. It can make it easier to distinguish interconnection functions from destinations that should receive ordinary traffic.

The FAQ does not prove that address misuse caused the 2021 incident. The correct claim is that Belnet linked the change to improving protection after the incident.

Belnet's 2022 monitoring article says an external cloud scrubbing centre was implemented in May 2021. It describes using that layer when a powerful attack against a customer threatens to saturate the rest of the network. [6]

This is also specific. It identifies the protected resource as network uplinks and distinguishes individual customer protection from network-wide protection.

Belnet's current Advanced DDoS Security pages describe a three-tier structure using automated filtering in routers, an internal scrubbing centre and an external cloud scrubbing centre. [4][5]

The technical FAQ says detectors analyse traffic entering the network and can redirect it to internal scrubbing. It says external rerouting is manual in order to preserve control when sending traffic to an outside party. It also describes redundant internal scrubbing equipment. [5]

These details show that resilience involves trade-offs.

Automation can reduce response time but can amplify a bad detection or route change.

Manual approval can preserve human control but can delay mitigation while a link is saturated.

Out-of-path scrubbing avoids permanent extra hops and may reduce ordinary-service risk, but it relies on detection and redirection working under attack.

External scrubbing adds capacity and geographic distribution, but it introduces another provider, routing relationship and data path.

Internal redundancy protects against equipment failure, but it does not automatically protect an external uplink from a flood larger than its capacity.

The accountability test is whether those trade-offs were tested against the real failure class.

A procurement receipt is not a test. A product dashboard is not a test. A successful low-volume demonstration is not a test.

Evidence should show detection at realistic volume, authority to reroute, route propagation, clean return paths, preservation of legitimate traffic, customer-specific policy, telemetry during saturation, fallback when a mitigation provider is unavailable and safe withdrawal after the attack.

Belnet's public pages describe mechanisms. A complete accountability record would connect those mechanisms to measured exercises and incident results.

Cross-domain mitigation must be arranged before the link is full

The DDoS Open Threat Signaling documents provide a useful comparison framework because they address a structural problem: the network suffering an attack may need help from another administrative domain.

RFC 8612 states requirements for DDoS mitigation signaling. RFC 8811 describes an architecture in which a client can ask a mitigation provider for help and receive status. RFC 8782 defines a signal channel designed for hostile conditions. RFC 8903 describes use cases. RFC 9244 addresses telemetry, including shared connectivity pipes. [15][16][17][18][19]

These standards should not be represented as evidence that Belnet deployed DOTS. Their value is analytical.

They show why an operator should not invent the service relationship during an incident.

The parties need identities, authentication, authorisation, scope and contact paths. The mitigation provider needs to know which prefixes or services the requesting party can control. Routing changes need to be accepted. Telemetry needs a common meaning. The signal path itself needs to survive degraded conditions.

Belnet's status record mentioned escalation paths, and its later materials describe external cloud scrubbing. [1][6] The standards help turn those concepts into review questions.

Was the external relationship active before the flood? Were customer prefixes and routing policies pre-authorised? Could Belnet invoke network-wide protection without waiting for each customer? Could individual customers request protection? Which conditions triggered external escalation? Did the signal and management path depend on the congested production network? What status came back from the mitigator? What telemetry proved that clean traffic returned?

Shared-pipe telemetry is particularly important.

If several customers share a physical or logical capacity constraint, an attack on one can degrade others. The provider needs to identify the attacked destination, the shared resource, the clean traffic and the point at which individual mitigation becomes network protection.

That decision has consequences.

Blackholing one destination can restore the shared network while denying all service to the target. Scrubbing can preserve service but may add latency or false positives. Rate limiting can distribute pain across legitimate users. Rerouting can change path length and capacity. Waiting can allow the flood to affect unrelated customers.

There is no universal threshold that resolves every case. The threshold is a governance decision informed by network design, customer criticality, capacity and contractual authority.

Accountability means the operator can explain that decision with evidence after the fact.

Ingress filtering matters, but it is not a universal event explanation

RFC 2827 describes network ingress filtering intended to reduce attacks that use forged source addresses. RFC 4948 discusses the value and deployment difficulty of that control. [13][14]

These standards belong in a DDoS accountability article because attack traffic can exploit weak source validation across many networks. Operators that allow spoofed packets externalise costs to victims and mitigation providers. Broad adoption can reduce some attack classes.

The Belnet evidence does not say whether spoofing was central to the May 2021 flood.

That boundary should remain explicit.

If the attack used compromised devices with valid source addresses, ingress filtering at those networks might not have removed it. If it used reflection and amplification with forged victim addresses, source validation could have reduced traffic at origin. If it combined several vectors, different controls would apply.

The public source set does not choose among those possibilities.

The correct accountability analysis separates control policy from causal claim.

Networks should implement appropriate source validation because it reduces a known class of abuse and protects the internet as a whole. That is a general duty supported by the standards.

Belnet and its partners should also retain event telemetry sufficient to determine whether spoofing, reflection, direct bot traffic or application requests drove the incident. That is an event-specific evidence duty.

The distinction matters because generic recommendations can create false closure.

If an operator responds to a direct botnet flood by announcing ingress filtering, it may not have addressed the saturated resource. If it responds to a reflection attack only by buying more capacity, it may miss opportunities for upstream filtering and source validation. If it deploys aggressive filters without measuring legitimate traffic, it may create a new availability problem.

Control selection should follow evidence.

This is also where economic accountability appears. RFC 4948 notes that some filtering benefits other networks more visibly than the network paying to deploy it. [14] Public networks and regulators can help correct that incentive problem through procurement requirements, peering expectations, transparency and shared services.

Belnet's position as a public network operator makes the incentive question especially relevant. It can aggregate protection for institutions that would struggle to buy it individually. It can also require customers and connected providers to maintain address and routing discipline. The point-to-point addressing change is an example of the operator using service rules to improve a shared control surface. [3]

The lesson is not that one BCP would have stopped the outage. It is that shared network resilience depends on controls deployed across organisational boundaries, and evidence is needed to select the right ones.

Connected institutions had continuity duties too

Belnet controlled the shared network. That does not mean every continuity duty belonged to Belnet.

Connected institutions controlled what happened after connectivity degraded.

They could identify critical applications, maintain alternate access, separate public and administrative paths, preserve out-of-band communications, test remote-work fallback and decide which services required independent providers.

The practical options varied. A small research organisation could not build a national scrubbing network. A ministry could not reconfigure Belnet's backbone. A university could not unilaterally invoke an upstream mitigation provider for Belnet-owned routes.

The responsibility should match that reality.

Institutions should not be blamed for controls they could not operate. They should be accountable for choices within their authority.

For a vaccination-reservation service, that might include a secondary public access path, tested DNS failover, cached information pages, call-centre fallback and a clear status channel.

For parliamentary work, it might include an alternative conferencing or document path and a way to continue essential proceedings without the primary network.

For universities, it might include independent emergency communications, local access to critical systems and documented limits on remote learning or research services.

For government departments, it might include a dependency register showing which functions rely on Belnet for public access, staff access, identity, inter-agency exchange and incident communication.

These controls require coordination with the network provider.

A second circuit is useful only if the institution knows whether it shares a point of presence, fibre route, upstream or mitigation dependency with the first. DNS failover is useful only if authoritative DNS and management access remain available. A backup remote-access service is useful only if identity and endpoints can reach it.

Belnet's technical FAQ describes options for a second point of presence and separate fibre path. [10] Institutions should be able to translate those options into service-specific risk decisions.

Public procurement can support this by asking:

Which physical and administrative failure domains are independent?
Is DDoS protection proactive or reactive?
What capacity is reserved?
Who can trigger mitigation?
What restoration objectives apply to the shared network and to individual customers?
What telemetry and post-incident evidence will be provided?
How are emergency changes authorised and reviewed?

These questions prevent a contract from reducing resilience to an uptime percentage that says little about correlated attacks.

Public status communication is part of the recovery control plane

During a network incident, communication is not separate from operations. It influences customer decisions, escalation and evidence.

Belnet's status page gave repeated updates as the attack changed. [1] The messages identified connectivity problems, ongoing waves, mitigation work, alternate paths, stabilisation and residual issues.

That cadence matters for institutions deciding whether to invoke local continuity plans.

A vague "investigating" message can leave customers waiting while their own fallback window closes. An overly confident "resolved" message can cause institutions to withdraw temporary controls before all paths are stable. A detailed technical message can create security risk or confuse non-specialists.

The right public record should answer operational questions without exposing sensitive configuration:

Is the problem in the shared network?
Which broad service class is affected?
Is attack traffic continuing?
Is mitigation active?
Are customers recovering at different rates?
Should institutions keep local fallback active?
Where should residual incidents be reported?
When will the next update arrive?

The status record also becomes evidence.

It can be compared with router telemetry, mitigation-provider logs, customer tickets and crisis decisions. Differences can reveal detection delay, incomplete impact assessment or recovery gaps.

This is why timestamps should be preserved in structured form. A later narrative can summarise the event, but responders and overseers need the original sequence.

The federal parliamentary record demonstrates another communication layer: public oversight. [7] Officials needed to explain scale, institutional impact, coordination and preventive action. A useful oversight process should request evidence without forcing disclosure of exploitable detail.

Questions should focus on control and proof:

What shared resource was constrained?
What mitigation capacity existed?
What changed during response?
Which institutions lacked independent paths?
What later control addressed which observed failure?
How was the repair tested?

Asking only who attacked can leave the infrastructure lesson unresolved.

A recovery claim should be service-specific and independently testable

Network operators often report aggregate stability before every customer has recovered. That is not necessarily misleading. A backbone can be stable while local sessions, routes or applications remain impaired.

The problem arises when the stages are not distinguished.

Belnet's status sequence moved from active waves and alternate paths to mitigation rules, stabilisation, residual incidents and longer-term work. [1] That supports a multi-stage recovery model.

Containment

Attack growth is limited, dangerous traffic is filtered or redirected, and operators regain control of shared resources.

Network stabilisation

Backbone and uplink utilisation remain within safe bounds. Routing and mitigation no longer oscillate. Core monitoring is reliable.

Customer connectivity recovery

Connected institutions can exchange traffic through expected paths. Exceptions are identified rather than hidden in averages.

Service recovery

Public websites, remote access, identity, video, research and other functions are tested from outside the institution.

Residual incident closure

Customer-specific route, filter, state or last-mile problems are resolved.

Remediation verification

The original failure class is replayed or simulated against the changed controls, with rollback and evidence.

Each stage should have exit criteria.

For containment, the criteria might include reduced packet loss, available clean capacity and stable router resources.

For network stabilisation, they might include sustained utilisation, route convergence, mitigation consistency and healthy telemetry.

For customer recovery, they might include representative probes across points of presence and customer classes.

For service recovery, institutions need application-level checks. An interface can be reachable while authentication, transactions or remote work remain broken.

Independent testing matters because a damaged or overloaded control plane may report itself healthy.

External probes, customer measurements and separate management paths can challenge the operator's internal view. They do not replace operator telemetry, but they reduce the risk of declaring success from the same systems being repaired.

CISA's later DDoS guidance emphasises planning, provider coordination and layered response. [20] It is useful as a comparison, not as evidence about Belnet's 2021 procedure.

The general principle is durable: restoration should be demonstrated from the perspective of legitimate users and shared infrastructure, not only from one dashboard.

The evidence package an accountable public network should retain

A post-incident report does not need to publish sensitive router configurations. It should still preserve enough evidence for customers, authorities and independent reviewers to understand what happened.

The package should begin with current-byte integrity.

Telemetry extracts, configuration snapshots, mitigation rules, routing changes and reports should have timestamps, ownership and cryptographic hashes. If evidence is revised, the revision should identify the superseded version and reason.

It should include a dependency map.

The map should identify backbone links, points of presence, upstreams, mitigation providers, management paths, status channels and customer classes. It should show shared capacities without exposing unnecessary device detail.

It should include an event timeline.

The timeline should distinguish first harmful traffic, detection, customer impact, incident declaration, crisis escalation, alternate paths, filtering, internal scrubbing, external scrubbing, stabilisation, customer recovery and closure.

It should include resource evidence.

Which links, forwarding resources or services approached limits? What was the clean traffic baseline? What attack classes were observed? What telemetry remained reliable under load?

It should include action evidence.

Which rules changed? Who approved them? Which routes moved? What collateral effects occurred? How were changes rolled back or retained?

It should include customer evidence.

How many institutions were materially affected? Which service classes failed? Which had independent access? How were residual incidents collected and closed?

It should include communication evidence.

When were status updates issued? What information was available at each time? Were critical institutions contacted out of band?

It should include remediation evidence.

Which later controls address which observed failure? How were point-to-point address changes verified? When was external scrubbing made available? What tests showed the current layered protection could protect both a target and the shared network?

It should include uncertainty.

Unknown attribution, missing packet detail, incomplete customer data and assumptions should be listed rather than silently resolved.

This package changes accountability from rhetoric into a reviewable process.

It also protects the operator. Evidence can show that teams acted quickly, that an attack exceeded reasonable design assumptions, that a customer lacked a purchased control, or that an upstream action constrained response. Accountability is not a presumption of operator fault. It is a method for assigning responsibility according to evidence and control.

Oversight should connect remediation to the observed failure

The federal parliamentary discussion asked about prevention, technical evolution, investment and evaluation. [7] Those are appropriate questions, but they can produce generic answers unless tied to the failure mechanism.

"We invested in cybersecurity" is not enough.

An oversight record should connect each expenditure to a control:

additional internal scrubbing increases capacity at a defined network point;
external scrubbing protects uplinks beyond local capacity;
router detection reduces time to identify a destination under attack;
point-to-point address discipline simplifies filtering and routing;
separate management paths preserve response authority;
secondary points of presence reduce access-path concentration;
exercises validate invocation and restoration.

The point-to-point FAQ and later DDoS service descriptions make this mapping possible. [3][4][5][6]

Oversight should also ask about service coverage.

If only some customers buy proactive mitigation, what protection does the shared network provide when an unprotected customer is targeted? When can Belnet act without customer approval to protect other institutions? What happens to the targeted service during that action? Are critical public services subject to stronger baseline requirements?

These are policy decisions as much as technical ones.

A public network can choose to socialise some mitigation cost because an individual target can create spillover for hundreds of institutions. It can offer enhanced protection for customers with exceptional risk. It can require configuration discipline as a condition of service. It can publish standard evidence after major incidents.

The design should be explicit.

Otherwise, responsibility becomes visible only during an outage, when the provider, customers and authorities discover different assumptions about who would absorb the flood.

The real accountability test is readiness before the next wave

Belnet's 2021 incident was dynamic. The status page described successive waves and changing mitigation. [1]

That is a useful model for resilience testing.

A test should not send one predictable stream at one protected service and stop when the dashboard turns green.

It should vary destinations, protocols and volumes within safe controlled limits. It should test a protected customer and an unprotected customer whose traffic threatens shared capacity. It should test internal and external scrubbing. It should test route propagation, return paths and withdrawal. It should test false positives and legitimate high-volume events.

It should also test people.

Can operators invoke external mitigation at night? Are contacts current? Can they authenticate when the main network is impaired? Do customers understand status messages? Can government coordinators identify critical services? Can engineers change filters with peer review while time matters?

It should test evidence.

Do telemetry and timestamps survive? Can the operator reconstruct which rule affected which traffic? Can customer probes confirm restoration? Can an independent reviewer reproduce the conclusion?

It should test failure of the mitigation system itself.

What happens if the internal scrubber is unavailable? What if the cloud provider has a control-plane incident? What if route redirection is delayed? What if a filter blocks critical legitimate traffic? What if the status platform depends on the affected path?

This is where current architecture descriptions become accountable controls. [4][5]

The value of three layers is not the number three. It is that each layer has a defined role, failure boundary, trigger and fallback. If all layers depend on the same detector, management identity or routing path, apparent diversity can still hide common mode.

The test should therefore ask not only whether the system absorbs traffic, but whether the organisation retains control and evidence as conditions change.

Conclusion: shared networks create a shared duty to prove resilience

The May 2021 Belnet incident did not make public-service continuity a network issue. It revealed that it already was one.

Government, education, research and other institutions depended on a shared network. A large volumetric attack produced connectivity problems across those organisations. Belnet responded with alternate paths, mitigation rules, crisis coordination and longer-term work. Later records connect the incident period to external scrubbing, addressing discipline and a more layered DDoS protection architecture. [1][2][3][4][5][6][7]

The evidence does not support a named attacker, exact traffic volume, complete vector analysis or a finding that one missing control caused the outage.

It supports a clear accountability framework.

Belnet had practical control over backbone operations, network-wide mitigation, rerouting, crisis escalation and the evidence needed to explain recovery.

Connected institutions had practical control over secondary access, application continuity, critical dependency maps and local fallback.

Upstream, last-mile and mitigation providers had practical control over contracted paths, capacity and cross-domain actions.

Public authorities had practical control over continuity requirements, procurement, coordination and oversight.

The attacker's responsibility for malicious traffic does not remove those duties. Neither does infrastructure accountability imply that every outage proves negligence.

The proper test is whether each party can show that its control was proportionate to the harm it could prevent or amplify.

For a shared public network, that proof should cover capacity, detection, alternate paths, scrubbing, escalation authority, legitimate-traffic preservation, customer recovery and tested remediation.

Service returning is an operational achievement. Showing why the network is more resilient, which risks remain and how that conclusion was verified is the accountability result.

Belnet's 2021 DDoS Outage Made Shared Public-Network Resilience an Accountability Test