How to Build Cloud-Sovereign Software Under the EU's CADA

On June 3, 2026, the European Commission dropped the Cloud and AI Development Act — CADA — and quietly redrew the map of where and how software companies can operate in Europe. If you deploy to the cloud for EU customers, this law will eventually touch your architecture, your vendor choices, and your deployment pipeline.

Unlike the EU AI Act, which focused on model risk classification, CADA targets the infrastructure layer itself. It introduces a four-tier sovereignty framework that classifies cloud providers based on ownership, control, data residency, and supply chain transparency. Public sector procurement is the first domino, but the private sector blueprint is clearly visible behind it.

Here is what CADA actually requires, what it means for your stack, and how to start building for compliance before the deadlines hit.

What CADA Actually Requires

CADA is part of the European Commission's broader AI Continent Action Plan. Its core objective is reducing European dependence on non-EU cloud and AI infrastructure. The Act does three things that matter to engineering teams.

First, it creates a Cloud Sovereignty Framework with four assurance levels. Every cloud provider offering services to EU public authorities must eventually certify at one of these levels. Second, it introduces procurement preferences for EU-developed technology, encouraging public bodies to favor providers that design hardware, software, or R&D within the EU. Third, it sets a capacity mandate — the EU aims to triple its data center capacity within five to seven years.

The regulation takes effect on August 4, 2026, but compliance deadlines are phased. Level 1 and Level 2 requirements kick in by February 2028. Level 3 and Level 4 — the strictest tiers — become mandatory by August 2029.

A new European Cloud and AI Agency will coordinate national regulators, develop technical standards, and enforce compliance. Penalties can reach a percentage of global annual turnover — a formula familiar to anyone who has tracked GDPR enforcement.

The Four Sovereignty Tiers, Decoded

The framework defines four progressively stricter assurance levels. Understanding them is essential for choosing the right deployment strategy.

Level 1 — Baseline. Data processing and storage must happen within EU infrastructure. Providers self-assess against baseline cybersecurity requirements. This is the minimum bar — think of it as table stakes for any public sector work in the EU.

Level 2 — Supply Chain Transparency. Providers must demonstrate independence from third-country jurisdictions and provide full transparency over their software supply chain. This means documenting where your dependencies come from and proving that no foreign government can compel data access through legal mechanisms like the US CLOUD Act or China's National Intelligence Law.

Level 3 — EU Ownership and Control. The provider must be owned and controlled from within the EU. Additional criteria include personnel citizenship requirements and operational control restrictions. This is where things get architecturally interesting — you cannot simply use a US hyperscaler with an EU region and call it compliant. The ownership structure itself must be European.

Level 4 — Full Sovereignty. Complete transparency and control over the entire software and hardware supply chain. No interference from any third country at any layer. Annual certification audits by a notified body under ENISA oversight. This tier is designed for the most sensitive government workloads, but it signals where the regulatory direction is heading for the broader market.

For most SaaS companies and development teams, Level 2 is the immediate practical target. Level 3 and Level 4 will initially apply to a narrow set of public sector contracts, but enterprises are already using the framework as a vendor evaluation rubric for private sector procurement too.

What Changes for Development Teams

CADA is not just a procurement policy. It creates architectural constraints that ripple through your entire stack. Here are the four areas where engineering teams will feel the impact first.

Data Residency Becomes Non-Negotiable

At every tier, data must be processed and stored within EU infrastructure. If your application sends telemetry to a US-based observability platform, queues jobs through a non-EU message broker, or backs up to a region outside Europe, you have a compliance gap. Audit every data flow — not just your primary database, but logging, caching, CDN, analytics, and third-party integrations.

This is more invasive than it sounds. Most modern applications rely on dozens of SaaS integrations, and many of those route data through US infrastructure by default. A single non-compliant analytics pixel or error-tracking SDK can invalidate your entire sovereignty posture.

Vendor Lock-In Risk Gets Regulatory Teeth

CADA explicitly encourages multi-cloud and multi-vendor strategies in public procurement. This means your architecture should avoid tight coupling to any single provider's proprietary services. If your deployment relies on AWS-specific constructs that have no equivalent on EU sovereign cloud providers like OVHcloud, Scaleway, or Deutsche Telekom's Open Telekom Cloud, you are building in a compliance liability.

