The Sovereignty Illusion: Trusted Cloud and the Stack Control Gap

France’s trusted-cloud model has crossed the regulatory threshold. The strategic question is whether boards understand which layer of dependency the certificate leaves outside the frame.

On 3 June 2026, the European Commission adopted its proposal for a Cloud and AI Development Act, introducing a single EU-wide framework to assess cloud and AI sovereignty and a public-sector adoption mechanism built around differentiated assurance levels. The timing matters. Six weeks earlier, on 17 April, the Commission’s own €180 million sovereign-cloud framework had admitted a Google-powered provider — Proximus’ consortium including S3NS — while ranking it below European-native stacks on the Commission’s sovereignty scale. Four months before that, in December 2025, France’s cyber agency ANSSI had qualified PREMI3NS, the trusted-cloud offering of S3NS, under SecNumCloud 3.2.

This is no longer an experimental niche. The trusted-cloud model — US hyperscaler technology, licensed and operated by a European-controlled entity — has moved from contested workaround to regulatory instrument.

The certificate answers a narrow question with discipline. It validates legal and operational controls around sensitive cloud workloads. It does not, by design, settle the strategic question that matters most under infrastructure warfare: who controls the technological stack on which the workload depends.

That distinction is now the governance problem. This is the same infrastructure at stake as in our analysis on Post-quantum cryptography risk. The encryption horizon problem and the stack sovereignty problem converge: both require visibility into systems you do not own and trust models you cannot audit.

The infrastructure may be European. The technology stack beneath it is not always.

1. What the Trusted-Cloud Label Actually Certifies

Strip away the marketing and SecNumCloud 3.2 validates three things, all of them real.

First, legal and corporate control. S3NS is a French company controlled by Thales and built through the Thales–Google Cloud strategic partnership. The regulatory logic is specific: the technology comes from a US provider, but the service is operated by a French-controlled entity, under French jurisdiction, for customers requiring protection against direct foreign control over sensitive data. On the narrow terrain of extraterritorial access to data — the US CLOUD Act, FISA Section 702, and equivalent concerns — that distinction is material.

Second, operational control. PREMI3NS is operated from France by S3NS, with a security architecture designed to separate the trusted-cloud environment from the standard public-cloud region. Google technologies and updates do not flow directly into production. They pass through a controlled validation process before being promoted into the qualified environment. That is not cosmetic. It is the operational core of the trusted-cloud model.

Third, functional depth. This is the model’s commercial reason to exist. PREMI3NS gives customers access to a sovereignised implementation of Google Cloud technology, including core cloud services in compute, storage, databases, Kubernetes and analytics. It offers a level of hyperscaler maturity that European-native providers still struggle to match across scale, automation and data tooling. Future AI and advanced analytics capabilities may extend that functional appeal further, though the exact catalogue available for qualified workloads should be verified at contracting rather than assumed from the public Google Cloud catalogue.

The label is honest about what it covers. The mistake would be to read it as something larger than itself.

SecNumCloud certifies a cybersecurity and governance perimeter. It does not certify European control over the design, intellectual property, evolution or long-term availability of the underlying technology stack.

2. The Cloud-Sovereignty Question the Certificate Leaves Open

There is a fourth layer of sovereignty, and it is the one that becomes decisive in a contested environment: technological control — who designs, maintains, evolves and can ultimately withdraw the stack.

Here the trusted-cloud model offers a controlled compromise, not a structural answer. The operating entity may be French. The infrastructure may be in France. The keys may be under European control. The service may be audited. But the technology remains derived from a US hyperscaler stack. Its roadmap is not set in Paris. Its core intellectual property is not held by the European operator. Its service evolution depends on the continued ability to import, validate and deploy upstream technological change.

That creates three exposures no certificate can retire.

The first is roadmap dependency. Every functional evolution — new database capabilities, analytics features, Kubernetes versions, AI tooling or security services — arrives on the hyperscaler’s schedule and then moves through the trusted-cloud validation process. Over time, the qualified sovereign environment can diverge from the public product. Customers do not control that cadence. They can only contract around it.

The second is reversibility in name only. A customer that builds its data estate around BigQuery logic, Google-native APIs, proprietary automation patterns or managed-service behaviour inherits exit costs that are not solved by a contractual reversibility clause. SecNumCloud requires reversibility as a principle. It cannot legislate away ecosystem lock-in. The practical question is not whether data can be exported. It is whether the workload, operating model, data pipeline and team competence can be reconstructed on a different stack within an acceptable time and risk envelope.

