Bandwidth.com's 2021 DDoS Attack Made VoIP and 911 Continuity

Summary

Confirmed boundary: Beginning on 25 September 2021, Bandwidth's communications network was subjected to a distributed denial-of-service attack. The company's Form 8-K said the attack initially caused intermittent communications-service disruptions in certain markets and for certain customers. Bandwidth later said its network had been largely stable and operating at normal service levels since the evening of 29 September, although intermittent disruptions continued. [1][2] Those are the most reliable boundaries for the public timeline. They do not support describing the event as one uninterrupted nationwide outage.
Infrastructure significance: Bandwidth provided programmable voice, messaging, telephone-number and emergency-service capabilities used by downstream communications providers and software platforms. A failure in that shared carrier layer could therefore become visible under brands that an end user did not associate with Bandwidth. Contemporary reporting and downstream status records described impaired calling, messaging, portals and possible 911-routing effects. [11][12][14][15][16] Those observations show dependency propagation. They do not establish that every failed call, provider outage or public-safety problem followed the same path.
Technical boundary: The public record establishes a DDoS attack, but it does not disclose the complete vectors, packet rates, botnet composition, scrubbing topology, route changes, private peering arrangements or every mitigation command. CISA material explains how direct floods and amplification attacks can exhaust network or service capacity, and how flow visibility, filtering, rate limiting and upstream coordination can be used in response. [9][10] That material supplies technical context, not proof that Bandwidth experienced any specific vector.
Responsibility map: Bandwidth controlled the architecture and operation of its communications network, including capacity planning, detection, mitigation relationships, routing choices, customer communications and restoration. Upstream carriers and mitigation providers controlled filtering and clean capacity on their systems. Downstream VoIP providers controlled dependency visibility, carrier diversity, failover, customer notice and alternative emergency-calling procedures. Regulators and public-safety organizations controlled parts of the outage-reporting and 911-notification framework. Responsibility follows those controls and the evidence each actor can produce.
Reality layer: This is a network-infrastructure article because the argument collapses if the shared VoIP layer, DDoS filtering, inter-provider routing, number and emergency-service records, failover paths and restoration telemetry are removed. Contracts, assigned numbers, status notices and routing configurations are accountability ledgers. They identify obligations and intended paths. They do not complete a call by declaration. Running capacity, reachable routes, filtering behavior, tested failover and verified restoration determine continuity.

The dated record is stronger than the early narrative

The most dependable reconstruction starts with Bandwidth's securities disclosures. Its 5 October 2021 Form 8-K said the attack began on 25 September and initially caused intermittent communications-service disruption affecting certain markets and customers. It said mitigation work with cybersecurity partners was proving successful and that the network had been largely stable and operating at normal service levels since the evening of 29 September, with some continued intermittent disruption. [2]

That wording establishes several facts while preventing several exaggerations.

First, the attack affected Bandwidth's communications network rather than merely a public website. Second, the service effect was intermittent and bounded to some markets and customers in the company's description. Third, stabilization did not mean that every downstream symptom ended at the same instant. Fourth, the record identifies a multi-day mitigation period without saying that every service was continuously unavailable for that entire period.

Bandwidth's first-party statement used similar language and emphasized the interconnected communications ecosystem. [1] The Form 10-Q later described the event and gave a fuller financial estimate. [3] The later earnings exhibit provided another retrospective boundary. [4][5] Together, those documents are more useful than an outage graph with no carrier context. They connect an operational event to dates, service effects, mitigation, customer experience and management's financial estimates.

Early reporting still matters, but for a different purpose. Independent reports captured what customers and downstream providers were seeing while the incident was unfolding. BleepingComputer and SiliconANGLE described effects involving voice, messaging, portals and emergency-related functions, while channel reporting examined the effect on providers that relied on Bandwidth. [11][12][16] These sources can corroborate that the incident propagated. They cannot replace the company's record for the exact attack start, nor can they prove the architecture behind every symptom.

