MICKAI
Article · 4 July 2026

The 19 Named Providers: DORA Just Made Cloud Concentration a Supervisory Problem

When your regulator names your provider critical, substitutability and exit stop being paperwork. Owning the intelligence layer is the substitutable fourth option.

The 19 Named Providers: DORA Just Made Cloud Concentration a Supervisory Problem
Author
Micky Irons
Published
4 July 2026
Follow Micky Irons
LinkedInX
DORAconcentration riskICT third-party risksovereign AIfinancial services resilience

# The 19 Named Providers: DORA Just Made Cloud Concentration a Supervisory Problem

By Micky Irons

On 18 November 2025, the European Supervisory Authorities did something the financial sector had been waiting on since DORA came into force. They published the first list of designated Critical ICT Third-Party Providers. Nineteen names. Amazon Web Services, Microsoft Azure, Google Cloud, IBM, Bloomberg, and the rest of the shortlist that quietly runs a large share of European finance. Those nineteen are now under direct oversight from the ESAs through the Lead Overseer framework, examined much the way a bank is examined.

If one of those providers is in your critical-function stack, and for most of you at least one is, the register you file just changed character. Your provider is no longer a commercial choice you documented. It is a named systemic node your regulator watches. That reframes two obligations you already carry under DORA Article 28 and the exit-strategy provisions: substitutability and orderly exit. Both of those just went from paperwork to something a supervisor can pull the thread on.

I want to be precise about what this is and what it is not, because the sector is full of people over-reading it in both directions.

What the designation actually changes

DORA does not ban cloud. It never has, and this list does not start doing so. AWS, Azure, and Google Cloud remain lawful, supported, and in many workloads the sensible engineering choice. The ESAs designating them as critical is not a warning to leave. It is an acknowledgement that a handful of providers now sit under so many regulated firms that a failure at one is a failure across many at once. That is the definition of concentration risk, and it is now a supervisory object rather than an internal risk-committee footnote.

So the honest read is this. The designation does not put a red line through your architecture. It raises the bar on what you must be able to demonstrate about it. Can you evidence that a critical function running on a named provider could be moved, or run without them, inside a defensible timeframe? Can you show the exit is real and not a slide? Under DORA that was always the theory. With nineteen providers now formally critical, it is the practice supervisors will test.

Classical marble scene, Nemesis, gold rim light on void black

Substitutability is the word that now costs you

Here is where most exit strategies fall apart. You can write a credible plan to move from one hyperscaler to another. What you usually cannot write is a credible plan to run the workload without a hyperscaler at all, at least not for the functions where the intelligence layer, the models, the inference, the reasoning over your own data, has been rented from the same concentrated set of providers.

That is the gap the designation exposes. If your AI and analytics capability is inseparable from the platform it runs on, then your substitutability story has a hole in exactly the place regulators are now looking. Two of your critical dependencies, compute and cognition, collapse into one named node. When that node is on the list, your register is harder to defend, because you cannot point to a genuine alternative that keeps the function alive under stress.

The fourth option: own the intelligence layer

This is where we come in, and I want to frame it accurately rather than sell you a panic. The usual choices for a critical AI workload are three: stay on the named provider, migrate to another named provider who will likely be on next year's list, or degrade the capability. Cloud-to-cloud migration does not fix concentration. It relocates it.

The fourth option is to own the intelligence layer yourself. Mickai is a Sovereign Intelligence Operating System. It is a full stack, models, inference, orchestration, and audit, that a regulated organisation owns and runs inside its own walls. Air-gapped if you want it air-gapped. Every action it takes is written to a cryptographically-signed audit record, so the evidence a supervisor asks for is generated as the system runs, not reconstructed afterward. It is built and live today, deployed on your own hardware, not a roadmap.

What that does to your register is concrete. The AI capability stops being a line that depends on a designated critical provider. It becomes a component you control, whose exit strategy is trivial because there is no third party to exit from, and whose substitutability is total because you already hold the substitute. You do not remove AWS or Azure from your estate. You remove your most sensitive intelligence workloads from the concentration count, which is precisely the part of the register the ESAs have now made a supervisory problem.

The engineering that makes this defensible rather than a slogan sits in our filings: 104 UK patent applications, roughly 2,340 claims across 13 families, filed under named inventor Mickarle Wagstaff-Irons and building toward examination. They cover the sovereign runtime and the signed audit trail that a regulated firm owns end to end. As a supporting capability, an on-chain attestation rail lets an auditor or regulator independently validate our post-quantum-signed records without us being present, so your evidence of control never depends on the vendor whose concentration you are trying to reduce.

