Strategic Enterprise Data Engineering: The European 'Third Way'

1 Introduction: The Geopolitical Engineering Imperative

The digital infrastructure of the European Union (EU) exists in a state of profound tension. On one side lies the operational necessity of the American hyperscalers—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure—whose technological maturity, scalability, and ecosystem depth are currently unrivaled. On the other side stands the uncompromising normative framework of European jurisprudence, anchored by the General Data Protection Regulation (GDPR) and reinforced by the Court of Justice of the European Union (CJEU). This tension is not merely a legal compliance issue; it is a fundamental engineering challenge that defines the current era of enterprise IT in Europe.

Following the invalidation of the Privacy Shield framework in the Schrems II ruling, European enterprises face a stark choice. They can retreat to on-premises data centers, sacrificing agility and innovation for certainty, or they can navigate the treacherous waters of US cloud adoption under the constant threat of regulatory enforcement and extraterritorial surveillance. The "European Third Way"—a term increasingly used to describe a strategic path distinct from both US "surveillance capitalism" and Chinese state-control—rejects this binary.¹ It seeks to leverage the technical superiority of global cloud providers while mathematically enforcing European values of privacy and sovereignty.

This report articulates the engineering realization of this Third Way. It introduces the Adraca Framework, a rigorous reference architecture for "Sovereign Landing Zones" (SLZ). This framework does not rely on contractual promises, which the CJEU has deemed insufficient in the face of US national security laws. Instead, it relies on cryptographic and hardware-based controls—specifically External Key Management (EKM), Key Access Justifications (KAJ), and Confidential Computing—to transform legal sovereignty into technical reality. By treating legal constraints as non-negotiable system requirements, we can architect cloud environments where the cloud provider is reduced to a blind utility, providing raw compute and storage without the capability to access, index, or comprehend the data it processes.

2 The Post-Schrems II Reality: Analyzing the Legal-Technical Threat Landscape

The Schrems II decision (Case C-311/18) was a watershed moment not because it changed the law, but because it exposed the incompatibility of the internet's physical reality with Europe's legal expectations. To design a compliant architecture, one must first deconstruct the specific legal risks identified by the CJEU and translate them into threat models.

2.1 The Extraterritorial Reach of the US CLOUD Act

The primary antagonist in the Schrems II narrative is the potential for US intelligence agencies to access data stored by US companies, regardless of the data's physical location. This capability is codified in the Clarifying Lawful Overseas Use of Data Act (CLOUD Act) of 2018.

2.1.1 The Jurisdictional Conflict

The CLOUD Act amended the Stored Communications Act (SCA) to explicitly state that a service provider must comply with US obligations to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.⁴

This creates a direct conflict with GDPR Article 48 ("Transfers or disclosures not authorised by Union law"), which states that any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognized or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty (MLAT).⁵

2.1.2 FISA Section 702 and EO 12333

The Schrems II court focused heavily on Section 702 of the Foreign Intelligence Surveillance Act (FISA) and Executive Order 12333.

FISA 702 allows the US Attorney General and Director of National Intelligence to authorize surveillance targeting non-US persons located outside the US to acquire foreign intelligence information. The definition of "foreign intelligence" is broad, and the targets are not necessarily suspected of crimes.⁷

EO 12333 governs US intelligence activities and allows for the collection of transit data (upstream collection) as it moves across the internet backbone.⁷

For the cloud architect, the implication is severe: if a US cloud provider (or its EU subsidiary) retains the technical means to decrypt data (i.e., they hold the keys), they fall under the "possession, custody, or control" clause of the CLOUD Act. Consequently, they can be compelled to decrypt and hand over that data, and GDPR Article 48 prohibits them from doing so without an MLAT. The provider is trapped in a conflict of laws, and history suggests they will prioritize domestic (US) criminal liability over foreign (EU) civil liability.

2.2 GDPR Article 44 and the Definition of Transfer