The distinction is essential in a shared network. An end user may report that a software product, hosted phone provider or support line is down. The visible brand can be two or more contractual layers away from the carrier that supplies numbers, call termination or emergency-service functions. A contemporaneous report can accurately describe the user symptom while remaining unable to identify the exact failing component.

An accountable timeline therefore needs separate tracks:

the attack and mitigation chronology reported by Bandwidth;
Bandwidth's own service-state observations;
downstream provider notices and customer-visible symptoms;
emergency-service notifications, if any;
external tests of call completion, messaging and portal access;
the point at which each dependent provider verified restoration.

Collapsing those tracks into one start and one end time would create false precision. It would also obscure which operator had evidence at each stage.

A shared VoIP carrier is hidden infrastructure

Bandwidth was not simply a retail telephone company in this event. Its communications platform supplied network and application capabilities to other providers. That business model can give downstream firms broad geographic reach, number access, voice and messaging features without requiring each one to build a complete carrier network. It also creates a dependency that may be invisible to the final caller.

The relevant infrastructure includes more than packet transport. A production voice service can depend on:

telephone-number assignment and routing records;
signaling and session-control systems;
media paths;
carrier interconnection;
number portability processes;
emergency-service address and routing data;
customer portals and APIs;
identity and authentication services;
monitoring and fraud controls;
upstream internet transit and DDoS mitigation;
operational communications between the carrier and its customers.

Not every listed component was publicly confirmed as impaired during the Bandwidth incident. The list defines the control surface that a continuity assessment must examine. A provider can keep one subsystem available while another blocks the completion of a call.

This layered arrangement explains correlated failure. Several downstream brands can appear independent commercially while sharing the same underlying carrier, portal or emergency-routing path. A disruption at the common layer can produce simultaneous incidents that look unrelated to users. The dependency is economically efficient during normal operation and operationally concentrated during failure.

Concentration is not automatically negligence. A specialized carrier can provide stronger operations, regulatory expertise and mitigation capacity than many small providers could build separately. The accountability test is whether the common dependency is measured, disclosed to the operators who must manage it, and paired with credible continuity options.

That test cannot be satisfied by a vendor list alone. A downstream provider may know that Bandwidth is a supplier without knowing:

which numbers or call paths depend on Bandwidth;
whether inbound and outbound traffic use the same carrier;
whether emergency calls have an alternate route;
whether a backup carrier shares an upstream mitigation dependency;
how long number or routing changes take;
which failover steps are automated and which require manual approval;
what customer data is needed to activate the alternate path;
whether the alternate path has been tested at realistic load.

These are running-system questions. A contract identifies a relationship. It does not prove that a backup call path can carry production traffic.

DDoS is a mechanism class, not a complete diagnosis

A distributed denial-of-service attack uses traffic from multiple sources to consume network, protocol or application capacity. CISA's description of direct network floods explains that large volumes can exhaust bandwidth or the resources needed to process requests. [9] CISA's guidance on amplification attacks describes how an attacker can exploit services that return a response larger than the initiating request, often with forged source addresses, to direct traffic toward a victim. [10]

Those mechanisms are relevant to carrier operations. Voice and messaging platforms have public internet surfaces, signaling systems, portals and APIs that can be stressed in different ways. A provider may face raw bandwidth exhaustion, state exhaustion, application-layer request pressure or several mechanisms at once.

The public Bandwidth record does not say which specific mechanism caused the 2021 service effects. It does not publish packet captures, protocol distributions, traffic rates or a topology diagram. It does not identify which links or systems saturated first. It does not establish whether all intermittent symptoms came from the same technical bottleneck.

That uncertainty should be retained rather than filled with a generic DDoS narrative. The mitigation for a volumetric transit flood differs from the mitigation for requests that appear valid but consume expensive application state. An upstream filter can drop traffic matching a clear network signature. It may be less effective when traffic resembles customer activity or when the protected service needs broad reachability.

An evidence-led post-incident account would answer:

