89.6% of EU Companies With a CDN Run on Cloudflare — And DORA's Concentration-Risk Rules Don't Cover It

On September 8, 2026, security-intelligence vendor CipherCue published an HTTP-fingerprinting analysis of 44,143 European companies with a detectable CDN. 39,547 of them — 89.6% — sit behind Cloudflare. The methodology is mechanical and disclosed: a cf-ray header or server: cloudflare response marks a company as Cloudflare-fronted; x-amz-cf-id marks Amazon CloudFront; Fastly and Akamai get their own header signatures (ciphercue.com). It went to #1 on Hacker News within hours (369 points, 333 comments at the time of writing) — not because the number is shocking (everyone who's worked in infra has felt Cloudflare's gravity), but because seeing it laid out per-country, at this scale, makes the abstract feel concrete.

CipherCue is upfront about the limits of its own dataset: the cohort skews toward small and mid-sized companies (Cloudflare's generous free tier dominates that segment), a company using multiple CDNs gets double-counted, and CDN detection tells you the front door — not where the data actually lives on the backend. Those caveats matter and this post keeps them in view. What doesn't need a caveat is the per-country breakdown, which is remarkably consistent:

(Source: CipherCue, "Among European Companies That Use a CDN, Nearly 9 in 10 Use Cloudflare," 8 Sept 2026. Amazon CloudFront trailed a distant second at 3,112 detections; Fastly 1,299; Akamai 396.)

We've written before about Cloudflare's CDN/WAF stack as a CLOUD Act and GDPR transfer problem — that post is still the right read for the jurisdiction angle, and we won't repeat its Schrems II analysis here. This post is about a different, less-discussed cost of the same concentration: availability. Not "can the US government compel Cloudflare to hand over your logs," but "what happens to your product when Cloudflare's control plane has a bad day — and why the regulation that was specifically written to make companies think about exactly this risk doesn't currently apply to the vendor 89.6% of them are using."

This isn't "just caching"

The reflexive dismissal of CDN concentration is that a CDN just caches static assets, so a Cloudflare incident means slightly slower page loads at worst. That was true in 2015. It isn't true of what most companies actually put behind Cloudflare in 2026:

• DNS resolution — if you use Cloudflare as your authoritative DNS provider and your CDN, an incident in one can take down the other's benefit; your domain doesn't resolve, full stop.
• TLS termination — Cloudflare holds (or proxies) the connection your users' browsers actually negotiate with.
• WAF and bot management — rules that decide whether a legitimate request or a legitimate user ever reaches your origin.
• DDoS mitigation — the layer standing between your origin and the internet's worst traffic.
• Increasingly, compute — Workers, KV, D1, R2 sit in the same account, same dashboard, same control plane as the CDN.

None of that is "just a cache." It's the front door, the lock, the security guard, and increasingly the lobby itself. When the front door has a bad configuration push, it doesn't matter how resilient your own application code is.

Three outages, one pattern

Cloudflare publishes detailed, technically honest post-mortems — better disclosure than most vendors this size manage. That transparency is exactly what makes the pattern across the last four months so easy to verify. Three separate incidents, three unrelated technical root causes, one shared structural cause: a change to a shared control plane that Cloudflare's entire customer base sits behind simultaneously.

Read the root causes again: a database permissions change, a security killswitch, an API parameter bug. None of these are exotic attacks or acts of god — they're the ordinary, everyday configuration and code changes that happen at every infrastructure company, every week. The difference is blast radius. When your own team ships a bad config change, it affects your own systems. When Cloudflare ships one, it affects every one of the (per CipherCue) tens of thousands of European companies sitting behind the same control plane at the same moment — regardless of how well-architected any individual customer's own application is.

Cloudflare's own response has been to name this explicitly: "Code Orange: Fail Small," published 19 December 2025 after both the November and December incidents, commits to rolling out configuration changes with the same gradual, tested process used for code deployments — instead of the near-instant global propagation (via their "Quicksilver" config system) that let a single bad config reach the whole network in seconds (blog.cloudflare.com). That's a credible, serious engineering response — and also, structurally, an admission that the previous architecture let a config change ripple to (in the December case) 28% of global HTTP traffic in one push.

The regulation built for this problem doesn't reach this vendor

Here's the part that doesn't show up in most of the coverage: the EU already has a regulatory framework that names "ICT concentration risk" as a defined, assessable thing — and it points directly at this exact pattern. It just doesn't currently reach Cloudflare.

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies to the financial sector — banks, insurers, investment firms, and (critically for this discussion) their ICT vendors. Article 28 sets the general principles for managing ICT third-party risk. Article 29, "Preliminary assessment of ICT concentration risk at entity level," requires financial entities to explicitly assess, before signing any contract for ICT services supporting a critical function, whether they'd be contracting a provider that isn't easily substitutable, or stacking multiple critical dependencies on the same provider or closely-connected providers. That's a remarkably precise description of what CipherCue just measured at market scale.

DORA doesn't stop at self-assessment. Article 31 lets the European Supervisory Authorities (ESAs) designate individual vendors as Critical ICT Third-Party Providers (CTPPs) — subjecting them to direct EU-level oversight (annual risk reviews, reporting obligations, on-site inspections) based on four criteria: systemic impact of a failure, the systemic importance of the financial entities relying on it, how deeply those entities depend on it for critical functions, and how substitutable it is.

On 18 November 2025 — the same day as Cloudflare's first outage in this table, coincidentally — the ESAs published the first CTPP list. Nineteen providers made it (PwC Legal): Amazon Web Services, Google Cloud, Microsoft, IBM, Oracle, SAP, Deutsche Telekom, Orange, Equinix, InterXion, Kyndryl, NTT DATA, Tata Consultancy Services, Accenture, Capgemini, Bloomberg, Colt, Fidelity National Information Services, and LSEG Data and Risk. We checked the ESAs' own announcement directly — Cloudflare is not on it, and isn't mentioned anywhere in the release (eba.europa.eu).

That's not a mistake — it's scope. DORA's CTPP regime only reaches vendors that financial entities themselves rely on directly for regulated critical functions, and the first designation round is dominated by hyperscale compute and core banking/data infrastructure, not edge/CDN providers. A bank's DORA-relevant ICT stack usually runs through AWS or Azure, not through a CDN in front of its marketing site. Fair enough on its own terms. But it leaves a real gap: CDN concentration among the broader EU company base — 89.6% on one vendor, per CipherCue — is measurably higher than compute concentration among the specific CTPP list (spread across at least three hyperscalers plus regional telcos). The layer with the most extreme single-vendor concentration is, for now, the one layer DORA's oversight regime doesn't touch. If you're not a DORA-regulated financial entity, none of this binds you directly either way — but the assessment method DORA mandates (the Article 29 substitutability-and-stacking test) is a genuinely useful, free framework for any EU SaaS team to run against its own CDN dependency, whether a regulator requires it or not.

Run the DORA-style assessment on your own stack

You don't need to be a bank to ask Article 29's two questions about your own architecture:

1. Is this provider easily substitutable for the specific functions you've put behind it (not "could I switch CDNs in theory," but "how much WAF-rule tuning, bot-management scoring, and Workers code would I have to rebuild")?
2. Are you stacking multiple critical functions on the same provider — DNS and CDN and WAF and DDoS mitigation and compute, all in one account, all sharing one control plane?

A simple scoring rubric, adapted from those two questions, for whatever edge vendor you're currently running:

Score 6+ across the three dimensions and you have, in DORA's language, an unassessed concentration risk — worth a documented decision, even an accepted one, rather than an unexamined default.

Before you can score it, you need an honest inventory — and most teams don't actually have one, because "which CDN do we use" was answered once, years ago, for the main app, and nobody's checked the marketing site, docs subdomain, status page, or that one API gateway a different team stood up. This is literally CipherCue's own method, pointed at your own domains instead of someone else's:

#!/usr/bin/env bash
# cdn-fingerprint.sh — mirrors CipherCue's HTTP-header detection method
# against your own properties. Run it against every subdomain you can
# think of, not just the primary app — concentration usually hides in
# the properties nobody's audited since they were set up.

domains=(
  "example.com" "www.example.com" "app.example.com"
  "api.example.com" "docs.example.com" "status.example.com"
)

for d in "${domains[@]}"; do
  headers=$(curl -sI --max-time 5 "https://$d" 2>/dev/null)
  vendor="unknown / no CDN detected"
  echo "$headers" | grep -qi "^cf-ray:"        && vendor="Cloudflare"
  echo "$headers" | grep -qi "^x-amz-cf-id:"   && vendor="Amazon CloudFront"
  echo "$headers" | grep -qi "fastly"          && vendor="Fastly"
  echo "$headers" | grep -qi "x-akamai"        && vendor="Akamai"
  echo "$headers" | grep -qi "^server: bunnycdn" && vendor="BunnyNet"
  printf "%-20s %s\n" "$d" "$vendor"
done

Wire that into a scheduled CI job (a nightly GitHub Actions cron works fine) and alert on any change in vendor, not just presence — that catches both an unplanned migration and a team quietly signing up for a new edge vendor nobody else knows about, which is its own kind of concentration-risk blind spot (you can't assess a dependency you don't know exists).

Mitigating it without pretending you can eliminate it

Full multi-CDN failover is real, but it's expensive in engineering time and it usually just relocates the lock-in rather than removing it — your WAF rules and bot-management tuning still live in one vendor's dashboard even if DNS can technically fail over to a second CDN. Two lower-cost steps get you most of the resilience benefit without a full multi-CDN build-out:

Separate your DNS provider from your CDN/WAF provider. This is the single most common accidental coupling: a company signs up for Cloudflare's CDN, and defaults to Cloudflare DNS too, because the onboarding flow makes that the path of least resistance. Now a Cloudflare control-plane incident doesn't just degrade your CDN — it can take your domain's DNS resolution down with it, with no independent path to route around it. Hosting DNS with a separate provider costs nothing extra in most cases and removes exactly one layer of coupling for free.

Pair an EU-jurisdiction backend with a genuinely independent edge vendor, rather than assuming "EU" and "independent" are the same property. sota.io runs application infrastructure out of a single EU datacenter (Falkenstein, Germany) specifically to avoid CLOUD Act exposure on the compute layer — that's a jurisdiction decision, not a concentration-risk decision, and we're not going to overstate it as the latter. If you're also thinking about the CDN layer's concentration risk specifically, the EU-native CDN/WAF alternatives we've compared before — BunnyNet (Slovenia), Gcore (Luxembourg), CDN77 — solve a different problem than sota.io does, and solving both means picking vendors independently at each layer rather than assuming one EU-jurisdiction choice covers the whole stack. A CLOUD-Act-free CDN in front of a CLOUD-Act-free backend, on two unrelated control planes, is a materially different risk profile than either "everything on Cloudflare" or "everything on one EU vendor that happens to do CDN, DNS, and compute together" — the second pattern just rebuilds the same coupling this post is about, with different logos.

The takeaway

The CipherCue number is a snapshot, not new information to anyone who's worked in this industry — Cloudflare's dominance has been visible for years. What's new is having three independent, technically-verified 2025–2026 outages to point at as concrete evidence of what that concentration costs in availability, sitting next to a regulatory framework that explicitly names "ICT concentration risk" as something worth formally assessing — and that, as of the first CTPP designation round, doesn't currently reach the layer where the concentration is most extreme. You don't need DORA to apply to you to borrow its method. Run the substitutability test on your own stack, fingerprint your own domains the way CipherCue fingerprinted 44,143 companies' domains, and make the concentration decision a documented one instead of a default one.

Sources: CipherCue, "Among European Companies That Use a CDN, Nearly 9 in 10 Use Cloudflare," 8 Sept 2026 · Hacker News discussion · Cloudflare, "Cloudflare outage on November 18, 2025" · Cybernews on the December 5, 2025 outage · Cloudflare, "Cloudflare outage on February 20, 2026" · Cloudflare, "Fail Small — our resilience plan" · EBA/ESAs press release on CTPP designation, 18 Nov 2025 · PwC Legal, full CTPP list · Regulation (EU) 2022/2554 (DORA), Articles 28, 29, 31.

See also: Cloudflare CDN + WAF EU Alternative 2026 for the CLOUD Act/GDPR jurisdiction analysis and full BunnyNet/Gcore/CDN77 comparison this post deliberately doesn't repeat.