Published: 12th October, 2026

White paper

The Physics of Critical Connectivity Failure

What 45 major infrastructure failures reveal about shared dependencies, recovery and resilient design

Resilience often begins by adding an alternative: another link, network, supplier or site. That protects a service when an individual component fails. Protection against a wider incident depends on what the primary and alternative paths still share. It also depends on whether the service can detect a failure at the layer where it occurs, and whether recovery remains available. Where a dependency remains shared, one incident can affect both paths. A resilience review therefore needs to identify each shared dependency, then either separate it or record it as an accepted exposure.

The first edition of this paper, part of CSL’s Critical Connectivity® Research Series, sets out how consequential connectivity failures propagate. It applies a six-stage failure chain to 45 documented incidents from 2018 to 2026, then draws out the design principles and assurance questions that follow. It is the evidence behind CSL’s approach to resilient connectivity: independence, not redundancy alone.

Speak to CSL

Why the evidence matters now

Payments, emergency calls, clinical systems, industrial controls and logistics all assume connectivity is present. As that dependence has grown, so has investment in second carriers, backup links, multi-region cloud and failover systems. If those alternatives still share a dependency with the primary, that investment can leave in place the exposure it was meant to remove.

Regulatory scrutiny of mobile resilience is widening at the same time. The UK regulator opened investigations in December 2025 into two national voice outages in 2025 that affected emergency calling. The Australian regulator began court proceedings in July 2026 over a 2025 emergency-call outage. The investigations and proceedings record scrutiny rather than findings of fault.

What the 45 incidents show

One class of failure does not respond to added redundancy in the same way. In all 45 analysed incidents, at least one documented shared dependency amplified the impact. The recorded elements include control planes, identity and naming services and common software. They also include replicated data states, shared cable corridors and the management networks responders needed. That result reflects how incidents were selected for the corpus rather than how common shared dependencies are across networks in general.

The coded service outcome was failed or insufficient in 24 incidents and degraded or partial in a further 19; the outcome was not reported in the other two. No incident was coded as operating fully as intended. An alternative path was reported as carrying partial traffic in six incidents. No such outcome was reported in the other 39.

In 25 of the 45 incidents, the initiating failure lay in a platform or service that traffic reaches, rather than in a carrier’s network. These included cloud, edge, DNS and identity platforms, endpoint software, hosting data centres and application systems. A device can retain radio signal while identity, DNS, cloud processing, payment authorisation or emergency-call handling is unavailable.

Cover of The Physics of Critical Connectivity Failure

Inside the white paper

Six coded stages for every incident

The Critical Connectivity Failure Chain follows each incident from trigger to business consequence.

Recovery as a resilience layer

Recovery capability was impaired in 27 incidents, showing why recovery should stay available when the service is affected.

Five failure archetypes

Each archetype is defined by the shared dependency involved, from control planes to physical routes and corridors.

Seven design principles

The principles are paired with 10 assurance questions for boards, service owners and procurement teams.

Eleven domains across nine years

Incidents from 2018 to 2026, from mobile cores and cloud platforms to data centres and submarine cables.

A transparent evidence base

A published register gives the primary source type, confidence, verification status and caveat for every incident.

Built on the Critical Connectivity Failure Atlas, dataset v0.8.16

Each edition of the paper is recalculated from a maintained research database with a documented taxonomy, evidence rules and review controls, rather than from a narrative archive. Dataset v0.8.16, for the incidents coded to a cut-off of 19 September 2026, records:

46 coded incidents: 45 meet the evidence threshold for descriptive analysis; one 2026 incident is excluded pending the regulator’s findings

High-confidence records: 43 of the 45 analysed records, each supported by a regulator, government or detailed provider record

Nine calendar years: incidents in the United Kingdom, Europe, North America, Australia, the Pacific, East and South-East Asia, the Middle East and East Africa

11 domains: telecommunications, emergency calling, internet routing, cloud, identity, DNS, endpoint security, aviation systems, data centres, terrestrial fibre and submarine cables

25 classified academic studies: 21 of them peer-reviewed or venue-confirmed, maintained in the Atlas academic evidence layer

Claim-specific evidence rules: the strongest source class is defined for each type of claim, and disagreement between sources is recorded

A published source register: primary source type, evidence confidence, verification status and material caveat for every catalogued incident; 38 of the 46 primary sources were verified live, and the other eight have a recorded preservation or confirmation action

Who should read it?

Boards and executive teams accountable for service continuity
Service owners in emergency services, payments, healthcare and transport
Procurement teams specifying resilience requirements in connectivity contracts
Network and infrastructure architects designing failover, recovery and monitoring
Risk, compliance and business continuity teams assessing single points of failure
Integrators and product teams building services that depend on continuous connectivity

Redundancy is not the same as independence

The paper does not argue against redundancy. A second link, site, supplier or platform still reduces the chance that the loss of one element interrupts a service. That logic holds for a large class of faults.

The distinction the corpus records is narrower. Redundancy protects against a shared condition only when the second path lies outside that condition’s failure domain. The shared element could be a control plane, software logic, a data state, a physical route, a power source or an operating process. Where the primary and the alternative shared one, a single condition reached both.

For an architecture or procurement review, the paper asks one question, whatever the number of networks or components:

Which failure domains do the primary and alternative paths still share, and which of those are acceptable?

CSL’s rSIM® technology and DualCore® architecture apply the same principle to specific connectivity layers. With rSIM technology, one SIM or eSIM holds two multi-network profiles. The SIM tests whether the active path can pass data and, when a configured failure condition is met, moves to the other profile. Where the two profiles are provisioned through independent operator cores, a failure in one core leaves the other path unaffected. Layers such as DNS, identity and cloud platforms need separate assessment on the same end-to-end principle.

Download the white paper

Get the full research paper

The Physics of Critical Connectivity Failure: what 45 major infrastructure failures reveal about shared dependencies, recovery and resilient design

This first edition was published in October 2026. It uses Atlas dataset v0.8.16 and includes a glossary of the technical terms in the paper.