What traffic change first triggered an alarm?
Which service-level indicator degraded first?
Which networks, ports, protocols and destinations received the traffic?
Which capacity limit was approached or exceeded?
What did mitigation providers classify and drop?
How much legitimate traffic was also rejected?
Which route, peering or filtering changes were made?
Which actions improved call completion rather than only reducing inbound traffic?
How did operators know that the attacker had stopped, shifted or lost effect?

These questions do not require disclosing filters in enough detail to help an attacker. They require enough aggregate evidence to distinguish detection, containment and recovery.

The difference matters because a network can look stable by one measure while a service remains unreliable. Traffic may fall after filtering, yet valid calls may still fail. A portal may recover while signaling remains intermittent. A carrier can announce that mitigation is working while downstream providers still need to verify their own call paths.

Attribution and extortion claims require a separate evidence lane

Contemporary reports placed Bandwidth's incident within a broader period of attacks against VoIP providers. Some reporting discussed extortion attempts and claims associated with other attacks. [11][13][17][18] The public securities disclosures establish that Bandwidth experienced a DDoS attack. They do not establish a named attacker or group.

That separation is not a minor editorial rule. Attribution and operational accountability answer different questions.

Attribution asks who initiated or directed the traffic. It may require intelligence about infrastructure, payment demands, communication channels, malware, botnets and behavior across multiple victims. Operational accountability asks whether the affected service was designed, monitored and restored within the controls available to its operators. The latter can be evaluated even when attribution remains unknown.

An unverified actor story can displace scrutiny. If the article centers a named group without evidence, the incident becomes a morality play about an external adversary. That can hide the more actionable questions:

Was mitigation capacity available at the required locations?
Were upstream providers prepared to change filters quickly?
Were voice and emergency-service paths isolated from less critical traffic?
Did downstream providers have functioning alternatives?
Were status messages tied to measurable service restoration?

None of these questions makes the attacker less responsible. They recognize that a public communications operator must plan for hostile traffic without knowing in advance who will send it.

The same discipline applies to ransom or extortion language. A report may accurately say that a demand was claimed or that an incident occurred during an extortion campaign. It does not prove that the claimant generated the traffic. An accountable article should identify the source of the claim, keep it separate from confirmed operational facts and avoid turning association into attribution.

The 911 boundary raises the evidence standard

The incident becomes more consequential when emergency calling is involved. Bandwidth's own legal material explains that VoIP and 911 availability depend on factors including electrical power, broadband connectivity, congestion and continued service operation. [6] That is a useful dependency disclosure. The attached record does not establish that the disclosure waived any duty, and the notice does not prove that a specific emergency call failed.

FCC rules make significant interconnected-VoIP outages and 911 effects a regulated reliability concern. The Commission has required reporting for qualifying interconnected-VoIP outages and has developed expectations for notifying 911 authorities about relevant outages, including information about cause, scope, restoration and follow-up. [7][8]

The precise application of a reporting rule depends on facts such as duration, user minutes, geographic scope and effect on 911 facilities. This article does not claim that every threshold was met in every downstream incident. The regulatory framework matters because it defines the kind of evidence that should exist when emergency communications are affected.

A later affected-customer analysis used call-volume data to examine disruption, while a contemporaneous downstream-provider incident record described possible 911-routing impacts alongside intermittent calling problems. [14][15] Together, they support a bounded conclusion: emergency-calling continuity was a credible operational concern during the event. They do not support a claim of a nationwide 911 shutdown, a particular dispatch failure, a fatality or a known number of failed emergency calls.

The evidentiary standard for a 911-related incident should include:

the numbers, services and locations potentially affected;
whether the effect involved call initiation, routing, location information, callback or notification;
the time at which the carrier identified the emergency-service risk;
the public-safety entities notified;
the alternate routes or caller instructions provided;
the test calls or telemetry used to verify recovery;
any gap between network stabilization and verified emergency-call continuity.

This is where operational records become crucial. Emergency-service address records, number assignments and routing configurations can show what should happen. They do not show that a call completed during congestion or mitigation. A completed test call, signaling trace, downstream confirmation or public-safety acknowledgment provides the reality layer.