The third is the technology-supply scenario. If a future US administration restricted the export, licensing or update flow of cloud technology to European joint ventures — as export-control logic has already been applied in semiconductors and advanced compute — the European operator could inherit a frozen base. It might remain operational for a period. It might remain legally sovereign. But its functional and security evolution would degrade over time.

This remains a low-to-moderate probability scenario over a two-to-three-year horizon. We assess it at roughly 15–25%, with higher uncertainty beyond 2028. But it is no longer a theoretical edge case. It sits squarely inside the wider European debate on dependence on non-European cloud technology, and the Commission’s own Cloud and AI Development Act now treats cloud and AI sovereignty as a policy problem requiring an EU-wide assurance framework.

A trusted-cloud certificate manages dependency elegantly. It does not remove it. Those are different products, and only one of them is on the label.

3. Why the EDF Decision Is the Right Mental Model

EDF’s November 2025 decision is useful because it is often misread.

EDF selected Bleu and S3NS to build a trusted-cloud layer for part of its data estate, in complement to its internal private cloud, which already hosts nearly 80% of the group’s data. The decision came in the context of rapidly expanding data volumes, including data linked to the French nuclear relaunch. It should not be read as a blanket endorsement of trusted cloud for all critical workloads. It is better understood as calibrated segmentation.

That is the right model.

For sensitive but non-classified workloads — strategic corporate data, regulated analytics, controlled collaboration environments, certain AI use cases on sensitive datasets — a trusted-cloud architecture can be a defensible and often optimal compromise. It offers more legal and operational protection than a standard public cloud, while preserving much of the functional depth that modern organisations require.

For classified data and cyber-physical control of critical installations — grid dispatch, nuclear operations, real-time SCADA, safety-critical industrial control — the model is not the appropriate default and is not marketed as such. Those workloads belong on hardened internal infrastructure, dedicated defence clouds, or architectures specifically designed for mission-critical continuity under hostile conditions.

The governance mistake would be to collapse these categories.

This dynamic echoes the critical minerals trilemma we analyzed last quarter: concentrated supply, geopolitical leverage, and the absence of viable alternatives. The difference here is speed. Mineral substitution takes decades. Cloud migration takes quarters.

A board that treats “qualified trusted cloud” as a single answer to all sensitive-data questions has not reduced risk. It has merely renamed it.

4. Why This Lands Differently After The Silent Front

In The Silent Front (30 April), we argued that cyber and infrastructure warfare have become the permanent baseline of great-power competition: state actors pre-positioning inside critical networks, the OT–IT gap closing, and infrastructure becoming a pressure surface below the threshold of open conflict.

That environment reframes cloud sovereignty.

The legacy question was: can a foreign government subpoena or otherwise access my data? That is the legal question trusted-cloud structures were designed to answer. It remains important. But it is no longer sufficient.

The 2026 question is broader: can my critical workload survive a deliberate attempt to degrade, constrain, delay or politicise the technological environment on which it depends, including pressure applied through my own supply chain?

That is a resilience and control-plane question. It runs through software updates, privileged administration, API dependency, managed-service behaviour, identity infrastructure, telemetry, encryption, incident response and the practical ability to move a workload under duress.

The ICC sanctions episode illustrates the category of risk, but it should be treated carefully. In 2025, the Trump administration imposed sanctions on International Criminal Court officials, including chief prosecutor Karim Khan, barring U.S. persons from providing professional services to those designated. The sanctions compelled American companies and individuals to sever professional relationships with the affected officials, disrupting access to services — including potentially cloud-based platforms — on which the Court depended. The strategic relevance is not any single provider's intent. It is the sanctions-triggered exposure: an institution depending on US technology found itself confronting the operational consequences of a political decision taken outside Europe.

That is the pattern boards need to understand.

The trusted-cloud model improves the legal and operational position at the service layer. It does not fully answer what happens if the underlying technology supply itself becomes the lever.

Under infrastructure warfare, the dependency you cannot audit, cannot replace quickly and cannot evolve independently is not a compliance footnote. It is part of the attack surface.

5. The Commission Has Already Drawn the Distinction

The European Commission’s April 2026 sovereign-cloud procurement is more revealing than the public debate around it.

