Sovereign Privacy-Enhancing Technologies and Federated Learning for European Organisations

Sovereign privacy-enhancing technologies (PETs) are a family of cryptographic and statistical techniques that allow organisations to extract analytical value from sensitive data without exposing the underlying records to any party that should not see them. For European regulated organisations, the critical addition is the word sovereign: the entire computation stack, from the orchestration layer to the model weights, must remain under a legal and jurisdictional framework that GDPR, DORA, NIS-2 and sector-specific rules such as the EU Health Data Space Regulation can actually enforce.

Why sovereign PETs matter differently from standard privacy tooling

Standard anonymisation or pseudonymisation tools reduce re-identification risk on a single dataset inside a single organisation. Sovereign PETs go further by enabling multi-party analytics, where hospitals, banks or public bodies jointly train models or run queries across their combined data without any participant’s raw records leaving its own controlled environment. The distinction matters legally because the moment raw data moves to a shared server, a new processing relationship is created, a new controller is potentially involved, and the question of where that server sits becomes a Chapter V transfer question under GDPR.

Federated learning architectures for EHDS and DORA contexts

In a federated learning deployment, each participating organisation trains a local model on its own data and sends only the resulting model updates (gradients or weights) to a central aggregator, which combines them without ever seeing individual records. For hospitals collaborating under the EU Health Data Space (EHDS) Regulation, this maps directly onto the secondary-use access model that the EHDS introduces: Health Data Access Bodies (HDABs) in each member state can approve algorithms that run inside a data holder’s environment rather than requiring data extraction. For financial entities under DORA, who must demonstrate operational resilience and supply-chain security, a federated approach means no single vendor or cloud provider accumulates the combined dataset of multiple institutions.

The architectural requirement for sovereignty is that the aggregation server must itself sit within an approved jurisdiction. Running OpenFL (Intel’s open-source federated learning framework) with its aggregator on an on-premises server in Germany or on a Swiss-hosted virtual machine satisfies this requirement. Running it on a US-based managed Kubernetes service does not, because US providers remain subject to CLOUD Act compelled-disclosure orders regardless of where the physical server is located.

Open-source frameworks and their sovereign integration challenges

Three frameworks are most commonly evaluated for sovereign PET deployments in European regulated sectors:

All three can be run entirely on-premises in principle. The practical challenge is not the code itself but the supply chain around it: package registries, container image repositories and documentation sites. Organisations should treat their PET software supply chain as a NIS-2 Article 21 security measure, subject to the same vendor risk assessment they apply to other critical dependencies.

Differential privacy: quantifying re-identification risk across sovereign jurisdictions

Even if raw data never leaves a participant’s perimeter, the aggregate outputs of a federated computation can leak information about individual records through membership inference or model inversion attacks. Differential privacy (DP) addresses this by adding calibrated statistical noise to outputs before they are shared, with the privacy loss measured by a parameter called epsilon.

No single binding epsilon threshold exists in current EU law. However, the European Data Protection Board and national supervisory authorities such as Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI) apply a general principle: epsilon values below 1.0 provide strong protection for sensitive categories of personal data under GDPR Article 9 (health data, financial data), while values up to roughly 10 may be defensible for lower-sensitivity aggregate statistics provided the dataset is large and the query budget is managed. Any organisation deploying DP in a regulated context should document the epsilon choice, the sensitivity of the underlying dataset, the expected number of queries, and the resulting re-identification risk estimate in a Data Protection Impact Assessment (DPIA) under GDPR Article 35.

“Federated learning is a promising approach that can help align AI development with European data protection principles, because it minimises the transfer of personal data while still enabling collaborative model training.” (European Data Protection Board, EDPB Guidelines on AI and data protection, edpb.europa.eu)

ISO/IEC 27563:2023 provides a structured taxonomy of privacy-enhancing technologies, including DP, and is now frequently cited by European DPAs as a reference framework when assessing whether an organisation has implemented “appropriate technical measures” under GDPR Article 25. Referencing ISO/IEC 27563 in a DPIA, alongside the specific DP parameters used, strengthens the demonstrability of compliance.

GDPR Article 26 joint-controller obligations and NIS-2 supply-chain security in multi-party PET deployments

When two or more organisations jointly determine the purposes and means of a federated computation, they become joint controllers under GDPR Article 26. This is not optional: Article 26 requires a binding arrangement that specifies each party’s responsibilities for transparency, data subject rights, breach notification and the technical security measures applied. In a sovereign secure multi-party computation (sMPC) or federated learning context, that arrangement must also describe the cryptographic protocol used, who controls the aggregation node, and what happens to intermediate computation artefacts after the run completes.

NIS-2 adds a parallel obligation. Article 21 of the NIS-2 Directive requires organisations in scope to manage supply-chain security risks, which includes the security of the software and infrastructure used in a multi-party computation. Each participant must assess whether the PET framework it uses introduces a dependency on a third-party vendor whose compromise could expose the participant’s data or disrupt the federation. This assessment should be documented and reviewed at least annually.