GDPR Article 44 establishes the "General principle for transfers," stipulating that any transfer of personal data to a third country (like the US) must not undermine the level of protection guaranteed by the Regulation.⁹

The CJEU ruling clarified that a "transfer" is not merely the movement of bytes across a network border. It encompasses access. If a support engineer in Seattle can view the console output of a VM running in Frankfurt, a transfer has occurred. If the data is stored in Frankfurt but encrypted with keys held in a Key Management Service (KMS) that is logically controlled by US administrators, the data is considered accessible.¹¹

Therefore, reliance on Standard Contractual Clauses (SCCs) alone is insufficient for transfers to the US, because SCCs bind the companies but cannot bind the US government or its intelligence agencies.¹³

2.3 The Mandate for Supplementary Measures

The European Data Protection Board (EDPB), in its Recommendations 01/2020 on measures that supplement transfer tools 15, outlined the path forward. Where the law of a third country impinges on the effectiveness of Article 46 safeguards (like SCCs), the exporter must implement supplementary measures.

The EDPB identified three categories of measures:

Contractual Measures: Additional clauses binding the importer to challenge warrants (insufficient on their own against FISA 702).

Organizational Measures: Internal policies and transparency reports.

Technical Measures: The only category capable of preventing access by public authorities.

The EDPB explicitly stated that for Use Case 6 ("Transfer to cloud services providers or other processors which require access to data in the clear"), if the data is not encrypted in a way that the keys are retained solely by the data exporter, the transfer is unlawful.¹⁷

This sets the fundamental requirement for the Adraca Framework: The separation of data processing (Cloud Provider) from data access (Sovereignty Provider).

3 The Adraca Framework: A Reference Architecture for Sovereign Landing Zones

The Adraca Framework is a theoretical and practical reference architecture designed to satisfy the rigorous requirements of the "European Third Way." It operationalizes the EDPB’s supplementary measures into a deployable cloud stack. "Adraca" is agnostic to the underlying hyperscaler (GCP or Azure) but dictates a specific topology of control.

The framework consists of three concentric defense layers, each mitigating specific vectors of extraterritorial access.

3.1 Layer 1: The Cryptographic Core (Sovereign Keys)

The innermost layer protects data at rest and guarantees that the cloud provider never possesses the cleartext key material required to decrypt the data. This effectively removes the data from the provider's "control" in the context of a subpoena.

3.1.1 Beyond BYOK: The Necessity of External Key Management (EKM)

Traditional Bring Your Own Key (BYOK) mechanisms are insufficient for strict sovereignty. In a BYOK model, the customer generates a key (e.g., on an on-premises HSM) and imports it into the cloud provider's KMS. While the customer manages the lifecycle (rotation, deletion), the key material sits inside the cloud provider's HSM boundary during use. Technically, the provider could extract it or use it without the customer's real-time consent.¹⁸

The Adraca Framework mandates External Key Management (EKM) (often called Hold Your Own Key or HYOK).

Architecture: The master keys (Key Encryption Keys - KEKs) remain exclusively in an external Hardware Security Module (HSM) owned by the customer or a trusted European third party (e.g., Thales, Fortanix).

Operation: When the cloud service (e.g., Google BigQuery or Azure Storage) needs to decrypt a file, it sends the wrapped Data Encryption Key (DEK) to the external key manager via a secure API call. The external HSM unwraps the DEK and returns it—or performs the cryptographic operation itself—without ever exposing the KEK to the cloud provider.²¹

Sovereignty Assertion: Because the cloud provider does not have the KEK, they cannot decrypt the data at rest without the active participation of the external system. If the link to the external system is severed, the data becomes cryptographic noise.²²

3.1.2 Key Access Justifications (KAJ) as a Kill Switch

Mere EKM is not enough; one must control why a key is being used. This is where Key Access Justifications (KAJ) become the "killer feature" of the Sovereign stack (currently most mature on GCP).