Warnings to customers also need precision. Advising users to try another phone can be prudent, but it transfers action to people who may not know whether their alternate device uses the same underlying carrier. A useful notice should state which service is affected, whether 911 may be impaired, what alternative is genuinely independent and when the provider last tested it.

Financial disclosure sets a boundary, not a measure of social harm

Bandwidth's public filings give unusually concrete financial estimates. The Form 10-Q said the attack was expected to reduce 2021 CPaaS revenue by between $9 million and $12 million, including an approximately $0.7 million third-quarter effect. [3] Later earnings material described an approximately $10 million effect for 2021 and continuing customer-experience and revenue consequences. [4][5]

These figures matter because they connect network reliability to a material business record. They include management's estimate of lost transaction volume and possible customer credits. They should not be presented as an audited measure of every loss caused by the incident.

The company's estimate does not necessarily include:

downstream providers' lost revenue;
customer support and remediation work;
missed or delayed calls;
any emergency-service consequences;
customers who changed providers;
reputational harm;
mitigation investments after the event;
costs incurred by upstream partners or public-safety organizations.

Conversely, those possible costs should not be asserted without evidence. A large ecosystem can produce a large hypothetical total, but hypothetical aggregation is not measurement.

The accountable use of the disclosed figure is to show what Bandwidth told investors it could quantify at the time. It creates a checkpoint for later reconciliation. Did the final observed effect fall within the estimate? Which component came from lost usage, credits or customer behavior? Did mitigation spending change? Which customer-experience effects persisted into 2022?

Financial disclosure can also reveal incentives. If lost transaction volume and credits create a measurable cost, continuity investments can be compared against a known loss boundary. But the decision should not be reduced to a simple loss-versus-mitigation calculation. Emergency-service continuity and public communications reliability involve consequences that are not fully captured in carrier revenue.

Responsibility follows operational control

Shared incidents invite two weak explanations. One assigns everything to the carrier because the carrier was attacked. The other assigns everything to the attacker and treats providers as passive victims. Neither maps the controls.

Bandwidth

Bandwidth controlled the communications network named in its disclosure. Its accountability included:

architecture and separation of critical services;
capacity planning;
traffic and service telemetry;
DDoS detection;
mitigation-provider and upstream relationships;
routing and filtering decisions within its authority;
customer status communications;
restoration priorities;
evidence supplied to customers and regulators.

The public record says mitigation with cybersecurity partners was proving successful. [2] It does not disclose how much traffic was filtered, which services recovered first, what legitimate traffic was lost or how emergency-call paths were verified. Those are evidence gaps, not proof that mitigation failed.

Upstream carriers and mitigation providers

An upstream carrier or scrubbing provider controls systems that Bandwidth cannot operate directly. CISA guidance emphasizes upstream coordination, flow visibility, filtering, rate limiting and routing-based mitigation in appropriate circumstances. [10] The relevant evidence includes the time to engage, available clean capacity, filter changes, route advertisements, false-positive rates and the handoff from emergency mitigation back to normal operation.

The existence of a mitigation contract does not prove capacity was available in the affected path. The existence of unused capacity does not prove routes could move traffic to it safely. Provider accountability therefore requires test and incident evidence, not a product name.

Downstream VoIP and software providers

Downstream providers did not control Bandwidth's internal mitigation. They did control their own dependency design and customer response.

Their accountable controls included:

knowing which services and numbers depended on Bandwidth;
separating inbound, outbound and emergency-service dependencies where practical;
maintaining tested carrier alternatives;
monitoring call completion independently;
notifying customers promptly;
giving realistic alternative-calling instructions;
preserving incident records.

A multi-carrier configuration is not automatically resilient. Two carriers can share transit, mitigation, data centers, number-routing dependencies or operational tooling. A backup that requires a lengthy manual number move may not protect a short emergency. A backup that has never carried production traffic may fail under load or lack correct emergency-service data.

Public-safety entities and regulators

Public-safety answering points and regulators do not operate the carrier's packet filters. They can define reporting thresholds, notification content, escalation paths and evidence retention. They can also test whether provider notices arrive in time for public-safety organizations to adapt.

