Encryption is a foundational technical control for cloud sovereignty, but under the proposed Cloud and AI Development Act (CADA), it would not be sufficient on its own to guarantee sovereignty. While encryption protects data confidentiality in transit and at rest, the proposal frames sovereignty more broadly to include operational autonomy, legal jurisdiction, and the prevention of third-country access to infrastructure and personnel. As a result, customer-held keys and confidential computing are valuable risk-mitigation tools, but they would not automatically satisfy the criteria for the higher Union assurance levels (2, 3 and 4), which would require strict controls over where data is processed, who handles it, and how the service is governed.

Detail

The proposed CADA would establish a "Union cloud computing sovereignty framework" comprising four Union assurance levels (Article 16), with the detailed criteria set out in Annex II. Understanding the role of encryption within this framework requires distinguishing between data protection (keeping data secret) and sovereignty (maintaining control over the whole service lifecycle, including operations, personnel and legal jurisdiction).

Encryption as a baseline, not a silver bullet

Under CADA as proposed, all four levels would require the service to comply with state-of-the-art cybersecurity standards (Annex II, point 1.1(e)); encryption is a normal part of meeting that bar. However, the proposal treats sovereignty risks as going well beyond confidentiality.

Recital 50 of the proposal identifies the risks of dependence on third-country-controlled providers, including "misuse (i.e. manipulation, remote access and control, sabotage, weaponisation)" and "access to information (i.e. access to sensitive information, unauthorised communication, technology leakage, data manipulation or exfiltration, espionage)". Encryption with securely held keys can mitigate some "access to information" risks, but it does not prevent remote access to and control of the underlying infrastructure, nor does it stop a third-country government from compelling a provider to degrade or disrupt the service.

CADA would therefore treat encryption as a necessary hygiene factor, not a standalone proxy for sovereignty. A service can be fully encrypted yet still fail the higher assurance levels if the provider is subject to third-country laws that allow operational disruption, or if the personnel and infrastructure do not meet the location and control criteria.

Customer-held keys (BYOK / HYOK)

Customer-held keys — "Bring Your Own Key" (BYOK) or "Hold Your Own Key" (HYOK) — let the customer retain control over the cryptographic keys used to encrypt their data. This is a strong tool for data confidentiality, which is one input to the risk assessments that determine the required assurance level (Article 29).

By holding the keys, a public sector body reduces the chance that the provider can access plaintext, even if the provider is compromised or compelled by a third-country law to disclose data. This addresses the "access to information" risks in Recital 50.

But the assurance-level criteria go further. For example, to meet Union assurance level 2, the audited provider and its subcontractors must be established in the Union (Annex II, point 2.1(a)) and the infrastructure, assets and personnel must be located in the Union (point 2.1(b)); and where the provider is subject to third-country control, it must demonstrate legal, technical and organisational measures preventing third-country access to customer data and disruption or degradation of the service (point 2.1(g)).

If a customer holds the keys but the provider is a non-EU entity with infrastructure outside the Union, the service would still fail these criteria regardless of the key-management model. And if the key-management service itself sits outside the Union or with a third-country entity, the sovereignty chain breaks. Customer-held keys would therefore need to be implemented within a provider that already meets the foundational criteria (establishment, location and control) to count under CADA.

Confidential computing

Confidential computing extends encryption to data in use, using hardware-based Trusted Execution Environments (TEEs) so that even the provider's hypervisor or operating system cannot read plaintext during computation. For architects, this mitigates insider risk and provider-side access, which supports CADA's broader objective of operational autonomy.

Under CADA as proposed, confidential computing could support the stricter criteria:

  • Union assurance level 2: data generated by the service must not be used to train or fine-tune AI systems operated by a third country and must not be transferred outside the Union (Annex II, point 2.1(f)). Confidential computing helps ensure data does not leak into the provider's broader infrastructure.
  • Union assurance levels 3 and 4: personnel involved in providing the service must be Union citizens (Annex II, points 3.1(d) and 4.1(d)), and technical and operational support must be initiated and performed exclusively within the Union by Union-resident personnel not subject to third-country control (points 3.1(h) and 4.1(h)).

Confidential computing protects the data, but it does not by itself satisfy the personnel or jurisdictional requirements. If the TEE hardware or its security-relevant software components are controlled by a third-country entity, the software-supply-chain and control criteria (Annex II, points 2.1(i)/3.1(i)/4.1(i) and the third-country-control criteria (g)) may still bite. Architects must therefore evaluate the whole supply chain of the confidential-computing stack, not just the encryption.

The role of risk assessments (Article 29)

Article 29 would require Member States and Union entities to conduct risk assessments to determine the appropriate Union assurance level for relevant public sector activities. Encryption strategies, including BYOK and confidential computing, would be weighed as mitigation measures. The assessment must consider at least: the sensitivity, criticality and magnitude of the data (Article 29(2)(a)); the risk of unlawful access by a third country (Article 29(2)(b)); and the risk of service disruption (Article 29(2)(c)).

Where high-sensitivity activities (for example in defence or national security) are involved, the methodology must steer the most critical activities — including, but not limited to, defence — to the highest assurance levels (Article 29(3)). In those cases encryption alone would not be enough; the provider would also need to show, as a legal and operational matter, that no third country can compel disruption of the service or access to the infrastructure.

What this means for you

For CTOs, architects and SMEs evaluating providers under the proposed framework:

  1. Audit your encryption strategy. Apply encryption end-to-end — at rest, in transit and, where feasible, in use. Verify that key-management systems are hosted in the Union and operated by personnel subject to Union law.
  2. Evaluate the provider's sovereignty profile. "EU region" data centres are not enough. Check whether the provider is established in the Union, whether it is subject to third-country control, and whether its subcontractors meet the same criteria (Annex II).
  3. Use confidential computing for high-risk workloads. For activities pointing to Union assurance level 2 or higher, confidential computing can be useful evidence in your Article 29 risk assessment that data is protected even from the provider's own infrastructure.
  4. Prepare for risk assessments and audits. Document data flows, key-management practices and provider dependencies. Levels 2–4 would require an independent third-party audit (Article 20), not a self-assessment.
  5. Consider multi-cloud. Article 29(9) would require risk assessments to consider whether a multi-vendor or multi-cloud strategy is appropriate, which can reduce single-provider dependence.

Common misconceptions

  • "If my data is encrypted, it is sovereign." Encryption protects confidentiality, not operational autonomy. A third-country-controlled provider could still disrupt or degrade the service, even with the payload encrypted. CADA as proposed would require control over the whole service lifecycle.
  • "Customer-held keys solve all sovereignty problems." Keys stop the provider reading your data, but do not stop a third-country law from compelling the provider to disrupt the service. The higher levels also require that the provider is not improperly subject to such control (Annex II, points 2.1(g), 3.1(g), 4.1(g)).
  • "Confidential computing makes any provider sovereign." It protects data in use, but does not address the provider's jurisdiction, the location and citizenship of personnel, or supply-chain control over the hardware and software.
  • "Union assurance level 1 is the same as GDPR compliance." GDPR addresses data protection; CADA's assurance levels address sovereignty, operational autonomy and resilience. A service can be GDPR-compliant yet fail level 1 if it does not meet the establishment, location, data-residency and control criteria (Annex II, point 1.1).

Official sources

Related

This is general information about a draft EU regulation, not legal advice.