Mechanism: Every time the cloud provider requests a decryption operation from the external HSM, the request must include a signed justification code (e.g., "CUSTOMER_INITIATED_ACCESS", "SYSTEM_MAINTENANCE", "THIRD_PARTY_DATA_REQUEST").²¹

Policy Enforcement: The external HSM is configured with an automated policy engine. It acts as a firewall for key usage.

Rule 1: If Justification == "CUSTOMER_INITIATED_ACCESS" -> ALLOW.

Rule 2: If Justification == "THIRD_PARTY_DATA_REQUEST" (i.e., a US warrant) -> DENY.²⁵

Result: This creates a technical impossibility for the cloud provider to comply with a CLOUD Act warrant. Even if legally compelled, the provider's systems will be technically blocked from decrypting the data by the customer's external infrastructure.

3.2 Layer 2: The Trusted Execution Layer (Confidential Computing)

While EKM protects data at rest, data must inevitably be decrypted in Random Access Memory (RAM) to be processed by CPUs. In a standard virtualization model, the hypervisor (managed by the cloud provider) has access to the memory space of the guest VM. This "data-in-use" vulnerability is the final frontier of cloud sovereignty.

The Adraca Framework addresses this via Confidential Computing.

3.2.1 Hardware-Rooted Isolation

Confidential Computing utilizes Trusted Execution Environments (TEEs) provided by modern silicon (AMD EPYC and Intel Xeon).

AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging): This technology encrypts the memory of the Virtual Machine with a unique key generated by the on-die AMD Secure Processor. The key is never exposed to the hypervisor or the host operating system. SEV-SNP adds integrity protection, preventing the hypervisor from replaying or remapping memory to corrupt the guest.²⁷

Intel TDX (Trust Domain Extensions): Intel's approach creates "Trust Domains" (TDs) that are hardware-isolated from the Virtual Machine Monitor (VMM) and other software on the platform.²⁹

3.2.2 The Attestation Workflow

Crucially, Confidential Computing includes Remote Attestation. Before the customer's external key manager releases any keys to the VM, the VM must prove it is running genuine hardware and a verified software stack.

The VM boots and generates a quote signed by the hardware root of trust (TPM/vTPM).

This quote is sent to the external key manager (Layer 1).

The key manager verifies the quote. Only if the quote proves the workload is running in a secure, encrypted TEE (and not a compromised emulator) will the key manager release the keys.³⁰

This closes the loop: Data is encrypted at rest (EKM) and encrypted in use (Confidential Computing), with the keys only released to a verified environment that the cloud provider cannot inspect.

3.3 Layer 3: The Policy Perimeter (Sovereign Landing Zones)

The final layer is the Sovereign Landing Zone (SLZ)—the operational configuration that enforces the usage of the previous two layers.

3.3.1 Data Residency Guardrails

Policy-as-Code (e.g., Azure Policy, Google Organization Policy) is used to strictly pin resources to specific EU regions (e.g., europe-west3 Frankfurt, europe-west4 Eemshaven).

Organization Policy Constraints: Administrators configure policies that deny the creation of any resource outside of the allowed list of regions. This prevents "shadow IT" or accidental deployments to US regions.³²

Disaster Recovery (DR) Implications: The SLZ architecture explicitly accepts lower availability in exchange for sovereignty. Global geo-redundancy is disabled; failover can only occur between paired EU regions (e.g., Frankfurt and Paris).

3.3.2 Operational Sovereignty and Support Access

A critical vector for data leakage is technical support. If a cloud provider's support engineer needs to debug an issue, they often request access to the environment.

Personnel Restrictions: Services like Google Assured Workloads and Microsoft Cloud for Sovereignty implement "US Person" restrictions or "EU-only" support queues. Access is restricted to support personnel physically located in the EU and subject to background checks.³⁵

Transparency Logs: All administrative access by the provider is logged in near real-time. These logs are immutable and can be exported to the customer's external SIEM, ensuring complete auditability of the provider's actions.³⁷