“Privacy-enhancing technologies represent a key building block for trustworthy data sharing across borders, and their deployment must be accompanied by rigorous governance to be legally effective.” (Andrea Jelinek, former Chair of the European Data Protection Board, EDPB Annual Report 2022, edpb.europa.eu)

Gaia-X data spaces and EHDS interoperability

The Gaia-X Data Spaces interoperability specifications define how federated data ecosystems can exchange metadata, access policies and credentials without centralising the underlying data. For a sovereign PET deployment, Gaia-X’s self-description and trust anchor mechanisms provide a way to assert that a particular computation node meets a defined set of technical and legal requirements before another participant sends it anything. In the health sector, the EHDS Regulation’s data access infrastructure is expected to align with Gaia-X principles, meaning that HDABs across member states will use compatible policy expression and access-control vocabularies.

In practice this means that a hospital network deploying PySyft for cross-border oncology research should expect to register its Domain nodes as Gaia-X participants with a self-description that includes the applicable EHDS data permit identifiers, the DP parameters applied, and the ISO/IEC 27563 technology category. This creates a machine-readable audit trail that both HDABs and national DPAs can query.

Generating audit evidence for data protection authorities

Proving to a DPA that no personal data left the sovereign perimeter during a federated run requires evidence at four layers. First, cryptographically signed network flow logs from each participating node must show that only gradient updates or aggregated model weights crossed the network boundary, not individual records. Second, a record of all differential privacy noise parameters applied before transmission must be retained alongside the corresponding query logs. Third, an immutable audit trail of who initiated the computation, under which data permit or GDPR Article 26 agreement, must be available. Fourth, for high-risk deployments, a Trusted Execution Environment (TEE) attestation report can demonstrate that the aggregation environment did not have decryption access to individual-level data.

Under DORA Article 25, ICT-related incident and audit records must be retained for five years. Healthcare organisations subject to the EHDS should align their PET audit log retention to the data permit duration specified by their HDAB, which may be shorter. The critical point is that these records must be generated automatically and continuously, not reconstructed after the fact in response to a supervisory inquiry.

IBM (2023): The average total cost of a data breach reached USD 4.45 million in 2023, the highest in 18 years of the IBM Cost of a Data Breach Report (ibm.com).

Sophos (2023): 60 percent of healthcare organisations reported being hit by ransomware in the previous year, underscoring why even analytical workloads involving health data must be treated as high-risk (sophos.com).

European Commission (2024): Only 17 of 27 EU member states had formally notified NIS-2 transposition measures by the October 2024 deadline, meaning a significant share of regulated organisations currently operate in a legal grey zone regarding supply-chain security obligations (digital-strategy.ec.europa.eu).

FAQ

Does federated learning by itself constitute a lawful data transfer mechanism under GDPR?

No. Federated learning reduces the movement of raw personal data but does not replace a lawful basis for processing under GDPR Articles 6 and 9, nor does it automatically satisfy Chapter V transfer rules if the aggregation server is located outside the EEA. A sovereign deployment keeps the orchestration layer inside an EEA or adequacy-decision jurisdiction and pairs it with a documented joint-controller agreement under Article 26.

What epsilon value for differential privacy does current European guidance consider acceptable for health data?

No single binding epsilon threshold exists in EU law yet. The EDPB and national authorities such as Germany’s BSI treat epsilon values below 1.0 as strong protection for sensitive health data under GDPR Article 9, while values up to around 10 may be acceptable for lower-risk aggregate statistics. Organisations should document their epsilon choice, the sensitivity of the dataset, and the expected query budget in their DPIA.

Can OpenFL or PySyft be run without any connection to US-controlled infrastructure?

Yes, but it requires deliberate configuration. OpenFL’s aggregator and PySyft’s Domain and Network nodes can run on on-premises servers or Swiss- or EEA-hosted virtual machines. The sovereign integration challenge is the software supply chain: both frameworks pull Python packages from PyPI, which is US-operated. Organisations should mirror required packages in an internal repository and disable outbound telemetry at deployment time.

How does the EHDS secondary-use regime interact with a federated learning deployment across member states?

Under the EHDS Regulation, secondary use of electronic health data requires a data permit from a national Health Data Access Body. The EHDS text allows approved researchers to run algorithms inside data holders’ environments rather than extracting data, which maps directly onto a federated compute approach. Each participating HDAB must approve the analysis protocol and the technical safeguards, including any differential privacy parameters applied before results are shared.

What audit evidence is required to prove to a DPA that no personal data left the sovereign perimeter during a federated run?

Organisations should generate: cryptographically signed network flow logs from each node showing only model updates traversed the boundary; a record of differential privacy parameters applied before transmission; an immutable audit trail of who initiated the computation and under which processing agreement; and, for high-risk deployments, a Trusted Execution Environment attestation report. Under DORA Article 25, these records must be retained for five years.