The regulation also introduces "Union added value" as a procurement criterion, meaning public bodies must consider whether a provider's technology stack includes components designed or manufactured in the EU. This creates a tangible incentive to adopt open-source and provider-agnostic tooling wherever possible.

Supply Chain Documentation Is Mandatory

Level 2 and above require supply chain transparency. In practice, this means maintaining a software bill of materials that traces dependencies to their origin, documenting which third-party services process EU data and under which jurisdiction they operate, and proving that no foreign legal mechanism can compel access to customer data.

CI/CD Pipelines Need Sovereignty Awareness

Your deployment pipeline needs to enforce region constraints, vendor compliance, and data flow policies automatically. Manual compliance checks do not scale. Teams building for CADA should integrate policy-as-code tools like Open Policy Agent or Kyverno to validate deployments against sovereignty requirements before they reach production.

Architecture Patterns for CADA Compliance

Building cloud-sovereign software does not mean abandoning modern architecture. It means being deliberate about where you place trust boundaries.

Multi-Region, Multi-Provider Deployments

Design your infrastructure to run across multiple EU cloud providers. Use Kubernetes with a provider-agnostic abstraction layer, or invest in Terraform modules that target multiple backends. The goal is portability — if a provider loses its sovereignty certification or your compliance requirements change, you can migrate without rebuilding your entire stack.

Data Residency Enforcement at the Application Layer

Do not rely solely on cloud provider region settings. Build data residency into your application logic. Use encryption-at-rest with EU-managed keys, implement geo-fencing at the API gateway layer, and ensure that data processing — including AI inference — happens exclusively within EU boundaries. Every third-party SDK and analytics tool needs to be validated against these constraints.

Sovereign AI Inference

If your product uses AI models, CADA's highest tiers require that inference data never leaves the EU. This pushes teams toward self-hosted models or EU-based inference providers. Open-weight models like Llama and Mistral, deployed on EU infrastructure, become architecturally preferable to API calls to US-based model providers for sensitive workloads. The trend toward smaller, more efficient models makes self-hosting increasingly practical even for mid-sized teams.

Zero-Trust Supply Chain Verification

Implement automated dependency scanning that flags non-EU origins in your software supply chain. Combine SBOMs with runtime attestation to verify that deployed artifacts match audited builds. Tools like Sigstore, SLSA, and in-toto provide the provenance chain that sovereignty auditors will look for.

Abstracted Infrastructure Layers

Build an internal platform layer that abstracts cloud provider specifics from your application code. This is where custom software development discipline pays off — teams that invested in platform engineering can swap underlying providers without rewriting business logic. The cost of abstraction is small compared to the cost of a forced migration under regulatory pressure.

Timeline and What to Do Now

CADA's phased rollout gives engineering teams a clear window to prepare, but that window is shrinking.

Now through Q4 2026 — Audit your current infrastructure for EU data residency compliance. Map every service, integration, and data flow that touches EU customer data. Identify dependencies on non-EU providers that could create compliance gaps at Level 2.

Q1–Q2 2027 — Begin implementing multi-provider deployment capabilities. Evaluate EU-native cloud providers for workloads that require Level 3 or 4 compliance. Integrate policy-as-code enforcement into your CI/CD pipeline.

By February 2028 — Achieve Level 1 and Level 2 compliance for any product targeting EU public sector customers. Have supply chain documentation and data residency controls in production.

By August 2029 — If your roadmap includes Level 3 or Level 4 workloads, your infrastructure must be fully EU-owned and controlled, with complete supply chain transparency and third-party audit capability.

The companies that treat CADA as a checkbox exercise will scramble at each deadline. The ones that build sovereignty into their architecture from the start will turn compliance into a competitive advantage — especially in a market where EU public sector contracts are growing rapidly.

Start Building for Sovereignty

CADA is the clearest signal yet that cloud sovereignty is moving from geopolitical talking point to engineering requirement. For software companies serving EU customers — whether you are a startup entering the market or an enterprise renewing government contracts — the question is no longer whether to build sovereign infrastructure, but how quickly you can get there.

The good news is that sovereign architecture aligns with practices most high-performing teams already value: portability, transparency, security-by-design, and infrastructure-as-code. If your team has invested in modern cloud architecture, you are closer to compliance than you think.

Need help auditing your stack for CADA compliance or building a sovereign deployment pipeline? Get in touch — our cloud and DevOps team has been helping companies navigate EU regulatory requirements since the AI Act, and CADA is the next frontier.