4 Implementation Strategies: Google Cloud Platform vs. Microsoft Azure

The abstract principles of the Adraca Framework must be instantiated using the specific product capabilities of the hyperscalers. Both Google and Microsoft have aggressively developed "Sovereign" portfolios to capture the European regulated market.

4.1 Google Cloud Platform: Assured Workloads and EKM

GCP is currently unique in offering the granular Key Access Justifications (KAJ) feature, which arguably provides the strongest technical defense against the CLOUD Act.

4.1.1 Architecture Components

Assured Workloads: This service creates a "Folder" in the GCP resource hierarchy that acts as a compliance boundary. It pre-configures Organization Policies for IL4, CJIS, or EU Sovereignty requirements. It restricts resource locations and enforces the use of compliant products.³⁵

Cloud EKM: GCP's EKM service connects to external key managers via Cloud VPN or Cloud Interconnect, ensuring key material never traverses the public internet. It supports Thales, Fortanix, and other EKMs.²²

Confidential Space: A specialized TEE environment designed for multi-party computation where data remains encrypted even from the workload owner until specific conditions are met.³⁹

4.1.2 The "Kill Switch" Workflow

The implementation of the KAJ "Kill Switch" on GCP is as follows:

Event: A US court issues a warrant for data stored in a GCP bucket in Belgium.

Attempt: Google engineers attempt to access the data. The system generates a decryption request to the customer's external HSM.

Justification: The request includes the code THIRD_PARTY_DATA_REQUEST.²⁵

Denial: The customer's Thales CipherTrust Manager policy evaluates the code. Seeing a prohibited justification, it denies the unwrap request.

Outcome: The Google engineer receives an error. The data remains encrypted. Google can truthfully testify to the court that they are technically unable to provide the data.²¹

4.1.3 Limitations

Service Compatibility: Not all GCP services support EKM or KAJ. While core services like Compute Engine, BigQuery, and Cloud Storage are supported, newer or specialized AI services (like some Vertex AI features) may not be.⁴⁰

Latency: The round-trip time (RTT) to the external HSM adds latency to every key operation. GCP attempts to mitigate this with key caching, but strict sovereignty policies may reduce cache times, impacting performance.²²

4.2 Microsoft Azure: Cloud for Sovereignty and Managed HSM

Microsoft’s strategy focuses on the "Microsoft Cloud for Sovereignty," a solution accelerator that combines Sovereign Landing Zones (SLZ) with Azure Confidential Computing.

4.2.1 Architecture Components

Sovereign Landing Zone (SLZ): An enterprise-scale architecture deployed via GitHub/Terraform. It organizes subscriptions into Management Groups with assigned Azure Policies to enforce the "Azure Sovereignty Baseline" (e.g., restricting regions, enforcing managed identity).⁴²

Azure Managed HSM: Unlike GCP's emphasis on external EKMs, Microsoft pushes Managed HSM. This is a FIPS 140-2 Level 3 validated HSM fleet that is single-tenant. Crucially, it uses a Security Domain that is downloaded by the customer. Microsoft claims that without this Security Domain key, they cannot reconstruct the keys to access the HSM, even though the hardware sits in their data center.⁴⁵

Confidential VMs: Azure has a broad portfolio of confidential options, including DCasv5/ECasv5 (AMD SEV-SNP) and DCesv5 (Intel TDX). They also offer Confidential Containers on AKS.⁴⁷

4.2.2 Double Key Encryption (DKE)

For customers who do not trust Managed HSM (since it is still physically possessed by Microsoft), Azure offers Double Key Encryption (DKE) for Microsoft 365 and some Azure services.

Mechanism: Data is encrypted with two keys. One key is in Azure Key Vault (Microsoft controlled). The second key is held by the customer (on-premises or EKM).

