欧洲数据保护监督官《TechDispatch 1/2026——安全多方计算(Secure Multi-Party Computation)》(2026年9月17日发布)

简称:EDPS TechDispatch 1/2026 安全多方计算

法规信息
  • 国家/地区:欧盟
  • 发布单位:欧洲数据保护监督官(European Data Protection Supervisor,EDPS)
  • 发布日期:2026-09-17
  • 法规类别:技术说明报告(TechDispatch)
  • 法规文号:TechDispatch 1/2026;ISBN 978-92-9242-964-5;doi:10.2804/4211489

查看 / 下载 PDF
法规简介

EDPS 发布《TechDispatch 1/2026》,介绍安全多方计算(SMPC)这一使不同组织在不相互披露数据的前提下共同计算结果的密码学技术;报告分析其在医疗、金融等领域支持隐私保护型协作的潜力,同时强调 SMPC 并不免除组织依欧盟数据保护法承担的义务。

Luxembourg: Publications Office of the European Union, 2026 © European Union, 2026 The reuse policy of European Commission documents is implemented by Commission Decision 2011/833/ EU of 12 December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Unless otherwise noted, the reuse of this document is authorised under a Creative Commons Attribution 4.0 International (CC BY 4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided appropriate credit is given and any changes are indicated. For any use or reproduction of elements that are not owned by the European Union, permission may need to be sought directly from the respective rightholders. PDF ISBN 978-92-9242-964-5 ISSN 2599-932X doi:10.2804/4211489 QT-01-26-002-EN-N Executive Summary Secure multi-party computation (SMPC) is a field of cryptography that enables different organisations to collaborate with their data while keeping their information private. The use of advanced cryptographic techniques allows different participants to compute shared results and gain insights without revealing any individual data. This is particularly valuable in fields such as medicine and finance, where organisations can benefit from jointly processing the data that each organisation possesses, whether client or patient data, but cannot, or do not want to, share it among themselves for different reasons (data protection, security or commercial interests). For instance, being able to determine whether an experimental treatment produces similar side effects across multiple institutions could provide crucial insights without requiring any organisation to share its underlying data. While highly beneficial for researchers, the use of SMPC also matters for the individuals whose data is involved. By enabling organisations to develop improved services and products without sharing personal data across multiple parties, SMPC supports more privacy-preserving forms of collaboration and challenges the traditional notion that data needs to be directly accessed in order to be used. Under this new 1 paradigm, data can be made available for specific computations while remaining protected and inaccessible for any other purpose. This represents a potential shift in how information can be used safely, securely and ethically in increasingly data-driven environments. In this respect, SMPC demonstrates considerable potential as a privacy-enhancing technology (PET). It enables data controllers to retain a high degree of control over the data for which they are responsible, while still allowing meaningful collaboration and analysis across organisational boundaries. At the same time, SMPC should not be regarded as a mechanism for circumventing legal or regulatory obligations, especially those stemming from the General Data Protection Regulation (GDPR). The use of SMPC does not, in itself, render data anonymous, nor does it remove all the responsibilities associated with processing personal data. Where personal data is involved, the processing carried out through SMPC remains subject to applicable data protection law, including obligations relating to lawfulness, transparency, purpose limitation, security, accountability and the rights of data subjects. Rather than replacing data protection requirements, SMPC should be understood as a tool that can help organisations better fulfil them. When properly implemented and governed, it may enable the secure use of information that might otherwise pose excessive risks to individuals’ rights and freedoms. 1 The groundwork for secure multi-party computation dates back to the 1970s, when cryptographers first begavn exploring methods for secure collaborative computation without relying on trusted third parties. See section 2 “What is SMPC?”. 1 Executive Summary Secure multi-party computation (SMPC) is a field of cryptography that enables different organisations to collaborate with their data while keeping their information private. The use of advanced cryptographic techniques allows different participants to compute shared results and gain insights without revealing any individual data. This is particularly valuable in fields such as medicine and finance, where organisations can benefit from jointly processing the data that each organisation possesses, whether client or patient data, but cannot, or do not want to, share it among themselves for different reasons (data protection, security or commercial interests). For instance, being able to determine whether an experimental treatment produces similar side effects across multiple institutions could provide crucial insights without requiring any organisation to share its underlying data. While highly beneficial for researchers, the use of SMPC also matters for the individuals whose data is involved. By enabling organisations to develop improved services and products without sharing personal data across multiple parties, SMPC supports more privacy-preserving forms of collaboration and challenges the traditional notion that data needs to be directly accessed in order to be used. Under this new 1 paradigm, data can be made available for specific computations while remaining protected and inaccessible for any other purpose. This represents a potential shift in how information can be used safely, securely and ethically in increasingly data-driven environments. In this respect, SMPC demonstrates considerable potential as a privacy-enhancing technology (PET). It enables data controllers to retain a high degree of control over the data for which they are responsible, while still allowing meaningful collaboration and analysis across organisational boundaries. At the same time, SMPC should not be regarded as a mechanism for circumventing legal or regulatory obligations, especially those stemming from the General Data Protection Regulation (GDPR). The use of SMPC does not, in itself, render data anonymous, nor does it remove all the responsibilities associated with processing personal data. Where personal data is involved, the processing carried out through SMPC remains subject to applicable data protection law, including obligations relating to lawfulness, transparency, purpose limitation, security, accountability and the rights of data subjects. Rather than replacing data protection requirements, SMPC should be understood as a tool that can help organisations better fulfil them. When properly implemented and governed, it may enable the secure use of information that might otherwise pose excessive risks to individuals’ rights and freedoms. 1 The groundwork for secure multi-party computation dates back to the 1970s, when cryptographers first begavn exploring methods for secure collaborative computation without relying on trusted third parties. See section 2 “What is SMPC?”. 3 CONTENTS Executive Summary ...........................................................................................................1 1. Introduction ..................................................................................................................4 Purpose and structure ...........................................................................................................5 2. What is SMPC? .............................................................................................................6 Origin .....................................................................................................................................6 A simplified representation of the millionaire’s problem ..................................................7 Terminology ...........................................................................................................................8 Principles ..............................................................................................................................10 How SMPC works: a high-level description ......................................................................10 3. What SMPC can do (some existing and potential practical use cases) .......................12 Cross-organisational statistics in the JOCONDE project................................................12 Money laundering detection .............................................................................................13 Data exchange between law enforcement agencies ......................................................13 Secure messaging and processing in adversarial environments ....................................14 SMPC applied in machine learning ...................................................................................14 4. SMPC and data protection .........................................................................................16 Contribution to data protection principles .......................................................................16 SMPC does not take data processing outside data protection law ...............................16 Accountability, roles, and allocation of responsibility .....................................................17 Risk assessment should go beyond the protocol itself ...................................................18 5. Factors influencing the adoption of SMPC .................................................................19 State of play .........................................................................................................................19 Opportunities ......................................................................................................................19 Challenges to SMPC adoption .........................................................................................20 Risks and limitations of SMPC ............................................................................................21 6. Conclusion ..................................................................................................................23 7. Bibliography ...............................................................................................................24 TechDispatch on secure multi-party computation 4 1. Introduction The growing demand for personalised, feature-rich and data-driven services has significantly increased organisations’ reliance on large volumes of high-quality data. This trend is especially evident in data-intensive systems, and particularly in the training of artificial intelligence (AI) systems, where diverse and comprehensive datasets are essential for the training, validation and refinement of models. The datasets that are most relevant for training AI models often contain confidential information, whether proprietary business information or personal data. For example, a pharmaceutical company may seek to train an AI model on unpublished clinical trial data and internal research findings. In this scenario the processing would involve both commercially sensitive information and personal data. Sharing this type of data with other organisations (for instance, an external company customising AI products based on client needs) may involve security and privacy risks stemming from unauthorised access to or public disclosure of confidential data. This could result in impacts on individuals’ rights (e.g. loss of confidentiality, discrimination and profiling), expose trade secrets, or create vulnerabilities in information systems. The core issue is that traditional approaches to joint data analysis often rely on transferring or centralising datasets, which entails disclosing the data to the other parties. Such practices increase the risk of unauthorised access, secondary use beyond original purposes or loss of control by individuals, and could result in greater impact from data breaches. The centralisation of data that these approaches require can introduce additional structural risks. Concentrating data within a single entity or intermediary may create a high-value target for external attacks and increase exposure to potential insider misuse. These challenges underscore the need for alternative models of collaboration that reduce reliance on direct data sharing. The more constructive question is not whether data can be exchanged, but whether organisations can jointly derive meaningful insights while keeping their underlying data confidential. Secure multi-party computation (SMPC) offers a technical response to this challenge by enabling multiple parties to jointly compute a function over their private inputs without revealing those inputs to one another. Participants exchange cryptographically protected data shares and learn only the agreed output, thereby limiting direct data disclosure while retaining analytical utility. SMPC can support data protection principles such as data minimisation, confidentiality and privacy by design, and may therefore be regarded as a privacy-enhancing technology (PET). In this way, it can help mitigate certain privacy and security risks associated with collaborative data use and form part of a broader strategy for responsible and secure data collaboration. Nevertheless, the deployment of SMPC also raises important governance, accountability, technical and compliance considerations, as it does not remove regulatory obligations or eliminate all residual risks. TechDispatch on secure multi-party computation 5 1.1 Purpose and structure The purpose of this TechDispatch is to provide a structured and accessible overview of SMPC. It aims to explain the core principles of SMPC, outline how the technology operates in practice, and describe its main technical characteristics and limitations. A particular focus is given to the contribution that SMPC can make to the protection of individuals’ privacy. The analysis examines how SMPC can support data protection objectives, including data minimisation, confidentiality, and privacy by design and by default, when applied in scenarios involving collaboration between multiple organisations that would otherwise require the sharing of personal data. The document also considers the extent to which SMPC can reduce certain privacy and security risks, while acknowledging that its use alone may be insufficient to guarantee the data protection of individuals. In addition, the document discusses the main drivers behind the adoption of SMPC, such as increasing regulatory requirements, growing concerns about data sharing and trust, and the need to enable data-driven innovation without excessive data disclosure. At the same time, it identifies and analyses key obstacles to wider uptake, including technical complexity, performance and scalability constraints, cost considerations, governance challenges, and legal and organisational uncertainties. The remainder of this TechDispatch is structured as follows. Section 2 introduces the core concepts and terminology of secure multi-party computation and offers a high-level description of how it works. Section 3 illustrates what SMPC can do through selected practical use cases, including the specific use of SMPC in machine learning. Section 4 examines SMPC from a data-protection perspective. Section 5 analyses factors that influence adoption, including opportunities, challenges and risks. Section 6 concludes. TechDispatch on secure multi-party computation 6 2. What is SMPC? Secure multi-party computation refers to a class of cryptographic protocols that allow multiple parties to jointly compute a function2 using data from their private datasets without revealing their inputs to one another or to third parties. The central idea is that the computation is distributed across several parties in such a way that no single participant ever has access to the full dataset or to other parties’ underlying data. This means that multiple organisations can collaborate on the processing of confidential business information or personal data without directly sharing raw inputs. This makes SMPC particularly relevant for sensitive domains, including cybersecurity, official statistics, financial services, healthcare, law enforcement cooperation and cross-border data analysis. 2.1 Origin The foundational work for multi-party computation dates back to the end of the 1970s, when cryptographers sought ways to allow only authorised parties to access specific information without relying on a trusted third party. In this context, the work ‘Mental Poker’ (Shamir et al., 1981) proposed a cryptographic method for playing a fair game of poker remotely, over the phone in the original formulation, while ensuring that no central authority was needed to guarantee fairness. However, it was Andrew Yao who introduced the concept of ‘garbled circuits’ 3 in his paper ‘Protocols for secure computations’ (Yao, 1982), which would become a fundamental principle of SMPC. His work presented the ‘millionaires’ problem’, a pivotal thought experiment in cryptography. In this fictional problem, two millionaires want to determine who is richer without revealing their actual wealth, learning only the comparison result (who is richer or whether they are equal). To achieve this, they engage in a cryptographic protocol that allows their private inputs to be compared in a protected manner through a series of secure computations and message exchanges, ensuring that neither party learns anything about the other’s wealth beyond the final outcome. While the millionaires’ problem demonstrates two-party secure computation, real-world SMPC often involves multiple parties (e.g. banks working together on anti-money laundering) and complex functions (e.g. machine learning model training). 2 In SMPC, the function being computed can be any agreed-upon calculation on the parties’ private inputs. This can be something simple, like comparing values or computing a sum or average, or something more complex, like running statistics, answering database queries, or performing parts of a machine-learning task. The key idea is that as long as the calculation can be written as a precise algorithm, it can be carried out jointly without revealing the underlying private data. 3 See the definition in the ‘Terminology’ section. TechDispatch on secure multi-party computation 7 2.2 A simplified representation of the millionaire’s problem This example illustrates the basic intuition behind SMPC using additive secret sharing. 4 Real SMPC protocols use more advanced cryptographic techniques than those shown here. Imagine Alice, Bob and Clara are three millionaires who want to find out who is the richest without revealing their fortunes to each other. Alice has €8 million, Bob has €5 million and Clara has €10 million, so they should ultimately conclude that Clara is the richest. To perform the SMPC computation, each of them generates three random numbers, the sum of which should equal their respective fortunes.5 For example: Alice Bob Clara 20 35 18 15 –25 –5 –27 –5 –3 Sum: 8 Sum: 5 Sum: 10 Then, each participant privately sends one random share to every other participant while keeping one share for themselves 6, as illustrated in the figure below. Each individual share appears random and, on its own, reveals no information about the original fortune. However, each party can use their received values to perform a calculation that will ultimately contribute to the desired result. 4 This example is based on one provided by Thomas Zakrzewski, which can be found in https://www.linkedin.com/pulse/ introduction-multiparty-computation-thomas-zakrzewski-tom-z-/ 5 In practical implementations, these values are usually generated and combined using modular arithmetic over a large finite field. This example uses ordinary integers for simplicity. 6 Not all SMPC protocols distribute shares this way. Some use threshold secret sharing (e.g., Shamir’s Secret Sharing), replicated secret sharing, or protocol-specific preprocessing. TechDispatch on secure multi-party computation 8 To determine whether Alice has more money than Bob, the following statement needs to be true: Alice – Bob > 0 Because the original fortunes were split into shares by addition, the differences between those shares can also be added together. When all three participants add their local results, the shares combine to reveal the true difference between Alice’s and Bob’s fortunes: A – B = (A1 + A2 + A3) – (B1 + B2 + B3) = (A1 – B1 ) + (A2 – B2 ) + (A3 – B3 ) For this, each party uses the shares they hold for Alice and Bob to calculate the difference between them: • Alice computes: 20 – (–25) = 45 • Bob computes: 15 – 35 = –20 • Clara computes: –27 – (–5) = –22 Each participant’s result is not the actual difference between Alice’s and Bob’s fortunes. Instead, it is a share of that difference. The participants therefore reconstruct the overall difference by adding their locally computed results: 45 – 20 – 22 = 3, which is greater than 0 In this simplified example, the intermediate values are reconstructed so that everyone can see the final difference (which is 3). Real SMPC protocols would instead perform the comparison without reconstructing this intermediate value, revealing only whether Alice is richer than Bob. The same process is repeated for the remaining pairs of participants (i.e. Alice and Clara, and Bob and Clara 7). By comparing each pair, the participants can determine which participant has the highest fortune without revealing the value of any individual fortune. 2.3 Terminology This document uses the following terminology: • Party: An organisation that holds private input data and participates in an SMPC protocol (see next definition) to achieve, or to help achieve, a certain goal. • SMPC protocol: A formally defined set of rules governing how parties operate during the computation, including the required input formats, message exchanges, and output generation. Compliance with the protocol is mandatory for all parties. A party is considered honest if it follows the protocol as specified, and corrupted if it deviates from the protocol. 8 7 Some implementations may optimize the number of comparisons required. For example, if it is already known that Alice > Bob and Bob > Clara, then an explicit comparison between Alice and Clara may be unnecessary. 8 SMPC protocols typically define a threat model, distinguishing between ‘honest-but-curious’ adversaries, who follow the protocol but attempt to infer additional information, and malicious (‘corrupted’) adversaries, who may deviate from the protocol. Security guarantees depend on assumptions regarding how many parties may be corrupted simultaneously. TechDispatch on secure multi-party computation 9 • Secret sharing is a core mechanism in SMPC. Each party divides its private input into multiple shares and distributes them among the participating parties. On their own, these shares reveal no information about the original data, but when combined according to the protocol, they enable the parties to perform computations or reconstruct the final result without ever exposing the original inputs. • Oblivious transfer is a cryptographic protocol designed to enable controlled, privacy- preserving disclosure of information between parties who do not fully trust each other, or that wish to share only the minimum necessary data. In its standard form, one party (the sender) holds two pieces of information, and the other party (the receiver) is entitled to obtain exactly one of them. The protocol ensures two things simultaneously: a) the receiver obtains a piece of information from the sender without revealing which piece was obtained, and without learning anything beyond the selected information; b) the sender does not learn which information was requested or received. This is a key component in many SMPC protocols. • Garbled circuits are a cryptographic technique that allows two parties to compute a result while keeping their inputs confidential. One party (the garbler) converts the computation into an encrypted form and provides it, along with encrypted representations of their own input, to the other party (the evaluator). The evaluator obtains encrypted representations of their own input through a separate protocol, without revealing those inputs to the garbler. The evaluator can then run the computation to obtain the result, learning nothing about the garbler’s data beyond what the output itself reveals, while the garbler learns nothing about the evaluator’s inputs. By default, only the evaluator receives the final result; if both parties need to know the output, an additional exchange needs to be carried out. • Homomorphic encryption permits certain computations to be performed directly on encrypted data, producing encrypted results that can later be decrypted to obtain the correct output. 9 In practice, SMPC systems often combine several cryptographic building blocks, including secret sharing, oblivious transfer, garbled circuits and homomorphic encryption, each operating at different levels of the protocol stack and offering different trade-offs between communication cost, computational overhead and the number of parties supported. 9 Homomorphic encryption can be classified into three main types based on supported operations and depth: Partially Homomorphic Encryption – PHE (supports one operation – addition or multiplication), Somewhat Homomorphic Encryption – SHE (supports both addition and multiplication, but only for a limited number of times or a limited depth of calculations), and Fully Homomorphic Encryption – FHE (enables arbitrary, complex and unlimited computations (both addition and multiplication) on encrypted data). TechDispatch on secure multi-party computation 10 2.4 Principles Zhao et al. (2019) identified the following five core principles for SMPC protocols: • Privacy: No party should be able to obtain any information other than its own output and information that can be derived from its own input and output. • Correctness: The output received by each party should be correct; • Fairness: Either all parties receive the output, or none does, i.e. corrupted parties should receive their own outputs if and only if the honest parties receive their own outputs. • Independence of input: Parties choose their inputs independently, without being influenced by others’ data. • Guarantee of output: Corrupted parties should not be able to prevent honest parties from receiving their own outputs. In other words, the adversary should not be able to interrupt the computation by running a ‘denial of service’ attack. SMPC protocols are typically designed to remain secure even if communication channels are observed or partially compromised. By distributing trust across multiple parties, SMPC reduces or eliminates the need for a fully trusted central intermediary, which is often a major source of risk in traditional data-sharing architectures. 2.5 How SMPC works: a high-level description A typical SMPC computation can be summarised in four stages: 1. Agreement on goal and protocol. The participating parties define the function they wish to compute and agree on an SMPC protocol and supporting infrastructure. Having a compatible infrastructure means that the parties need to have the appropriate computational resources, software libraries and cryptographic tools to enable secure, distributed computation. 2. Preparation and sharing of inputs. Each party encodes its private data into cryptographic shares or encrypted values10 and distributes these according to the chosen protocol, so that no single share reveals meaningful information. 3. Distributed computation. The parties collaboratively perform arithmetic or logical operations on their shares, exchanging only encrypted intermediate values. At no point are the original inputs reconstructed during this phase. 10 Input data can be protected using secret sharing, encryption, or a combination of both, depending on the protocol. In secret sharing, no single party ever holds the full input after distribution, and computation proceeds by having all parties operate on their respective shares in a coordinated way. With encrypted values, a party encodes its input as a ciphertext, and the computation operates on that ciphertext directly, either through homomorphic operations or by evaluating a garbled circuit. TechDispatch on secure multi-party computation 11 4. Reconstruction of output. Once the computation is complete, the parties combine their final shares to reconstruct the agreed output. The result (i.e. the final computation) reveals only what can be inferred from the output itself, not from individual inputs. TechDispatch on secure multi-party computation 12 3. What SMPC can do (some existing and potential practical use cases) This section presents examples of SMPC implementations and proposed applications across different sectors. Its objective is to illustrate how SMPC can potentially be deployed to achieve outcomes that would otherwise require the sharing of personal data. These examples are only intended to demonstrate the technical feasibility and versatility of SMPC in diverse contexts. They do not, however, constitute an assessment of whether the specific implementations satisfy applicable legal or regulatory requirements. 3.1 Cross-organisational statistics in the JOCONDE project The JOCONDE project11 is a European initiative led by Eurostat that explores ways for official statistics to be produced collaboratively across countries without sharing the data collected (including personal data) with other statistical organisations or third parties. Instead of establishing a permanent shared infrastructure or central platform, the project explores the feasibility of an on-demand, decentralised approach to study how joint statistical computations could be carried out for a specific purpose and a limited period. JOCONDE focuses on cross-border collaboration within the public sector and is not intended for commercial data sharing or experimental research use. The project considers the legal, organisational and governance constraints faced by statistical authorities, including confidentiality requirements, accountability obligations and the need for transparency in the production of results. The main objective of the project is to assess feasibility, clarify roles and responsibilities, and identify the technical, legal and organisational conditions required to support potential future scaling of such an approach. 11 The name stands for Joint On-demand COmputation with No Data Exchange. More information on the project can be found at https://cros.ec.europa.eu/joconde TechDispatch on secure multi-party computation 13 3.2 Money laundering detection Financial crime is a global problem, and banks play a crucial role in identifying suspicious transactions. However, illicit transaction flows often span multiple institutions rather than remaining within a single bank’s network, which means they can easily go undetected. Although sharing detailed financial transaction data between banks is subject to data protection and anti-money laundering regulations, recent implementations of SMPC have shown that banks can collaboratively compute a risk score for each customer while preserving the confidentiality of sensitive information. One possible implementation uses the notion of ‘secure risk propagation’, where the risk calculation is performed in consecutive iterations. 12 In a secure risk propagation iteration, participating banks exchange encrypted (and only the relevant) risk scores. Each customer’s risk score is computed based on their transactions with other clients, while also incorporating the risk scores of those counterparties. These scores are encrypted using additive homomorphic encryption (AHE), which allows addition to be performed directly on encrypted data. When a bank wishes to decrypt the final risk score of one of its own customers, it can do so only with the consent of the other participating banks, using a mechanism called threshold decryption. 13 This ensures that no single institution can unilaterally access sensitive information. 3.3 Data exchange between law enforcement agencies In many serious criminal cases, relevant information about suspects is distributed across multiple law enforcement agencies (LEAs), with each agency holding only partial indicators that may be insufficient, when considered in isolation, to justify further action. As a result, this fragmentation of knowledge can hinder timely and effective intervention. At the same time, data processing based on large, centralised databases has repeatedly been found to pose severe risks to fundamental rights, enabling profiling, function creep and disproportionate surveillance. 14 Existing decentralised exchange mechanisms also struggle to balance necessity, proportionality and purpose limitation. To resolve this conflict, Treiber et al. (2022) proposed a privacy-preserving, decentralised architecture based on SMPC and private set intersection (PSI).15 Rather than pooling raw data, 12 A solution proposed by the company TNO following the research paper on this topic (van Egmond, 2024) 13 Threshold decryption is a cryptographic technique that prevents any single party from decrypting data on its own. Instead of one entity holding the full decryption key, the key is split into multiple shares, each held by a different participant (different banks, in the case above). A predefined minimum number of these participants (called the threshold) need to cooperate to decrypt the data. 14 The rise of the Surveillance Databases, Privacy International, https://privacyinternational.org/long-read/5455/rise-surveillance- databases 15 PSI is a practical application of SMPC that enables two or more parties to determine the intersection of their datasets – the items they have in common – without disclosing any additional information about their data. Using PSI, parties can only learn which identifiers are common with other parties, while learning nothing about items that are unique to the other parties. No raw data is exchanged in plaintext, and nothing beyond the agreed output is disclosed. TechDispatch on secure multi-party computation 14 participating LEAs would retain their databases locally and jointly execute a cryptographic protocol. First, the protocol would determine which identities occur in more than one database. Then, it would securely evaluate whether the combined, lawfully held information meets predefined legal criteria for information exchange. Throughout the computation, all intermediate data would remain encrypted or secret-shared, ensuring that no participating agency would gain access to any underlying information beyond what is strictly necessary. In particular, agencies would learn nothing about individuals who do not appear in multiple datasets, nor about matching individuals who fail to meet the applicable legal thresholds. While the protocol limits direct data exposure, the output itself may still reveal sensitive inferences (e.g. identifying suspects based on cross-agency matches), requiring additional safeguards (e.g. human review, purpose limitation). Because intermediate values processed during secure multi-party computation are not directly accessible to the participating parties, the exposure of personal data is reduced in comparison to approaches based on plaintext sharing. 3.4 Secure messaging and processing in adversarial environments Chandran et al. (2023) proposed an SMPC-based secure communication scheme that uses secret sharing to split a message into multiple cryptographic shares, which are then transmitted over independent communication channels.16 Each channel carries only a fragment of the message, and no single channel reveals any meaningful information on its own. The recipient reconstructs the original message only after receiving all required shares. The main privacy gain of this approach is the elimination of a single point of trust. Since no individual service provider or communication channel has access to the complete message, the risk of disclosure through compromised infrastructure, provider access, or backdoors is reduced. Confidentiality is preserved as long as at least one channel remains uncompromised. According to the authors, the design also limits data exposure by avoiding centralised key management or reliance on long-term cryptographic secrets, and it can operate entirely on the client side. While the scheme does not provide anonymity or metadata protection, it offers a simple and understandable mechanism for strengthening end-to-end confidentiality across existing communication platforms. 3.5 SMPC applied in machine learning SMPC can provide a way to train and use machine-learning models without requiring parties to surrender their underlying data (Zhou, 2024). This can offer advantages from a data-protection perspective, as it reduces unnecessary disclosure of personal or confidential information while still enabling collaborative analysis and development. 16 The EMC2 tool can be tested online in https://encrypto.de/emc2/index.html TechDispatch on secure multi-party computation 15 Some works refer to the set of techniques used to train and deploy machine learning models while keeping the underlying data secure and confidential as privacy-preserving machine learning (PPML) (Xu, 2021). In collaborative model training, multiple parties each possess a private dataset and jointly compute a shared machine-learning model while keeping their local datasets confidential. 17 SMPC can also support privacy-preserving inference, allowing one party to execute a model using another party’s confidential input data without revealing either the model parameters or the input data to the other party. As a result, SMPC can be applied throughout different stages of the machine-learning lifecycle, including both training and inference (Mudannayake, 2025). One practical example is CrypTen, (Knott, 2021) an open-source framework designed to make SMPC more accessible to machine-learning practitioners by integrating secure computation into a programming interface similar to PyTorch. 18 Rather than requiring developers to work directly with cryptographic protocols, the framework provides more familiar abstractions, allowing existing machine-learning models to be adapted with relatively limited changes. The framework has been proposed for applications including image classification, speech recognition and text classification. Applying SMPC to machine-learning workloads nevertheless remains computationally demanding. The main practical limitations arise from the communication rounds required between participating parties and the computational cost of cryptographic operations, particularly for deep-learning models with large numbers of parameters. Consequently, scalability remains an important consideration as the number of participants and model complexity increase. In a machine-learning context, SMPC is often combined with complementary privacy-enhancing technologies rather than used in isolation. For example, within federated learning, SMPC can be used to securely aggregate model updates during collaborative training, ensuring that individual participants’ updates remain confidential while only the aggregated result is revealed. Techniques such as differential privacy may then be added to reduce the amount of information that could still be inferred from the aggregated model or its outputs (Mudannayake, 2025). The appropriate combination of techniques depends on the intended application, threat model and required balance between privacy, accuracy and computational efficiency. 17 An example of collaborative model training is federated learning, where each party trains a local model on their dataset. 18 PyTorch is an open-source deep learning framework based on the Python programming language that is widely used for developing and training neural networks. TechDispatch on secure multi-party computation 16 4. SMPC and data protection 4.1 Contribution to data protection principles The use of SMPC for processing personal data can help to promote several data protection principles. In particular: • SMPC can reduce unnecessary sharing, and consequent processing, of personal data when compared to traditional data-sharing approaches. In this way, SMPC promotes data minimisation; • The fact that the communications and computations occur over encrypted data contributes to the confidentiality and integrity of the data during those stages of the processing; • By reducing the sharing, and potential replication, of personal data across different organisations, SMPC also contributes to reducing the risk of personal data breaches; • The fact that SMPC systems are set to address specific problems, and are constrained to use well-defined computations, helps ensure that personal data is used only to produce a certain type of result, which increases the chances that data will be used for a specific purpose (purpose specification). Taken together, these properties support the view that SMPC can be considered a privacy- enhancing technology (PET). However, SMPC does not eliminate all privacy risks and should therefore not be seen as a way to circumvent data protection obligations or as a substitute for compliance with applicable data protection laws, such as the GDPR. 4.2 SMPC does not take data processing outside data protection law Although SMPC-based data processing may prevent participating parties from attributing encrypted data they process to specific individuals, the processing still takes place on data that may relate to identifiable persons . This means that, even where the information is not directly intelligible to the parties involved, they may still be engaged in a processing operation in which the input data, and potentially also the output data, would qualify as personal data. It is equally important to recognise that an SMPC computation does not occur in isolation , but rather constitutes one stage within a broader data-processing operation. In some cases, the output generated through the multi-party computation will subsequently be combined with the TechDispatch on secure multi-party computation 17 original input data, whether because it enables additional inferences to be drawn or enriches the existing dataset in some manner. Accordingly, any assessment of SMPC should focus not only on the encrypted shares and the computational process, but also on the overall purpose and context of the whole data processing operation. This means that SMPC processing still needs an appropriate lawful basis and still needs to comply with purpose limitation, storage limitation, transparency and data subject rights, where applicable. From a compliance perspective, implementing data processing based on SMPC also requires careful analysis with regard to accountability and risk assessment. 4.3 Accountability, roles, and allocation of responsibility In the context of SMPC, accountability is among the most challenging compliance issues. This complexity arises because the computation is distributed across multiple participants, which can make the allocation of roles and responsibilities under the GDPR less clear. As a result, determining who qualifies as a data controller or processor – and who is responsible for specific compliance obligations – can become non-trivial, increasing the risk that parties underestimate their legal duties. Where parties are actively involved in determining the purposes and means of an SMPC system - for example by deciding what will be computed for which use case, which protocol stack will be used, what categories of data will be processed, and what input and output formats will be used – it can be considered that they fit within the definition of ‘controller’ under Article 4(7) of the GDPR.19 If multiple organisations jointly decide the purposes and means of the SMPC system, they are likely to qualify as joint controllers,20 even if none of them ever gains access to the other parties’ underlying private data. Where a party was not involved in the set-up of the SMPC (for example, because it joined the SMPC at a later stage21), and only participate by inputting data, outputting data, or both, they nevertheless may retain responsibility for ensuring compliance with data protection obligations in relation to their own processing activities (whether as a controller or a processor of that data). This includes ensuring the confidentiality, integrity and accuracy of the personal data processed, as well as compliance with applicable data subject rights. 19 ‘Controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data, where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law – Article 4(7) of the GDPR. 20 Article 26 (1) GDPR (Joint controllers) states that “Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers”. 21 Depending on the specific design of an SMPC protocol, adding a new participant may require anything from a full reinitialization of cryptographic setup (including key generation and secret sharing) to a more lightweight reconfiguration step. In general, newly admitted parties do not affect the structure or execution of an ongoing computation, which is fixed at protocol start, but instead need to be incorporated into the existing cryptographic state before participating in future or reconfigured executions. TechDispatch on secure multi-party computation 18 5. Factors influencing the adoption of SMPC 5.1 State of play Although SMPC offers valuable privacy advantages, its adoption remains comparatively limited outside specialised sectors. One of the main barriers is the significant computational and communication overhead associated with SMPC protocols, which often require extensive coordination, multiple rounds of interaction and substantial processing resources (Gamiz, 2025). Additionally, integrating SMPC into existing infrastructures frequently requires substantial architectural adaptation and specialised cryptographic expertise. 5.2 Opportunities Recent technical advances have improved the practicality and scalability of SMPC, supporting its broader adoption in operational environments. Improvements in secret-sharing schemes and computation protocols have reduced computational and communication overhead, making SMPC more efficient and suitable for real-world use cases. 23 In parallel, the emergence of dedicated deployment platforms, orchestration tools and browser- level or application-level integrations has lowered implementation barriers and simplified integration with existing systems. Automated provisioning and management capabilities further enable scalable, repeatable and auditable SMPC workloads, supporting consistent deployment across organisations. Collectively, these developments enhance the feasibility of SMPC as a privacy-preserving technology while enabling organisations to align technical implementation with governance, security and compliance requirements. Another opportunity stems from the continued research into privacy-preserving machine learning (PPML) (Tan, 2021) (Xu, 2021). The growing interest in PPML has encouraged the development of more efficient cryptographic protocols, software frameworks, optimisation techniques and deployment tools, many of which leverage or facilitate secure multi-party computation. Continued progress in the PPML ecosystem may therefore contribute to the wider maturity and adoption of SMPC technologies. 23 Works such as the ones from Liu et al. (2024) and Keller (2020) have proposed secret-sharing schemes to enhance the efficiency of SMPC infrastructures. Any subsequent processing of personal data that occurs when combining their original input data with the output generated by the SMPC computation should take place in accordance with data protection law. Organisations deploying SMPC should therefore clarify from the outset at least the following matters: the purpose of the computation, the categories of data involved, who determines the function and the protocol, who operates any coordinating infrastructure, who receives the output, how long inputs and shares are retained, and how incidents, audit requests and data subject requests will be handled. These questions should be reflected in appropriate legal and governance instruments, such as joint controllership arrangements, data processing agreements, protocol rules and security policies. 4.4 Risk assessment should go beyond the protocol itself As with any privacy-enhancing technology, SMPC integration into data processing activities should be preceded by a thorough assessment of the relevant data protection risks and the identification of appropriate mitigating measures. While personal data processed through SMPC may remain securely encrypted during computation, its confidentiality and integrity still need to be safeguarded when the data is stored and when it is handled within the organisation. The same level of protection should apply to any outputs generated through SMPC processing – including aggregate results, model outputs or statistical findings – where these may relate to identifiable individuals. At the protocol stage, implementation errors, poor key management, collusion assumptions, side-channel leakage, or weaknesses in an aggregation design can undermine the intended confidentiality guarantees. 22 There is also a risk that SMPC’s guarantees against direct data exposure could lead participants to place excessive trust in the system’s security features, while underestimating risks that can arise at other stages of the data processing lifecycle. Performing an adequate data protection risk assessment may also be more complex in the context of SMPC, as the parties involved might have limited or only partial visibility into the full attack surface – that is, the combination of entry points, vulnerabilities and exposed assets implicated in the computation. A thorough data protection impact assessment (DPIA) should therefore look beyond the SMPC protocol itself and consider the entire data processing pipeline: the nature and sensitivity of the inputs, the intended and foreseeable uses of the outputs, the parties involved, and the potential for inference attacks or unintended disclosures. 22 Sub-section Risks and limitations of SMPC of section 5 addresses some of these risks. TechDispatch on secure multi-party computation 19 5. Factors influencing the adoption of SMPC 5.1 State of play Although SMPC offers valuable privacy advantages, its adoption remains comparatively limited outside specialised sectors. One of the main barriers is the significant computational and communication overhead associated with SMPC protocols, which often require extensive coordination, multiple rounds of interaction and substantial processing resources (Gamiz, 2025). Additionally, integrating SMPC into existing infrastructures frequently requires substantial architectural adaptation and specialised cryptographic expertise. 5.2 Opportunities Recent technical advances have improved the practicality and scalability of SMPC, supporting its broader adoption in operational environments. Improvements in secret-sharing schemes and computation protocols have reduced computational and communication overhead, making SMPC more efficient and suitable for real-world use cases.23 In parallel, the emergence of dedicated deployment platforms, orchestration tools and browser- level or application-level integrations has lowered implementation barriers and simplified integration with existing systems. Automated provisioning and management capabilities further enable scalable, repeatable and auditable SMPC workloads, supporting consistent deployment across organisations. Collectively, these developments enhance the feasibility of SMPC as a privacy-preserving technology while enabling organisations to align technical implementation with governance, security and compliance requirements. Another opportunity stems from the continued research into privacy-preserving machine learning (PPML) (Tan, 2021) (Xu, 2021). The growing interest in PPML has encouraged the development of more efficient cryptographic protocols, software frameworks, optimisation techniques and deployment tools, many of which leverage or facilitate secure multi-party computation. Continued progress in the PPML ecosystem may therefore contribute to the wider maturity and adoption of SMPC technologies. 23 Works such as the ones from Liu et al. (2024) and Keller (2020) have proposed secret-sharing schemes to enhance the efficiency of SMPC infrastructures. TechDispatch on secure multi-party computation 20 5.3 Challenges to SMPC adoption SMPC still faces notable usability challenges that hinder its widespread adoption. A primary barrier is the complexity of protocol design, which requires developers to have in-depth knowledge of cryptography and distributed systems. Even minor implementation errors can compromise security, restricting development to specialists and limiting broader engagement (Gamiz, 2025). Also, despite technical advancements, performance and scalability remain key challenges in SMPC adoption, particularly for real-time applications (e.g. when systems need to deliver quick outputs). SMPC protocols often involve complex cryptographic operations that can be computationally intensive. 24 Such operations can significantly slow down processing, especially when handling large datasets or performing complicated computations (Liu, 2024). SMPC protocols also rely on frequent exchanges between participants to share secret shares, encrypted data and intermediate results. In distributed settings with many participants, this can significantly increase bandwidth usage and introduce latency (Zhou, 2024) (Rahaman, 2024). Many SMPC protocols incorporate fault-tolerance mechanisms: they can detect or correct deviations from the protocol, allowing the system to remain secure even if a subset of parties is corrupted (i.e. behaves maliciously or unpredictably). The exact tolerance depends on the protocol – for example, some protocols can withstand misbehaviour by up to a specified fraction of participants without compromising correctness or privacy. Despite these cryptographic safeguards, the selection of computation partners remains important . Exceeding the protocol’s misbehaviour threshold can undermine security guarantees or lead to computation failures. Additionally, trustworthy partners improve operational reliability, reduce the risk of delays or aborts and support compliance with legal, regulatory, and audit requirements. Equally critical is transparency around who participates as computation agents and how they are monitored. Even fault-tolerant protocols benefit from regular auditing, verifiable logging and formal agreements that define roles and responsibilities. These measures provide assurance that participants operate as intended, enable detection of misbehaviour that could exceed fault-tolerance thresholds, and support accountability for both internal stakeholders and external regulators. Finally, the cryptographic complexity of SMPC can make it difficult for regulators, auditors, or non-technical stakeholders to independently audit how computations are performed or whether protocol guarantees are correctly implemented. 24 This is particularly relevant for ML training/inference, see section 3 ‘What SMPC can do’, subsection ‘SMPC applied in machine learning’. TechDispatch on secure multi-party computation 21 5.4 Risks and limitations of SMPC 5.4.1 Collusion risk Collusion between participating agents represents a significant potential threat to data confidentiality. If multiple participants coordinate their actions and the protocol corruption thresholds25 are exceeded, there is a risk that shared data could be reconstructed, undermining the privacy guarantees of the system.26 To mitigate this risk, it is essential to carefully define secure protocol corruption thresholds and implement robust cryptographic safeguards. Properly designed protocols ensure that no subset of participants below the defined corruption threshold can reconstruct underlying data, thereby maintaining confidentiality and trust in multi-party computations. Organisations should also combine technical safeguards with governance measures, such as clear access policies and auditing, to further reduce the likelihood of collusion. 5.4.2 Operational and deployment risks In terms of system operation, although SMPC protects data at the computation level, secure transport layers are still necessary. Robust network security measures are still required to protect communications between participants. This is in addition to the need to apply adequate protection measures to personal data at rest within the systems of the participating party. 5.4.3 Limited protection against malicious inputs While SMPC protects data during computation, it does not inherently guarantee that the input data provided by participants is accurate, lawful, unbiased, or non-malicious. Parties may intentionally or unintentionally introduce manipulated, poisoned, or low-quality data into the computation. 5.4.4 Output leakage and inference risks Even where inputs remain secret, the final output of the computation may enable participants to infer sensitive information about other parties’ data, especially when outputs are highly granular, repeatedly queried, or combined with external datasets. 25 A corruption threshold refers to the maximum number (or proportion) of participants that a protocol can tolerate being compromised – whether through malicious behaviour, collusion, or technical failure – while still guaranteeing the security and correctness of the computation. 26 Wang et al. (2016) analysed different types of collusion attacks on secret-sharing-based SMPC protocols. TechDispatch on secure multi-party computation 22 6. Conclusion SMPC represents an important development in privacy-preserving data processing. It enables multiple parties to compute meaningful results without directly sharing their underlying data, offering an alternative to traditional data-sharing models. From a data protection perspective, SMPC can contribute to the implementation of key principles such as data minimisation, confidentiality, and privacy by design and by default. Its distributed and cryptographic nature reduces exposure to raw personal data and limits the risks associated with centralised storage or broad data disclosure. At the same time, SMPC does not transform personal data into anonymous data, nor does it remove the applicability of data protection law. Legal obligations related to principles such as lawfulness, transparency, purpose limitation, accountability and data subject rights remain fully applicable when personal data is processed through SMPC. This TechDispatch has also highlighted that the deployment of SMPC involves important technical, organisational, and governance considerations. Performance constraints, protocol complexity, partner selection, fault tolerance, and collusion risks should be carefully assessed. Moreover, clear allocation of roles and responsibilities, contractual arrangements, auditing mechanisms, and ongoing risk assessments are essential to ensure that SMPC is deployed in a trustworthy and legally compliant manner. Overall, SMPC should be understood as an enabling technology that can reduce certain risks associated with collaborative data processing, rather than as a standalone solution. Its responsible adoption at scale will depend on continued progress in technical standardisation and the availability of assurance and trust-building mechanisms. When integrated into a broader framework of technical and organisational measures, SMPC can play a meaningful role in supporting privacy-preserving data collaboration while maintaining legal and ethical safeguards. At a time when access to high-quality data - particularly personal data - is increasingly regarded as a key constraint on the development of advanced AI systems, it is worth considering the potential of a technology such as SMPC, which can allow different parties to build upon data from others while significantly reducing the risks associated with direct data sharing and centralised processing. 5.4.5 Governance and trust-building mechanisms Beyond technical performance and usability considerations, the adoption of SMPC is also influenced by governance and trust-related factors. Because SMPC relies on complex cryptographic protocols and distributed execution across multiple actors, its correct implementation and operation can be difficult to assess for non-specialists. This complexity may create uncertainty for organisations considering deployment, as well as for regulators and data subjects seeking assurance that the technology is used in a secure and compliant manner. In this context, certification and other assurance mechanisms can play an important role in supporting trust and adoption. Standardisation of SMPC protocols or implementations can provide structured guidance on how the technology should be deployed in line with recognised security, privacy and data protection standards. At the EU level, the development of harmonised standards and certification frameworks specifically addressing SMPC could make a significant contribution to broader adoption. Such standards could establish common benchmarks for protocol security, implementation requirements and data protection compliance, offering organisations a clear reference point when deploying SMPC across jurisdictions. Harmonised standards could also reduce fragmentation, ensuring that SMPC deployments in one Member State can be assessed and trusted by actors in another. From an accountability perspective, certification may also enhance transparency. It can support organisations in demonstrating that their use of SMPC has been independently assessed against predefined benchmarks, thereby facilitating internal governance, partner trust and regulatory oversight. For supervisory authorities, certification schemes can provide a common reference framework for evaluating complex cryptographic processing operations without requiring detailed, case-by-case technical audits. For individuals, certification may improve visibility into the safeguards applied to protect personal data in collaborative processing scenarios. Certified SMPC solutions would, nevertheless, not remove the need for context-specific risk assessments, nor would they alter the legal responsibilities of controllers and processors. The effectiveness of certification ultimately depends on its scope, governance and alignment with broader legal and organisational accountability mechanisms. TechDispatch on secure multi-party computation 23 6. Conclusion SMPC represents an important development in privacy-preserving data processing. It enables multiple parties to compute meaningful results without directly sharing their underlying data, offering an alternative to traditional data-sharing models. From a data protection perspective, SMPC can contribute to the implementation of key principles such as data minimisation, confidentiality, and privacy by design and by default. Its distributed and cryptographic nature reduces exposure to raw personal data and limits the risks associated with centralised storage or broad data disclosure. At the same time, SMPC does not transform personal data into anonymous data, nor does it remove the applicability of data protection law. Legal obligations related to principles such as lawfulness, transparency, purpose limitation, accountability and data subject rights remain fully applicable when personal data is processed through SMPC. This TechDispatch has also highlighted that the deployment of SMPC involves important technical, organisational, and governance considerations. Performance constraints, protocol complexity, partner selection, fault tolerance, and collusion risks should be carefully assessed. Moreover, clear allocation of roles and responsibilities, contractual arrangements, auditing mechanisms, and ongoing risk assessments are essential to ensure that SMPC is deployed in a trustworthy and legally compliant manner. Overall, SMPC should be understood as an enabling technology that can reduce certain risks associated with collaborative data processing, rather than as a standalone solution. Its responsible adoption at scale will depend on continued progress in technical standardisation and the availability of assurance and trust-building mechanisms. When integrated into a broader framework of technical and organisational measures, SMPC can play a meaningful role in supporting privacy-preserving data collaboration while maintaining legal and ethical safeguards. At a time when access to high-quality data - particularly personal data - is increasingly regarded as a key constraint on the development of advanced AI systems, it is worth considering the potential of a technology such as SMPC, which can allow different parties to build upon data from others while significantly reducing the risks associated with direct data sharing and centralised processing. TechDispatch on secure multi-party computation 24 7. Bibliography • Chandran, G. R. (2023). Encrypted MultiChannel Communication (EMC2): Johnny Should Use Secret Sharing. Proceedings of the 23rd Workshop on Privacy in the Electronic Society, 34-39. • Gamiz, I. R. (2025). Challenges and future research directions in secure multi-party computation for resource-constrained devices and large-scale computations. International Journal of Information. • Keller, M. (2020). P-SPDZ: A versatile framework for multi-party computation. Proceedings of the 2020 ACM SIGSAC conference on computer and communications security, 1575- 1590. • Knott, B. V . (2021). Crypten: Secure multi-party computation meets machine learning. Advances in Neural Information Processing Systems, 34, 4961-4973. • Liu, S. L. (2024). Efficient privacy-preserving Gaussian process via secure multi-party computation. Journal of Systems Architecture, 151. • Mudannayake, O. I. (2025). On privacy-preserved machine learning using secure multi-party computing: Techniques and trends. Computers, Materials & Continua, 85, 2527-2578. • Rahaman, M. A. (2024). Secure multi-party computation (SMPC) protocols and privacy. Innovations in Modern Cryptography, 193-2018. • Shamir et al. (1981). Mental poker. The mathematical gardner. Boston, MA: Springer US., 37-43. • Tan, S. K. (2021). CryptGPU: Fast privacy-preserving machine learning on the GPU. 2021 IEEE Symposium on Security and Privacy (SP), 2021-1038. • Treiber, A. M. (2022). Data protection law and multi-party computation: Applications to information exchange between law enforcement agencies. Proceedings of the 21st Workshop on Privacy in the Electronic Society, 69-82. • van Egmond, M. B. (2024). Privacy-preserving anti-money laundering using secure multi- party computation. International Conference on Financial Cryptography and Data Security, 331-349. • Wang, Z. C. (2016). Information-theoretic secure multi-party computation with collusion deterrence. IEEE Transactions on Information Forensics and Security, 980-995. • Xu, R. B. (2021). Privacy-preserving machine learning: Methods, challenges and directions. arXiv preprint arXiv:2108.04417. • Yao, A. C. (1982). Protocols for secure computations. 23rd annual symposium on foundations of computer science (sfcs 1982), 160-164. • Zhao, C. Z. (2019). Secure multi-party computation: theory, practice and applications. Information Sciences, 476, 357-372. • Zhou, I. T. (2024). Secure multi-party computation for machine learning: A survey. IEEE Access, 12, 53881-53899. This publication is a brief report produced by the Technology and Privacy Unit of the European Data Protection Supervisor (EDPS). It aims to provide a factual description of an emerging technology and discuss its possible impacts on privacy and the protection of personal data. The contents of this publication do not imply a policy position of the EDPS. The author is Vitor Bernardo. The editors are Luis Velasco, Massimo Attoresi and Xabier Lareo. Contact: techmonitoring@edps.europa.eu To subscribe or unsubscribe to TechDispatch publications, please use our newsletter management tool. The data protection notice is online on the EDPS website. © European Union, 2026. Except otherwise noted, the reuse of this document is authorised under a Creative Commons Attribution 4.0 International License (CC BY 4.0) . This means that reuse is allowed provided appropriate credit is given and any changes made are indicated. For any use or reproduction of photos or other material that is not owned by the European Union, permission must be sought directly from the copyright holders.