Classical marble scene, Nemesis, gold rim light on void black

The honest boundary

Let me hold the line I always hold. This is not a claim that you are barred from cloud. You are not. DORA, the FCA and PRA, the EBA guidelines, they all permit cloud with controls, and the genuine no-cloud requirement is workload-level and narrow: classified material, defence, isolated operational technology, a DPIA that comes back negative. The market for sovereign ownership rests on preference and control, not prohibition. It is real preference, mind you. Across the UK and EU that is roughly 16,092 register-backed institutions, sitting inside an enterprise-AI-platform market that runs from about £11.7bn in 2025 toward £39.7bn by 2030. But it is a preference, and I will not tell you otherwise to close a point.

What the 19-provider list changes is not the legality of cloud. It changes the cost of concentration. It gives your supervisor a named list to ask about and gives you a harder question to answer about substitutability. Owning your intelligence layer is the clean answer to that question. It is the fourth option, and right now it is the only one that actually shrinks the register you have to defend.

Frequently asked questions

Does the DORA critical-provider designation mean we have to leave AWS, Azure, or Google Cloud?

No. The designation places those providers under direct ESA oversight; it does not prohibit their use. DORA permits cloud with appropriate controls. What changes is your obligation to evidence real substitutability and a credible exit for critical functions that depend on a now-designated provider.

How does owning an AI layer reduce our concentration risk if we still use cloud for other things?

It removes your most sensitive intelligence workloads from the count of functions that depend on a designated critical provider. You keep cloud where cloud makes sense. You take the reasoning-over-your-own-data workloads in-house, so that particular register line has a genuine, owned substitute rather than another hyperscaler that may be designated next. Our writing on sovereign AI ownership for regulated firms walks through how that maps onto DORA Article 28.

Is a sovereign intelligence operating system actually deployable today, or is this a roadmap?

It is built and live. Mickai runs on hardware you own, inside your own perimeter, air-gapped if required, with a cryptographically-signed audit record on every action. This connects directly to our related work on the signed audit trail as a compliance primitive.

What is the on-chain attestation rail, and is it a token or crypto product?

It is neither. It is a validation utility that lets an auditor or regulator independently verify our post-quantum-signed audit records without the vendor being present on-premises. There is no token, no tradable value, and none is ascribed by design. It exists so your evidence of control does not depend on the provider whose concentration you are trying to reduce. See our related writing on independent audit validation for regulators.

---

If your critical-function register now names a designated provider, the question your supervisor will eventually ask is simple: show me the substitute. The fourth option is to already own it.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/dora-19-critical-providers-concentration-risk-and-the-fourth-option. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles
4 Jul 2026
Alex Karp Is Right: You Are Paying For Tokens You Cannot Audit
Alex Karp said hosted-AI vendors capture your data and bill you for unproductive tokens that create no value. He is right. We built Mickai so regulated organisations own the substrate instead of renting it, with a signed audit record on every action.
4 Jul 2026
The EU Just Pushed High-Risk AI to December 2027. Here Is What We Are Building Instead of Waiting
The Digital Omnibus provisional agreement moves the EU AI Act high-risk deadlines from August 2026 to December 2027. Most coverage frames the delay as relief. We frame it as the window to own your compliance stack outright, so you are compliant on day one in 2027 instead of retrofitting logging, oversight and traceability under a live deadline.
4 Jul 2026
Article 50 Lands in August: Machine-Detectable AI Provenance, and Why We Sign It At Source
Article 50 makes synthetic content machine-detectable from 2 August 2026, and the draft Code of Practice names C2PA as the route. We bind Content Credentials to the cryptographically-signed audit record Mickai writes on every action, so provenance is produced at source inside your own walls, not bolted onto a cloud API afterward.
4 Jul 2026
Under Oath, They Said They Could Not Say No. That Sentence Is the Whole Market
Microsoft France told the French Senate under oath that it cannot guarantee European data will never reach US authorities under the CLOUD Act, even inside a French sovereign region. We think that single sentence defines the market. Sovereign cloud is a real engineering improvement, but while the parent is US-domiciled the legal gap stays open. The only structure where the answer to a foreign subpoena is genuinely no is one you own and run inside your own walls.