Sovereignty: Microsoft cannot decrypt the data because they only have one of the two keys. This provides a stronger guarantee than Managed HSM but often comes with significant functional limitations (e.g., loss of search, indexing, and co-authoring features in M365).⁴⁹

5 Comparative Analysis: Cloud Native vs. Cloud Sovereign

The transition to a Sovereign architecture is not free. It imposes costs in performance, finance, and complexity. The following table contrasts a standard "Cloud Native" architecture with the "Cloud Sovereign" Adraca implementation.

5.1 Architecture Comparison Table

6 The European Ecosystem: Gaia-X and the Data Governance Act

The "European Third Way" is not merely defensive; it is constructive. The Adraca Framework is designed to integrate with the emerging federated data ecosystem championed by the EU, specifically through the Data Governance Act (DGA) and the Gaia-X initiative.

6.1 The Data Governance Act: Institutionalizing Intermediaries

The DGA introduces a novel regulatory entity: the Data Intermediation Service (defined in Article 2(11) and regulated under Article 10).⁵³

Definition: These are neutral third parties that facilitate data sharing between data holders and data users. They are strictly prohibited from using the data for their own purposes (e.g., analytics, advertising), breaking the business model of traditional tech giants.⁵⁵

Engineering Relevance: A Sovereign Landing Zone should be architected to act as a secure "Data Pod" that connects to these Intermediaries. The strict egress controls and EKM ensure that when data is shared via a DGA-compliant intermediary, the data holder retains cryptographic control (revocation rights) even after the data has left their immediate infrastructure.

6.2 Gaia-X: The Federated Trust Layer

Gaia-X is the technical realization of the European data strategy. It is not a competitor to AWS or Azure, but a federated software layer that connects various cloud providers into a cohesive ecosystem based on European values.⁵⁶

6.2.1 The Gaia-X Federation Services (GXFS)

To participate in Gaia-X, a Sovereign Landing Zone must implement specific Federation Services 57:

Identity & Trust: The SLZ must support decentralized identity using Verifiable Credentials (VCs). Instead of a username/password, the infrastructure presents a VC signed by a Trust Anchor proving it is compliant.⁵⁹

Federated Catalogue: The SLZ publishes Self-Descriptions (SDs). These are machine-readable files (JSON-LD) that describe the node’s capabilities.

Example SD: "This node is located in europe-west3, runs AMD SEV-SNP, utilizes Thales EKM, and is compliant with GDPR Art 44".⁶⁰

Sovereign Data Exchange: Using Data Contract Services, the SLZ enforces usage policies. For example, a dataset might be shared with a policy that says "Compute allowed only in TEEs." The Adraca Framework's Confidential Computing layer provides the technical guarantee to satisfy this contract.⁵⁸

6.2.2 The SLZ as a Gaia-X Node

By implementing the Adraca Framework, an enterprise effectively transforms its Azure or GCP tenant into a valid Gaia-X Node. The Confidential Computing layer provides the "Technical Trust" required to join the federation, allowing the enterprise to participate in European Data Spaces (e.g., Catena-X for automotive) securely.⁶⁰

7 Conclusion: Engineering as Strategy

The geopolitical divergence between the US and the EU regarding data privacy is unlikely to resolve in the near term. The Schrems II ruling and the CLOUD Act represent fundamental differences in how each jurisdiction balances national security against individual rights. For the European enterprise, waiting for a new political agreement (like the Data Privacy Framework) is a strategy of hope, not engineering.

The Adraca Framework offers a deterministic path forward. By layering External Key Management, Key Access Justifications, and Confidential Computing on top of US hyperscale infrastructure, we can achieve the "European Third Way." This approach allows Europe to benefit from the immense R&D investment of American tech giants without capitulating to American surveillance law.

Recommendations for the Enterprise Architect:

Adopt a "Verify then Trust" Posture: Move from contractual compliance (trusting the provider's legal team) to technical compliance (verifying the provider's inability to access data via TEE attestation and EKM logs).