The Commission awarded a six-year framework worth up to €180 million to four providers. Three providers built on European-native stacks reached SEAL-3, the highest level under the Commission’s Cloud Sovereignty Framework. The Proximus-led consortium including S3NS, Thales, Google Cloud-related technology and Mistral AI reached SEAL-2.

That does not mean S3NS is not sovereign enough for its intended use. It means the Commission’s own scale distinguishes between European-operated borrowed technology and European-controlled technology stacks. It admits the trusted-cloud model while ranking it below home-grown alternatives on sovereignty assurance.

That is the calibrated read.

The market should not pretend there is no difference. Nor should it pretend European-native alternatives already match hyperscaler functionality across the full enterprise cloud catalogue. Both claims are wrong.

The strategic centre of gravity is shifting from certification to industrial capability. Europe can regulate trusted cloud, procure sovereign cloud and define assurance levels. But a label is not a substitute for a competitive native stack.

This is the same pattern we mapped in The Critical Minerals Trilemma (5 May) and The Precursor Problem (26 May). Europe can secure the visible layer while remaining exposed at the upstream layer. A European-assembled battery with Chinese anode materials is not autonomy. A French-operated cloud running on US hyperscaler technology is not full technological control. In both cases, the dependency has moved upstream. It has not disappeared.

6. The Calibrated Read

The trusted-cloud model is very likely to remain part of the European regulatory landscape through 2028. The SREN decree, the Commission’s April procurement, and the new Cloud and AI Development Act all point in the same direction: sensitive public and strategic workloads will increasingly be governed through differentiated assurance levels rather than a binary sovereign/non-sovereign distinction.

For sensitive but unclassified data, this is a pragmatic direction. S3NS-type offerings give European organisations a stronger legal and operational posture than standard hyperscaler cloud while preserving access to advanced cloud capabilities. In the absence of functionally equivalent European alternatives at scale, that compromise will remain attractive.

For critical operational systems, it is insufficient. The gap is not legal. It is architectural. If the workload cannot tolerate delayed updates, loss of upstream technology supply, API lock-in, identity-layer disruption, privileged-access ambiguity or exit timelines measured in years, the certificate should not be the decisive governance criterion.

For European technology policy, the implication is more severe. The EU is now building a cloud-sovereignty framework while still depending on non-European suppliers for much of the stack that makes modern cloud and AI usable at scale. The Commission’s 3 June proposal is therefore not an endpoint. It is an admission of the problem.

The certificate is a cybersecurity instrument. It was never a technology-policy instrument. The market risks conflating the two at scale.

7. Three Scenarios for European Trusted Cloud, 2026–2030

Scenario A — Managed Dependency Becomes the Default (base case, ~55%). 

Trusted-cloud models become the standard answer for sensitive but non-classified workloads in France and parts of the EU. Public-sector and regulated-industry buyers use SecNumCloud, equivalent schemes and EU assurance levels as procurement filters. European-native providers grow, but hyperscaler-derived trusted clouds retain the functional advantage in analytics, AI tooling and managed services. Dependency is better governed, not eliminated.

Scenario B — Sovereignty Shock Forces Re-Architecture (~30%). 

A sanctions dispute, export-control change, cloud-service interruption, political confrontation or major incident involving a non-European provider forces boards and regulators to revisit dependence on borrowed technology. Exit planning, workload segmentation, code portability and European-native fallback capacity become mandatory for critical sectors. Costs rise sharply because reversibility was under-contracted during the adoption phase.

Scenario C — Native Stack Acceleration (~15%). 

The Cloud and AI Development Act, strategic procurement, EIB financing, national cloud strategies and industrial demand converge into a real European scale-up cycle. European-native stacks close part of the functionality gap in priority workloads: secure collaboration, regulated analytics, sectoral AI, edge cloud, government workloads and critical infrastructure operations. Hyperscaler-derived trusted cloud remains part of the landscape, but no longer monopolises the high-functionality sovereign segment.

The base case is managed dependency. The strategic opportunity is to make that dependency explicit, priced and reversible before the shock arrives.

8. Weak Signals Worth Tracking

The first signal is the implementation of the Cloud and AI Development Act: how its four assurance levels are defined in practice, whether public-sector adoption mechanisms become binding, and whether critical sectors such as energy, defence, health and finance receive differentiated procurement rules.

The second is the evolution of EUCS. Recent drafts and political negotiations around the European cybersecurity certification scheme for cloud services have weakened or removed stricter legal-immunity criteria from the highest assurance tier. Whether those criteria return, disappear permanently, or reappear through procurement rather than certification will shape the market.