The regulatory objective should not be a larger incident form for its own sake. It should be a record that helps distinguish scope, cause, active risk, restoration and required follow-up. A notification without routing or geographic detail may satisfy a procedural step while offering little operational help.

Enterprise customers and end users

Enterprise customers can evaluate providers, configure alternatives and test business continuity. Individual end users usually cannot see the hidden carrier chain. They cannot choose a route for an emergency call after pressing send. Their responsibility is therefore limited.

This asymmetry should shape communications. A provider should not tell users merely to "retry" if retries add load or if the provider cannot say whether the alternate path is independent. It should provide bounded, actionable information based on the controls users actually possess.

Status communication is an operational control

Bandwidth said it regularly updated customers and partners and directed them to its status service. [2] Status communication is often treated as a public-relations layer. In a shared carrier incident, it is part of operations.

Downstream providers need information to decide whether to:

fail over calls;
reroute numbers;
disable a feature;
warn about emergency calling;
open a customer incident;
preserve logs;
delay their own restoration declaration.

A status message such as "mitigation is ongoing" may be accurate but limited public evidence. The operationally useful message identifies service class, region or market, observed effect, mitigation state, uncertainty and the next decision point.

At the same time, excessive detail can expose defensive methods. A practical standard is to publish what dependent operators need to act without disclosing signatures or capacity thresholds that would help an attacker. That can include:

whether voice, messaging, portal and emergency functions are affected separately;
whether impact is intermittent or continuous;
whether new calls and established calls behave differently;
whether a specific region or number set is involved;
whether customer failover is recommended;
whether the network is stable but restoration verification continues.

The last distinction mirrors Bandwidth's own wording. Largely stable at normal service levels since the evening of 29 September did not mean every intermittent issue had ended. [2] A mature closeout would state what "largely stable" measured and what remained under investigation.

Status records should also be preserved after the event. A live page that is overwritten loses chronology. Customers and regulators need timestamps, revisions and a clear difference between observation, diagnosis, mitigation and verified recovery.

Detection, mitigation and restoration are three different gates

An operator can detect an attack without containing it. It can reduce hostile traffic without restoring valid service. It can restore internal metrics without confirming that downstream calls complete.

The evidence should therefore be organized into three gates.

Detection

Detection evidence should show what changed and when. Network traffic volume is one signal. Call setup success, message delivery, portal transactions and emergency-service errors are others. A carrier needs service-level telemetry because a DDoS event can impair an application before a transit link is full, or fill a link while some cached or established sessions remain healthy.

Detection should also distinguish an external attack from an internal fault triggered under load. The public record does not identify such an internal fault in the Bandwidth event. The distinction remains part of responsible diagnosis: hostile traffic and a latent defect can coexist.

Mitigation

Mitigation evidence should show what control was applied and what it changed. Useful measures include traffic admitted and dropped, false-positive rates, clean capacity, service latency, call completion and geographic reachability.

Network filtering can create its own failure mode. An aggressive rule may protect infrastructure while blocking legitimate signaling or management traffic. Routing a service through a mitigation provider may change latency or reachability. Rate limiting can preserve some availability while rejecting high-volume customers.

The success criterion is not "attack traffic decreased." It is "the protected service regained bounded, verified availability without unacceptable loss of valid traffic."

Restoration

Restoration should be verified from outside the failed layer. Internal service health is necessary but not sufficient. Downstream providers should test inbound and outbound calls, messaging and emergency-related functions relevant to their configuration. Tests should cover representative regions and carriers without generating unsafe emergency calls.

The restoration record should identify:

the first stable internal interval;
the first successful external checks;
the point at which customer failovers could be reversed;
the point at which emergency-service risk notices could be closed;
any residual intermittent effects;
the criteria used to declare the incident resolved.

This evidence would reconcile Bandwidth's stabilization statement with continuing intermittent disruption.

Failover is a tested transfer, not a diagram

The common response to a carrier incident is to recommend redundancy. The word is too broad to be an accountability control.