Implement Sovereign Landing Zones Default: New workloads should land in SLZ-configured subscriptions/folders by default. Retrofitting sovereignty onto legacy "open" environments is costly and complex.

Prepare for Federation: Design data architectures to be compatible with Gaia-X Self-Descriptions and DGA Intermediaries. The future of European data is federated, and the Sovereign Landing Zone is the fundamental building block of that future.

In the Post-Schrems II era, data sovereignty is no longer a legal checkbox; it is a rigorous engineering discipline. The tools exist. The legal mandate is clear. The "Third Way" is open for those willing to engineer it.

Works cited

BUILDING DATA BRIDGES Why Data Ecosystems Can Be the Next Public Infrastructure - Capgemini, accessed January 27, 2026, https://www.capgemini.com/wp-content/uploads/2022/01/Building-Data-Bridges.pdf

The Rise of European Data (2022). Francesco Vogelezang - The Datasphere Initiative, accessed January 27, 2026, https://www.thedatasphere.org/wp-content/uploads/2023/05/The-Rise-of-European-Data-2022.-Francesco-Vogelezang.pdf

Digital Sovereignty - The EU in a Contest for Influence and Leadership, accessed January 27, 2026, https://eu.boell.org/en/2021/02/15/digital-sovereignty-eu-contest-influence-and-leadership

CLOUD Act - What It Means for EU Data Sovereignty - Wire, accessed January 27, 2026, https://wire.com/en/blog/cloud-act-eu-data-sovereignty

CLOUD Act vs. GDPR: The Conflict About Data Access Explained – - Exoscale, accessed January 27, 2026, https://www.exoscale.com/blog/cloudact-vs-gdpr/

Mitigating the risk of US surveillance for public sector services in the cloud, accessed January 27, 2026, https://policyreview.info/articles/analysis/mitigating-risk-us-surveillance-public-sector-services-cloud

EU Data Transfer Requirements and U.S. Intelligence Laws: Understanding Schrems II and Its Impact on the EU-U.S. Privacy Shield | Congress.gov, accessed January 27, 2026, https://www.congress.gov/crs-product/R46724

The Court of Justice of the European Union in Schrems II: The impact of GDPR on data flows and national security - Brookings Institution, accessed January 27, 2026, https://www.brookings.edu/articles/the-court-of-justice-of-the-european-union-in-schrems-ii-the-impact-of-gdpr-on-data-flows-and-national-security/

Cross-Border Data Transfers Between the EU and the U.S.: A Transatlantic Dispute - Santa Clara Law Digital Commons, accessed January 27, 2026, https://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1242&context=scujil

Article 44. - Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (United Kingdom General Data Protection Regulation) (Text with EEA relevance), accessed January 27, 2026, https://www.legislation.gov.uk/eur/2016/679/article/44

third country problem under the GDPR: enhancing protection of data transfers with technology - Oxford Academic, accessed January 27, 2026, https://academic.oup.com/idpl/article/13/3/225/7226249

EDPB Releases Final Recommendations on Supplementary Measures for International Transfers - Hunton Andrews Kurth LLP, accessed January 27, 2026, https://www.hunton.com/privacy-and-information-security-law/edpb-releases-final-recommendations-on-supplementary-measures-for-international-transfers

How the Schrems II Decision Changed Privacy Law - TrustArc, accessed January 27, 2026, https://trustarc.com/resource/schrems-ii-decision-changed-privacy-law/

The CJEU judgment in the Schrems II case - European Parliament, accessed January 27, 2026, https://www.europarl.europa.eu/RegData/etudes/ATAG/2020/652073/EPRS_ATA(2020)652073_EN.pdf

Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, accessed January 27, 2026, https://www.edpb.europa.eu/sites/default/files/consultation/edpb_recommendations_202001_supplementarymeasurestransferstools_en.pdf

Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data Version 2.0, accessed January 27, 2026, https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf

