All articles
CloudCybersecuritySovereignty

When Ordinary Tools Quietly Become Critical Infrastructure

Nobody decides to make a SaaS tool load-bearing for the economy. It just happens, one convenient choice at a time.

Ilke Tosunoğlu
Ilke TosunoğluMay 14, 20268 min readUpdated July 20, 2026
Infographic: a single routine software update propagates a fault across airports, healthcare, banking, offices, broadcast and cloud services, ending in 8.5 million affected devices, illustrating the path from convenience to embedding to concentration to criticality.

Part of the pillar series Europe's Digital Dependence, Explained.

On 19 July 2024, a single content update from one security vendor crashed an estimated 8.5 million Windows devices worldwide. No attacker was involved. Airlines grounded fleets, hospitals diverted patients, banks and payment systems stalled, broadcasters went dark. One study put the direct losses to US Fortune 500 companies alone at $5.4 billion (Parametrix, 2024; Microsoft).

The uncomfortable lesson was not "that vendor was careless." It was that a tool most organizations adopted for convenience had quietly become critical infrastructure: a single point of failure with a continent-sized blast radius. And it was far from the only one.

How convenience becomes a single point of failure

There is a repeatable mechanism here, and naming it is the first step to managing it.

Diagram of the four-stage path (convenience, embedding, concentration, criticality) above a table of recent concentration and continuity shocks: CrowdStrike (2024, ~8.5M Windows devices), SolarWinds (2020, ~18,000 orgs / ~100 breached), MOVEit/CL0P (2023, 2,500+ orgs / ~93M individuals), AWS US-EAST-1 (2025, ~15-hour outage) and Azure Front Door (2025, global disruption).

It runs in four steps. A tool is adopted for efficiency. It gets embedded into business-critical workflows: security agents in the kernel, identity in the login path, email and collaboration everywhere. The market concentrates: three hyperscalers now hold roughly 70% of the EU cloud market (Synergy Research), and supervisors note "low levels of substitutability." Finally, criticality emerges, without anyone ever deciding it should.

The Bank of England's then-governor saw this coming back in 2019: "Two providers account for nearly half of revenues in cloud computing, bringing scale and efficiency, but also concerns about dependence and a single point of failure in the case of a cyber-attack." (Mark Carney, Mansion House, 20 June 2019)

When one update takes down a continent

CrowdStrike was not a one-off. In the space of a single month in late 2025, three more attacker-free outages cascaded across the internet, all from concentrated platforms, each from a single internal change.

Incident Year What failed Blast radius
CrowdStrike 2024 Faulty kernel-mode content update; validator missed it ~8.5M Windows devices; aviation, health, finance, emergency services
AWS US-EAST-1 2025 DNS automation race condition cascaded across services ~15-hour outage; Snapchat, Signal, Ring, banking apps (global ripple)
Azure Front Door 2025 Bad tenant config propagated globally Microsoft 365, Teams, Xbox + airlines, retail
Cloudflare 2025 A permissions change ballooned an internal "feature file" past a hard limit, crashing servers ~5.5-hour outage; roughly one in five web pages and a third of the top 10,000 sites
MOVEit / CL0P 2023 Zero-day in a shared file-transfer tool 2,500+ organizations; ~93M individuals' data
SolarWinds 2020 Compromised software-update channel ~18,000 orgs downloaded; ~100 actively breached

Sources: CISA; ThousandEyes; Cloudflare.

Notice the pattern: the most recent and most disruptive of these involved no attacker at all. A bad update, a DNS race, a permissions change, a config push. When millions of systems share the same software and the same provider, a local defect becomes a correlated, continent-scale failure. (The engineering choices that contain this, and the ones that don't, are the subject of our companion piece, Designing Against the Monoculture.)

Why regulators now treat concentration as systemic risk

This is the shift that matters most for European organizations: concentration has moved from a procurement preference to a supervised, systemic risk.

  • DORA. On 18 November 2025, the European Supervisory Authorities designated the first 19 critical ICT third-party providers for direct EU oversight, including AWS, Microsoft, Google Cloud, Oracle, SAP, and others. The designation criteria are explicitly about concentration of reliance and substitutability. (ESAs, 2025)
  • ECB. Its 2025 cloud-outsourcing guide warns of "an increased reliance… a concentration of a small number… particularly cloud service providers, and low levels of substitutability." (ECB, 2025)
  • National audit. The Netherlands Court of Audit found that every Dutch ministry uses public cloud, more than half of the most important services come from Amazon, Microsoft, or Google, and 67% had no strategic risk assessment. (Court of Audit, 2025)

The regulator is, in effect, naming the dependencies it cannot yet replace.

The risk hiding in plain sight: you can't leave

Public-cloud adoption is near-universal; tested exit plans are not. The ECB's 2025 supervisory guidance on cloud outsourcing exists precisely because supervisors kept finding deficiencies in banks' exit strategies, from missing documentation to untested transitions (ECB, 2025).

That gap is exactly why the EU has had to legislate it. Under DORA's Article 28(8), financial entities must now maintain documented, tested exit strategies for critical services. And from 12 January 2027, the EU Data Act prohibits all cloud switching and egress charges, removing the financial penalty that has long made leaving a hyperscaler prohibitively expensive (EU Data Act, Art. 29).

When France's Health Data Hub decided to move its national health platform off a US hyperscaler to a European provider on sovereignty grounds, the migration was budgeted at roughly 18 months (Euronews, 2026). Exit is feasible, but only if you designed for it.

How to reduce cloud concentration risk

Concentration risk is manageable without ripping everything out overnight. A pragmatic sequence:

  1. Map your dependencies, including fourth- and nth-party ones. You can't manage a single point of failure you can't see.
  2. Tier your workloads. Decide which functions are critical or important, and treat those to a higher standard than the rest.
  3. Demand portability by design: open standards, machine-readable export, and contract clauses for reversibility.
  4. Test the exit. An untested exit plan is a hope, not a control. Run switch drills for critical entities.
  5. Evidence it continuously, the way DORA and NIS2 now expect, not as an annual paperwork exercise.

This is where the work meets the tooling. Command operates your whole security program from one place: controls drafted and mapped to the frameworks that apply to you (NIS2, DORA, ISO 27001), evidence collected once and counted across audits, and threat intelligence triaged against your actual controls. If your concern is DORA specifically, the Growth plan covers unlimited frameworks with continuous validation.

And concentration is itself a design choice. The Soveryne Cloud Foundation runs on geographically distributed compute clusters across the EU, operated on our own infrastructure rather than resold from a single hyperscaler, so there is no single site, and no single provider, to take you down with it.

FAQ

What is cloud concentration risk? The risk that an organization, sector, or economy depends so heavily on a small number of cloud or IT providers that the failure of one causes systemic, cascading disruption. Regulators now treat it as an operational and financial-stability risk.

What is a critical ICT third-party provider under DORA? A provider whose large-scale failure could threaten financial stability, designated for direct EU oversight. The first 19 were named in November 2025.

Are cloud providers "too big to fail"? Supervisors increasingly treat the largest providers as systemically important, which is precisely why DORA, the ECB, and national audit offices now require concentration mapping, exit strategies, and resilience testing.

How do you reduce cloud concentration risk? Map dependencies, tier workloads, require portability and open standards, test your exit, and evidence resilience continuously.


Concentration is the quiet root cause behind legal, operational, and security risk all at once. The companion technical post shows the architecture that contains a single faulty update. To see controls mapped and evidenced in one place, explore Command, or start with the Growth plan for DORA.

Sources