A second provider can reduce dependency only if traffic can move to it. For voice service, that may require numbers, signaling configuration, emergency-service records, customer authentication, fraud controls, capacity and operational authority. Some changes can be automated. Others depend on carrier processes or public numbering systems.

The continuity test should ask:

Which service is being transferred?
Which record or route must change?
Who has authority to make the change?
How long does it take?
Does the destination have capacity?
Are emergency-service data and caller identity preserved?
Has the transfer been tested under realistic conditions?
How is return to the primary provider controlled?

This is where the Heng.lu reality layer is directly applicable. Records are indispensable. A telephone number assignment, emergency address and carrier agreement preserve identity and responsibility. But the record is not sovereign over the running network. It cannot force a route to propagate, a filter to pass a valid packet or a backup platform to accept a call.

Operational continuity depends on making the recorded intent executable. The evidence is a tested transfer with measured call completion, not a policy document that says failover exists.

Portability also has time dimensions. A process suitable for moving a customer between carriers over days may be useless during a minutes-long outage. Emergency continuity may require pre-provisioned alternate paths rather than an improvised transfer.

Dependency inventories must identify common control points

A supplier inventory that lists Bandwidth once does not reveal the concentration exposed by this incident.

An operational dependency map should connect:

customer-facing service;
numbers and calling direction;
emergency-service function;
primary carrier;
secondary carrier;
signaling and media paths;
internet transit and mitigation;
control portal and API;
monitoring source;
failover authority;
recovery test.

The map should identify common control points. If the primary and secondary carrier use the same DDoS mitigation service in the same region, that common dependency should be visible. If both are managed through one identity provider or one DNS zone, that should be visible. If emergency routing cannot move with ordinary traffic, that limitation should be explicit.

This inventory is not a demand for public disclosure of sensitive topology. It is an internal and contractual evidence requirement. Regulators and large customers can ask for aggregate proof without publishing exploitable detail.

Channel reporting around the Bandwidth event highlighted the visibility problem for providers and customers. [16] ServiceTitan's later analysis used call-volume data to illustrate downstream effects. [14] These perspectives show why dependency mapping must include observed service behavior. A provider may not learn the significance of a common carrier until unrelated customer products fail at once.

The regulatory record should be usable for engineering

FCC outage reporting and 911-notification rules create records for qualifying incidents. [7][8] Their value depends on whether they can support operational learning.

An engineering-useful record would preserve:

onset and detection times;
affected service and geography;
estimated user impact;
911 or public-safety effect;
cause category and confidence;
mitigation steps;
restoration milestones;
follow-up analysis;
corrections to earlier estimates.

The record should separate confirmed values from estimates and unknowns. Early reports will be incomplete. A correction process is more credible than false precision.

There is also a coordination problem. A shared carrier may report an incident, while downstream providers separately report symptoms. Without a way to relate the records, regulators can overcount one event or fail to see its ecosystem scope. A shared incident identifier or confidential correlation mechanism could improve analysis while respecting security and customer confidentiality.

The objective is not centralized control of routing decisions. It is a trustworthy evidence layer that lets operators and regulators determine what happened, which controls failed, and whether remediation was tested.

A verifiable evidence agenda

The public record supports the event boundary, but it does not support a complete technical reconstruction. The appropriate response is an evidence agenda.

Traffic and capacity

Bandwidth and its mitigation partners should be able to reconstruct aggregate traffic by time, protocol, destination, source network and mitigation action. The record should identify the first constrained resource and how close critical services came to capacity.

Service behavior

Traffic measures should be paired with voice, messaging, portal and emergency-service indicators. Call setup success, completion, latency and error classes are more meaningful to customers than aggregate packets alone.

Routing and mitigation

Operators should preserve route and filtering changes, including who authorized them, when they took effect and what service result followed. CISA guidance makes upstream coordination and routing-triggered defenses part of the available toolkit, but the incident record must show which controls were actually used. [10]

Downstream propagation

Customer notices and status records should be correlated with the carrier timeline. This can reveal which dependency paths recovered early and which remained intermittent.

Emergency continuity