Cloud Neutral Access Security Compliance Post Schrems II - Thales CPL, accessed January 27, 2026, https://cpl.thalesgroup.com/blog/identity-data-protection/access-security-compliance-post-schrems-ii

Overview of Key Management in Azure | Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/security/fundamentals/key-management

Bring Your Own Key Encryption (BYOK) - Entro Security, accessed January 27, 2026, https://entro.security/glossary/bring-your-own-key-encryption-byok/

Demystifying AWS KMS key operations, bring your own key (BYOK), custom key store, and ciphertext portability | AWS Security Blog, accessed January 27, 2026, https://aws.amazon.com/blogs/security/demystifying-kms-keys-operations-bring-your-own-key-byok-custom-key-store-and-ciphertext-portability/

Cloud Key Management | Google Cloud, accessed January 27, 2026, https://cloud.google.com/security/products/security-key-management

Protecting data with Google Cloud External Key Manager, accessed January 27, 2026, https://services.google.com/fh/files/misc/protecting_data_with_googlecloud_ekm.pdf

Google Cloud External Key Manager Resources - Thales Documentation Portal, accessed January 27, 2026, https://docs-cybersec.thalesgroup.com/bundle/v2.21-cdsp-cm/page/admin/cckm_ag/ekm/index.html

How Key Access Justifications lets you be the ultimate arbiter of access to their data on Google Cloud Platform (GCP), accessed January 27, 2026, https://cloud.google.com/blog/products/identity-security/control-access-to-gcp-data-with-key-access-justifications

Justification reason codes | Key Access Justifications - Google Cloud Documentation, accessed January 27, 2026, https://docs.cloud.google.com/assured-workloads/key-access-justifications/docs/justification-codes

Privileged access in Google Cloud | Security, accessed January 27, 2026, https://docs.cloud.google.com/docs/security/privileged-access-management

AMD EPYC™ Processors Deliver Confidential Computing for Public and Private Cloud Environments, accessed January 27, 2026, https://www.amd.com/en/blogs/2022/amd-epyc-processors-deliver-confidential.html

Confidential virtual machines versus VMs: Latency analysis | Red Hat Developer, accessed January 27, 2026, https://developers.redhat.com/articles/2025/07/28/confidential-virtual-machines-versus-vms-latency-analysis

Confidential VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX - Systems Research Group, accessed January 27, 2026, https://dse.in.tum.de/wp-content/uploads/2024/11/sigmetrics25summer-CVM-Explained.pdf

What is confidential computing? Definition + use cases - Decentriq, accessed January 27, 2026, https://www.decentriq.com/article/what-is-confidential-computing

Microsoft Cloud for Sovereignty - Part 6 - Confidential VM, accessed January 27, 2026, https://sovereign-cloud.nl/posts/mcfs-cvm-2024-06-29/

Microsoft strengthens sovereign cloud capabilities with new services | Microsoft Azure Blog, accessed January 27, 2026, https://azure.microsoft.com/en-us/blog/microsoft-strengthens-sovereign-cloud-capabilities-with-new-services/

AWS vs. Azure vs. GCP: An Executive Comparison and Decision Matrix - BairesDev, accessed January 27, 2026, https://www.bairesdev.com/blog/aws-vs-azure-vs-gcp/

EU Data Boundary with Access Justifications | Assured Workloads | Google Cloud Documentation, accessed January 27, 2026, https://docs.cloud.google.com/assured-workloads/docs/control-packages/eu-data-boundary-access-justifications

Data Boundary via Assured Workloads | Sovereign Cloud, accessed January 27, 2026, https://cloud.google.com/security/products/assured-workloads

CCN-CERT BP31 Data Protection in The Cloud Digital Sovereignty | PDF - Scribd, accessed January 27, 2026, https://www.scribd.com/document/969145140/CCN-CERT-BP31-Data-Protection-in-the-Cloud-Digital-Sovereignty

