EU Data Act (Regulation (EU) 2023/2854)¶
Framework Overview¶
Full name: Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (EU Data Act) Entered into force: 11 January 2024 Applicable from: 12 September 2025 Type: EU Regulation (directly applicable in all Member States)
The EU Data Act establishes rules for data sharing, cloud switching, data portability, and safeguards against unlawful international government access to non-personal data. It is a broad regulation covering IoT data access, B2B data sharing, cloud service switching, and international data protection.
Who Must Comply¶
- Cloud service providers (IaaS, PaaS, SaaS) operating in the EU
- Customers of cloud services (data holders and users)
- Manufacturers of connected products (IoT)
- Entities involved in B2B data sharing
Structure¶
The Data Act contains 11 chapters. The most relevant to CloudTaser are:
- Chapter III (Articles 8-12): B2B data sharing obligations
- Chapter VI (Articles 23-31): Cloud switching and data portability
- Chapter VII (Articles 32-34): Safeguards against unlawful international government access
Chapter III -- B2B Data Sharing¶
Articles 8-12 establish rules for making data generated by connected products available to third parties. While primarily focused on IoT data, the principles apply to any data sharing arrangement where cryptographic protection is needed.
| Data Act Requirement | Article | CloudTaser Mapping | Component |
|---|---|---|---|
| Data made available must be protected against unauthorized access | Art. 8(6) | CloudTaser ensures shared data encryption keys are held in EU-hosted vault. Keys injected into process memory via memfd_secret are invisible to the cloud provider |
Wrapper |
| Trade secret protection during data sharing | Art. 8(6), Art. 11 | Encryption keys protecting trade secrets remain in EU vault. Even if shared data traverses US cloud infrastructure, the keys are inaccessible to the provider | Wrapper, S3 Proxy |
| Technical measures to preserve data integrity | Art. 8(6) | S3 proxy provides client-side AES-256-GCM encryption with integrity verification. DB proxy provides transparent encryption for database records | S3 Proxy, DB Proxy |
Chapter VI -- Cloud Switching and Data Portability¶
Articles 23-31 require cloud providers to eliminate barriers to switching between providers and ensure data portability. CloudTaser directly supports these requirements by decoupling secret management from the cloud provider.
| Data Act Requirement | Article | CloudTaser Mapping | Component |
|---|---|---|---|
| Remove barriers to switching | Art. 23 | CloudTaser stores secrets in a portable EU vault (OpenBao/Vault), not in the cloud provider's secret management service (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). Switching providers does not require re-engineering secret management | Wrapper, Operator |
| Functional equivalence during transition | Art. 23(1)(b) | CloudTaser works identically across AWS, GCP, and Azure. The same vault configuration, annotations, and eBPF policies apply on any Kubernetes distribution | Operator |
| Data portability | Art. 24 | Secrets and encryption keys are in a standard vault (OpenBao/Vault) format, not locked to any provider's proprietary format. Export and import use standard vault CLI tools | Wrapper |
| Gradual reduction of switching charges | Art. 29 | CloudTaser has no switching charges. The vault is customer-owned and customer-operated. Moving to a new cloud provider requires only redeploying the CloudTaser operator and wrapper on the new cluster | Operator |
| Interoperability and open standards | Art. 30 | CloudTaser uses standard Kubernetes APIs (admission webhooks, ServiceAccounts, RBAC). The vault uses the standard Vault/OpenBao API. No proprietary protocols | Operator, Wrapper |
How CloudTaser Enables Cloud Switching¶
-
Before CloudTaser: Secrets are stored in the cloud provider's native secret management service. Switching providers requires migrating all secrets, updating all application configurations, and re-implementing access controls. This creates vendor lock-in.
-
With CloudTaser: Secrets are stored in a portable EU vault. The cloud provider's infrastructure runs the workloads, but has no access to secrets. Switching providers means:
- Deploy CloudTaser operator on the new cluster
- Point the wrapper at the same EU vault
- Workloads resume with the same secrets, same access policies, same eBPF enforcement
- No secret migration required
Chapter VII -- Safeguards Against Unlawful International Government Access¶
Articles 32-34 are the most directly relevant to CloudTaser. They require cloud providers to implement technical, legal, and organizational measures to prevent non-EU government access to data held in the EU that would conflict with EU or Member State law.
Article 32 -- International Governmental Access and Transfer¶
| Data Act Requirement | CloudTaser Mapping | Component |
|---|---|---|
| Take all adequate technical measures to prevent non-EU government access that conflicts with EU law | CloudTaser's entire architecture is designed for this purpose. memfd_secret makes secrets invisible to the cloud provider. eBPF blocks all memory access vectors. Secrets never touch persistent storage |
Wrapper, eBPF |
| Take all adequate organizational measures | CloudTaser supplements organizational measures with technical enforcement. Even if organizational controls fail (e.g., the provider is compelled by US law), the technical controls prevent access | All |
| Publish description of technical measures on website | cloudtaser audit generates detailed reports of active protection measures. These reports document the technical safeguards in place |
CLI |
Article 32 -- Specific Technical Measures¶
CloudTaser implements the following technical measures that address Article 32's requirements:
| Threat Vector | CloudTaser Measure | How It Prevents Access |
|---|---|---|
| Cloud provider reads secrets from storage | Secrets never touch etcd, Kubernetes Secrets, disk, or swap | Nothing to read -- secrets exist only in volatile process memory |
| Cloud provider reads secrets from memory | memfd_secret (kernel 5.14+) removes pages from kernel direct map |
Kernel, hypervisor, and /dev/mem cannot see the pages |
Cloud provider uses ptrace to extract secrets |
eBPF blocks ptrace attach/seize on protected processes |
System call denied before execution |
Cloud provider reads /proc/pid/mem |
eBPF blocks /proc/pid/mem and /proc/pid/environ reads by external processes |
File access denied |
| Cloud provider loads kernel module for memory access | eBPF detects and logs kernel module loading events. memfd_secret pages are invisible even to kernel modules |
Defense-in-depth: module loading detected + pages not mappable |
| US government issues CLOUD Act subpoena | Provider cannot comply -- they do not have the secrets, the encryption keys, or the ability to access them technically | Legal demand rendered moot by technical impossibility |
Article 33 -- Conditions for Lawful International Access¶
Article 33 specifies the conditions under which international government access to non-personal data may be lawful (e.g., via international agreements, mutual legal assistance treaties). CloudTaser does not interfere with lawful access conducted through proper EU legal channels -- the EU entity controlling the vault can comply with lawful EU government requests.
Article 34 -- Commission Powers¶
Article 34 empowers the Commission to develop harmonized standards for the technical measures required by Article 32. CloudTaser's architecture aligns with the expected direction of these standards: client-side encryption, EU key control, and runtime memory protection.
Component Coverage Matrix¶
| CloudTaser Component | Data Act Chapters Addressed |
|---|---|
| Operator (webhook injection) | Chapter VI (switching, portability, interoperability) |
| Wrapper (secret delivery) | Chapter III (data protection), Chapter VI (portability), Chapter VII (government access) |
| eBPF (runtime enforcement) | Chapter VII (government access prevention) |
| S3 Proxy (client-side encryption) | Chapter III (data integrity), Chapter VII (government access) |
| DB Proxy (transparent encryption) | Chapter III (data integrity), Chapter VII (government access) |
| CLI (audit, validate, discover) | Chapter VII (transparency, documentation) |
Gaps and Limitations¶
| Data Act Area | Gap | Mitigation |
|---|---|---|
| Chapter II (IoT data access) | CloudTaser does not address IoT data access obligations | Outside scope. CloudTaser protects secrets and encryption keys, not IoT data flows |
| Chapter IV (unfair contract terms) | CloudTaser does not address contractual fairness | Legal/contractual measure, outside product scope |
| Chapter V (B2G data sharing) | CloudTaser does not address government data sharing requirements | Outside scope. CloudTaser protects against unauthorized government access, not authorized data sharing |
| Personal data handling | Chapter VII Articles 32-34 apply specifically to non-personal data. For personal data, GDPR transfer mechanisms (Schrems II supplementary measures) apply | CloudTaser's Schrems II mapping covers personal data. The technical measures are the same |
| Full provider compliance | The Data Act places obligations on cloud providers, not their customers | CloudTaser helps customers implement technical measures that satisfy the provider's Article 32 obligations. Customers should verify their provider also complies with Chapters VI and VII |
Data Act and Schrems II overlap
Article 32 of the Data Act (non-personal data) and Schrems II supplementary measures (personal data) both require technical measures against non-EU government access. CloudTaser's technical controls satisfy both requirements simultaneously. See the Regulatory Mapping page for the Schrems II mapping.
Audit Evidence¶
CloudTaser produces evidence relevant to Data Act compliance:
# Generate compliance audit report
cloudtaser audit --vault-address https://vault.eu.example.com
# JSON output for evidence packages
cloudtaser audit --vault-address https://vault.eu.example.com -o json
The audit report provides:
- Cloud-agnostic deployment verification (Chapter VI portability)
- EU vault connectivity verification (Chapter VII data sovereignty)
- Protection scores per workload (Chapter VII technical measures)
- eBPF enforcement coverage (Chapter VII government access prevention)
- Orphaned Kubernetes Secrets inventory (data in US-controlled storage)