The record should identify any known 911-related effects, notification times, alternate arrangements and restoration checks without exposing personal call data.

Financial reconciliation

The later actual effect should be reconciled with the $9 million to $12 million estimate and the approximately $10 million retrospective figure. [3][4][5] The reconciliation should distinguish lost usage, credits and longer-term customer effects.

Remediation

Every remediation claim should have an owner, implementation date, test method, result and residual limitation. "Increased capacity" is not complete evidence without the workload tested. "Improved DDoS protection" is not complete evidence without the service behavior under filtered and legitimate traffic. "Added redundancy" is not complete evidence without a transfer test.

What should have been tested after the incident

A post-incident test program should cover scenarios that reproduce the control problem without reproducing harm.

One test should increase synthetic or replayed load in a controlled environment while measuring voice, messaging and portal isolation. The aim is to determine whether noncritical surfaces can be constrained before critical call paths fail.

Another should simulate upstream mitigation activation. It should measure time to divert or filter traffic, legitimate-call loss, route stability and the ability to return safely to normal paths.

A third should test downstream carrier failover. Selected numbers and representative call flows should move to an alternate provider. The test should verify caller identity, inbound and outbound reachability, messaging where applicable, and emergency-service configuration using approved non-emergency test procedures.

A fourth should test communications. Operators should receive a mock incident notice and decide whether to fail over, warn customers or preserve logs. The exercise should reveal whether the notice contains enough information.

A fifth should test evidence preservation. Teams should be able to reconstruct the timeline from network telemetry, service metrics, route records, mitigation actions, customer notices and external probes.

Tests should also include failure. A backup path that fails during an exercise is valuable evidence if it is corrected. A backup that remains untested is only an assertion.

Accountability does not require pretending every detail is public

There is a legitimate security reason not to publish exact filters, capacities or topology. There is also a legitimate public interest in knowing whether critical communications infrastructure can withstand and recover from attack.

These interests can be reconciled through layered evidence.

The public record can disclose dates, service classes, regions, broad cause, restoration milestones, customer protections and tested remediation. Customers with operational need can receive more detailed dependency and failover information under appropriate controls. Regulators can receive confidential technical records. Internal teams should retain the full packet, routing and service evidence needed for engineering review.

The absence of public packet detail should not be converted into an accusation. It should be recorded as an unknown that limits the article's conclusions. The same rule applies to current remediation. Without later test evidence, the article cannot claim that Bandwidth's defenses are now effective or ineffective.

This discipline protects both readers and operators. It prevents speculative blame, while refusing to treat a corporate statement as proof of operational resilience.

The central lesson is continuity at the shared control plane

The 2021 Bandwidth attack was not significant only because a DDoS campaign reached a communications company. It exposed how voice, messaging, telephone numbers and emergency-service functions can depend on a shared network layer that end users do not see.

The strongest public facts are bounded. The attack began on 25 September. It caused intermittent disruption in certain markets and for certain customers. The network was largely stable at normal levels from the evening of 29 September, with some continued intermittent effects. Bandwidth estimated a $9 million to $12 million 2021 CPaaS revenue reduction and later described an approximately $10 million effect. [2][3][4][5]

The public record does not establish the complete vector, actor, topology, total affected-call count or full 911 impact. Those limits should remain visible.

Accountability begins where control begins. Bandwidth must account for the shared network, mitigation and restoration evidence. Upstream partners must account for filtering and clean capacity. Downstream providers must account for dependency visibility and tested alternatives. Regulators and public-safety entities must account for usable notification and evidence requirements.

The Heng.lu principle is practical here: records are ledgers of responsibility, not substitutes for running infrastructure. A number assignment, emergency address, contract or status notice can identify what should happen. Only observed call completion, routable capacity, working filters, tested transfer paths and external restoration checks show what did happen.

The durable remediation is therefore not a promise that the next attack will be blocked. It is a set of controls that can fail in bounded ways and a record that proves how they behaved. For a carrier embedded beneath many brands, that record is part of the service.

Bandwidth.com's 2021 DDoS Attack Made VoIP and 911 Continuity an Accountability Test