Microsoft announces new European digital commitments - Microsoft On the Issues, accessed January 27, 2026, https://blogs.microsoft.com/on-the-issues/2025/04/30/european-digital-commitments/

Assured Workloads documentation - Google Cloud Documentation, accessed January 27, 2026, https://docs.cloud.google.com/assured-workloads/docs

Confidential computing for data analytics, AI, and federated learning | Cloud Architecture Center, accessed January 27, 2026, https://docs.cloud.google.com/architecture/security/confidential-computing-analytics-ai

Cloud External Key Manager - Google Cloud Documentation, accessed January 27, 2026, https://docs.cloud.google.com/kms/docs/ekm

Scope of Data Boundary by Partners Solutions - Google Cloud, accessed January 27, 2026, https://cloud.google.com/terms/in-scope-sovereign-cloud

Deploy Azure Landing Zones - Azure Architecture Center | Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy

sovereign-landing-zone/docs/01-Overview.md at main - GitHub, accessed January 27, 2026, https://github.com/Azure/sovereign-landing-zone/blob/main/docs/01-Overview.md

Microsoft Cloud for Sovereignty - Sovereign guardrails, accessed January 27, 2026, https://learn.microsoft.com/en-us/industry/release-plan/2025wave1/cloud-sovereignty/sovereign-guardrails-guidance

How to generate and transfer HSM-protected keys for Azure Key Vault Managed HSM, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/hsm-protected-keys-byok

Azure Key Vault vs Managed HSM: Key Differences | Hokstad Consulting, accessed January 27, 2026, https://hokstadconsulting.com/blog/azure-key-vault-vs-managed-hsm-key-differences

Azure Confidential Computing Products | Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/confidential-computing/overview-azure-products

Azure Confidential VM options | Microsoft Learn, accessed January 27, 2026, https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-options

Microsoft cloud security benchmark v2 - Data Protection, accessed January 27, 2026, https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-data-protection

Generational Performance Leap for Azure Confidential Computing, accessed January 27, 2026, https://techcommunity.microsoft.com/blog/azureconfidentialcomputingblog/generational-performance-leap-for-azure-confidential-computing/4468989

Performance Impact of Enabling Confidential Computing on Oracle Cloud Infrastructure VMs, accessed January 27, 2026, https://blogs.oracle.com/cloud-infrastructure/perf-impact-of-confidential-computing-on-oci-vms

Azure Confidential VMs - Cloud Security - Medium, accessed January 27, 2026, https://medium.com/cloud-security/azure-confidential-vms-fb820899885a

Article 10, Data intermediation services, the Data Governance Act (DGA), accessed January 27, 2026, https://www.european-data-governance-act.com/Data_Governance_Act_Article_10.html

Article 2, Definitions, the Data Governance Act (DGA), accessed January 27, 2026, https://www.european-data-governance-act.com/Data_Governance_Act_Article_2.html

Data Governance Act explained | Shaping Europe's digital future - European Union, accessed January 27, 2026, https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained

GAIA-X: Technical Architecture - bundeswirtschaftsministerium.de, accessed January 27, 2026, https://www.bundeswirtschaftsministerium.de/Redaktion/EN/Publikationen/gaia-x-technical-architecture.pdf?__blob=publicationFile&v=1

Overview - Gaia-X Architecture Document - 22.10 Release, accessed January 27, 2026, https://docs.gaia-x.eu/technical-committee/architecture-document/22.10/overview/

Specification Phase 1 - GXFS.eu, accessed January 27, 2026, https://www.gxfs.eu/specification-phase-1/

Enabling Services - Gaia-X Architecture Document - 24.04 Release, accessed January 27, 2026, https://docs.gaia-x.eu/technical-committee/architecture-document/24.04/enabling_services/

Gaia-x - Architecture Document - 22.04 Release, accessed January 27, 2026, https://gaia-x.eu/wp-content/uploads/2022/06/Gaia-x-Architecture-Document-22.04-Release.pdf