The third is the Commission’s use of SEAL levels in future procurement. If SEAL-3 becomes the de facto benchmark for high-sensitivity EU workloads, European-native providers gain a strategic advantage. If SEAL-2 remains widely accepted for most workloads, trusted-cloud models built on US technology will remain structurally embedded.

The fourth is the service catalogue of qualified trusted clouds. Boards should track which AI, analytics and managed services are actually available inside the qualified environment, not merely in the public hyperscaler catalogue. The gap between public-cloud capability and sovereign-cloud capability is where operational friction will appear.

The fifth is the first major forced-exit case. A customer that attempts to move from a hyperscaler-derived trusted cloud to a European-native stack will reveal the real portability cost: data, APIs, skills, monitoring, security tooling, automation and contractual exit rights.

9. What This Means, Concretely, For Boards

Discipline 1 — Classify before you certify.

A trusted-cloud label is meaningful only against a workload’s sensitivity tier. Boards should define at least four categories: public, internal, sensitive, and critical/classified. Trusted cloud is relevant for the middle categories. It is not a universal answer for the top tier.

Discipline 2 — Treat SecNumCloud as the floor, not the verdict.

SecNumCloud clears a serious legal, operational and cybersecurity bar. It does not resolve the technology-dependency question. The board’s job begins where the certificate stops: roadmap control, service-catalogue drift, reversibility, privileged access, identity dependency, incident escalation and exit timelines.

Discipline 3 — Contract for the cut-off scenario before it becomes political.

Procurement teams should negotiate audit rights, standardised export formats, tested exit procedures, escrow or continuity provisions where available, and a 24-month workload migration plan before signing. These clauses are cheap before adoption and expensive after lock-in.

Discipline 4 — Diversify across the dependency axis, not just the vendor axis.

Two trusted-cloud offerings built on US hyperscaler technology are not true diversification. They may diversify operators, contracts and jurisdictions, but they do not diversify the upstream technology dependency. A serious architecture should include at least one European-native stack for selected workloads, even if functionality is narrower.

Discipline 5 — Separate data sovereignty from control-plane sovereignty.

Where data is stored matters. Who operates the environment matters. But boards must also ask who controls the management plane, the update path, the API layer, the identity stack, the observability tooling and the incident-response chain. Those layers decide continuity under stress.

The trusted-cloud certificate is a real achievement of European cyber governance. The legal protection it offers is not cosmetic. But it answers the question Europe was asking in 2018: can sensitive data be protected from direct foreign legal reach?

The question of 2026 is different.

In a theatre where critical infrastructure is probed continuously, where sanctions can move from financial instruments to technology access, and where cloud and AI are now part of the strategic industrial base, the decisive variable is not only where the data sits. It is the dependency you cannot audit fully, cannot reprice quickly and cannot exit under pressure.

A label tells you that you have cleared a bar. It does not tell you what you are standing on.

The next question is not whether Europe will respond to these pressures. It is how. A follow-up analysis will examine the European Commission's proposed Cloud and AI Development Act — specifically, whether its technical criteria create enforceable sovereignty or merely procedural opacity.

---

From cloud-dependency mapping to critical-infrastructure exposure, CES Intelligence provides the independent judgement senior leaders need to classify, contract and govern strategic technology risk. Request a secure consultation.

DISCLAIMER

This briefing is not investment advice, financial advice or legal advice.

This briefing is based on publicly available sources cited herein. Factual claims are attributed to named sources. Analytical judgments, scenario assessments and probability estimates reflect the author's professional assessment and do not constitute assertions of fact. Readers are advised that technological and geopolitical analysis involves inherent uncertainty. CES Intelligence and its authors accept no liability for decisions taken on the basis of this briefing. This briefing does not constitute an allegation against any named individual, corporation, or state entity.

SOURCES

This briefing draws on S3NS and Thales public communications on PREMI3NS and SecNumCloud 3.2; EDF’s 5 November 2025 announcement on Bleu and S3NS; Décret n° 2026-272 of 14 April 2026 under the SREN framework; the European Commission’s 17 April 2026 cloud-sovereignty procurement announcement; the Commission’s 3 June 2026 Cloud and AI Development Act proposal; public reporting and official responses on the ICC/Microsoft sanctions episode; and the published CES Intelligence analyses The Silent Front, The Critical Minerals Trilemma, The Precursor Problem, AI Sovereignty and The Energy Front.