Skip to main content

Confidential computing and related technologies: a critical review


This research critically reviews the definition of confidential computing (CC) and the security comparison of CC with other related technologies by the Confidential Computing Consortium (CCC). We demonstrate that the definitions by CCC are ambiguous, incomplete and even conflicting. We also demonstrate that the security comparison of CC with other technologies is neither scientific nor fair. We highlight the issues in the definitions and comparisons and provide initial recommendations for fixing the issues. These recommendations are the first step towards more precise definitions and reliable comparisons in the future.


Regulations, such as the General Data Protection Regulation (GDPR) (European Commission: Regulation (EU) 2016/679 2016), necessitate protecting personal data. A wide variety of technologies, from purely algorithmic to hardware-based, exists as possible solutions. Purely algorithmic solutions include cryptographic methods, such as Homomorphic Encryption (HE) (Acar et al. 2018) and Secure Multi-Party Computation (MPC) (Evans et al. 2018). On the other end of the spectrum, hardware-based solutions include a secure cryptographic processor, such as Hardware Security Module (HSM) (Anderson 2020) and Trusted Platform Module (TPM) (Arthur and Challener 2015; Proudler et al. 2014). Recently, Confidential Computing (CC) using hardware-based Trusted Execution Environments (TEEs) has emerged as a promising solution (Confidential Computing consortium 2021). With such emerging technologies, it is crucial to precisely define, as well as reliably evaluate and compare technologies to choose the most suitable one for a given problem while ensuring compliance with legal standards.

As a first step towards definitions and comparison of technologies, some white papers (Confidential Computing consortium 2021a, b, c) have recently attempted to tackle this challenge. These white papers are a collaborative effort of the Confidential Computing Consortium (CCC), comprising various notable organizations, including Google, Microsoft, Huawei, Red Hat, Arm and Intel. Although CCC recommends using the definitions, we demonstrate in this work that the definitions by CCC are imprecise, incomplete and even conflicting. This is critical because of three main reasons. Firstly, it leaves room for competing vendors to claim CC to potentially give end usersFootnote 1 a false sense of security. Secondly, it creates legal uncertainty in the regulatory authorities for ensuring compliance with regulations, specifically transparency obligations. Finally, for researchers and solution providers, this hampers a reliable comparison across vendor solutions in a uniform way.

In relation to the comparison among various technologies for the protection of data, CCC white papers (Confidential Computing consortium 2021a, b, c) present security comparisons for TEE, HE and TPM. However, the threat model for such a comparison is not specified, and thus the comparison may lead to misleading conclusions. Moreover, there is a lack of scientific evidence and argumentation in the comparison.

To improve the situation, we review and highlight some of the key issues in the definitions related to CC ("Definitions" Section) as well as its comparison with related technologies ("Comparison of CC with related technologies" Section) in this work. We pointed out these issues to CCC Technical Advisory Council (TAC) in April 2021. However, the rare response from CCC TAC has generally raised more questions and concerns (Confidential Computing consortium 2020). We, therefore, pose it as an open challenge to the community. We emphasize the dire need for formal definitions for CC and believe that resolving the issues highlighted in this work would be the first step towards that. In this regard, we also provide some recommendations to achieve clarity and precision in the definitions as well as fair and scientific comparison among existing technologies. To the best of our knowledge, no other works have attempted to provide a security comparison of the technologies, so we focus on the CCC white papers and related literature. An attempt has been made to keep this paper self-contained by reproducing the original definitions, figure and table, whenever required, and to keep the paper simple and readable for broad readers from systems engineering, security and privacy, and legal communities, while still maintaining mathematical rigour.


This section presents a review of definitions related to CC by CCC TAC. All definitions by CCC TAC are informal. Formal definitions of security are essential for a systematic design of cryptosystems, as Katz and Lindell reinforce:

“If you don’t understand what you want to achieve, how can you possibly know when (or if) you have achieved it?” [Sect. 1.4.1, p. 15 in Katz and Lindell (2020)].

Unlike the traditional heuristic approach based on intuition, formal definitions also allow for rigorous proof of security. Moreover, formal definitions provide the basis for a meaningful comparison of cryptosystems, such as trade-offs between security and efficiency (Katz and Lindell 2020).

In the following subsections, we list some of the key issues related to definitions of terms related to CC by first providing CCC’s actual definitions, whenever available.

Confidential Computing (CC) and related technologies

CCC claims that CC is uniquely defined, while several other related technologies have multiple competing definitions:

“Unlike the term ‘confidential computing’, several of the terms used in the diagram have multiple competing definitions” [Sect. 4, p. 8 in Confidential Computing consortium (2021a)].

The diagram referred to here is the Venn diagram shown in Fig. 1.

We first analyze the claim of the unique definition of CC. This claim is based on the following definition by CCC:

“The protection of data in use by performing computation in a hardware-based Trusted Execution Environment” [Sect. 2.1, p. 5 in Confidential Computing consortium (2021a)]

In contrast to the above definition based on hardware-based Trusted Execution Environment (HW TEE), in CCC scope white paper, it is considered to be based on programmableFootnote 2 HW TEE [cf. Fig. 1 in Confidential Computing consortium (2021c)]. It is evident from Fig. 1 that the set of programmable HW TEEs (prog_HW_TEE) is a proper subset of the set of HW TEEs (HW_TEE), i.e.,

$$\begin{aligned} \texttt {prog\_HW\_TEE} \subset \texttt {HW\_TEE} \end{aligned}$$

Hence, the two definitions of CC within the CCC white papers are competing. Moreover, even the members of CCC do not agree on the definition of CC. For instance, researchers at Arm (member of CCC) define CC to include everything in the Venn diagram in Fig. 1 (Mulligan et al. 2021). Therefore, the unique definition claim of CCC is false.

Fig. 1
figure 1

Venn diagram, illustrating technologies for secure computation, produced by Confidential Computing Consortium (CCC) as a result of a survey (2021a)

We now analyze the claim about multiple competing definitions of other terms. In contrast to CC, other terms used in the figure are formally defined in the literature. For instance, HE is formally defined by Fontaine and Galand (2007) as:

Let \(\mathcal {M}\) (resp., \(\mathcal {C}\)) denote the set of plaintexts (resp., ciphertexts). An encryption scheme is said to be homomorphic if for any given encryption key k the encryption function E satisfies

$$\begin{aligned} \forall \ m_1,m_2 \in \mathcal {M}, \; E(m_1 \odot _\mathcal {M} m_2) \longleftarrow E(m_1) \odot _\mathcal {C} E(m_2) \end{aligned}$$

for some operators \(\odot _\mathcal {M}\) in \(\mathcal {M}\) and \(\odot _\mathcal {C}\) in \(\mathcal {C}\), where \(\longleftarrow\) means “can be directly computed from,” that is, without any intermediate decryption.

If (\(\mathcal {M}\), \(\odot _\mathcal {M}\)) and (\(\mathcal {C}\), \(\odot _\mathcal {C}\)) are groups, we have a group homomorphism. We say a scheme is additively homomorphic if we consider addition operators, and multiplicatively homomorphic if we consider multiplication operators.

Similar to HE, MPC is defined by Evans et al. (2018). Privacy-preserving computation, like secure computation, is a general term and is interpreted differently based on the privacy goals, such as input privacy or output privacy. Hence, the claim of CCC is not true.

Trusted Execution Environment (TEE)

CCC defines TEE as:

“An environment that provides a level of assurance of the following three properties:

  • Data confidentiality: Unauthorized entities cannot view data while it is in use within the TEE.

  • Data integrity: Unauthorized entities cannot add, remove, or alter data while it is in use within the TEE.

  • Code integrity: Unauthorized entities cannot add, remove, or alter code executing in the TEE” [Sect. 3.1, p.6 in Confidential Computing consortium (2021a)].

We observe the following issues in this definition:

  • This definition of TEE is quite vague. For example, it is unclear what is meant by “a level of assurance”, and it can be interpreted in various ways. Similarly, “data” is undefined and can be interpreted to mean all data or a well-defined subset of data. Moreover, no description of “unauthorized entities” is provided.

  • The definition is not precise enough to characterize TEEs. For example, all three properties are satisfied by HSMs also.

  • Both fundamental components of a security definition, according to Katz and Lindell (2020), are missing, i.e., the definition of TEE neither clearly defines what constitutes a successful attack, nor does it specify the threat model, i.e., (computational) power of the adversary, e.g., probabilistic polynomial time.

In summary, the definition of TEE is vague and incomplete. With such a definition, it may not be possible to classify an environment as a TEE reliably or to have a meaningful comparison among different TEE solutions from different vendors.

TEE environment

Although the term “TEE” is somewhat defined in CCC white paper, another term, “TEE environments”, is used and remains undefined (Confidential Computing consortium 2021a). Expanding the abbreviation TEE, it stands for “Trusted Execution Environment environments”. The two terms cannot be interpreted as synonyms because, in one place, they are used together:

“Attestation of TEEs and TEE environments” [Sect. 5.1, p. 10 in Confidential Computing consortium (2021a)]

The term “TEE environments” is also not defined in any of the references of the white paper (Confidential Computing consortium 2021a). Therefore, the difference between the two terms is not clear.

Hardware-based TEE

It is important to define HW TEE and contrast it with virtualized software TEE because one of the CC definitions is dependent on HW TEEs (Confidential Computing consortium 2021a). Given the CCC claim that these two sets are disjoint (Fig. 1), it should be possible to clearly and distinctly define the two terms. However, precise definitions of HW-based TEE and virtualized software TEE are missing. For instance, it is unclear whether hardware includes firmware.


Since one of the definitions of CC by CCC is based on programmable HW TEEs (Confidential Computing consortium 2021c), it is also important to clearly define programmability. However, it is not the case, and there are at least two different possible interpretations of programmability:

  • TEE can be programmed with arbitrary code.

  • TEE supports only a limited set of operations and is thus limited to specialized problems that can be framed in terms of supported operations.

It should be clarified that the interpretation of programmability is Turing-complete, i.e., arbitrary code can be run in a programmable TEE. Moreover, for completeness in Fig. 1, the programmable set should also be depicted for virtualized software TEEs since it is shown only for HW TEEs.


CCC defines attestation as:

“Attestation is the process by which one party, called a ‘Verifier’, assesses the trustworthiness of a potentially untrusted peer, i.e., the ‘Attester’” [Sect. 6, p. 14 in Confidential Computing consortium (2021a)].

Here, the definition is missing a vital party namely ‘Relying Party’, as defined in Birkholz et al. (2023). Moreover, the notion of measurement, which is a key component of attestation (Szefer 2018), is not explicit in the definition. A fundamental property of attestation is that the attested entity must not be able to lie about the state (i.e., code, configuration and data) that it is in. Hence, the definition of attestation should explicitly include some form of trusted measurements of both code and configuration of a TEE’s platform as well as the code that executes inside the TEE, its configuration and some TEE-held data.

Table 1 Summary of key issues in the definitions of terms related to CC, and recommendations for CCC

Attestation in CC

Compared to purely cryptographic technologies (such as Fully Homomorphic Encryption (FHE) and Secure Multi-Party Computation), CC using HW TEEs on commercial architectures has much more trust in hardware and software components (Szefer 2018). Hence, in HW TEEs, it is vital to attest that the hardware is up to date with the latest security features. Without attestation, TEEs do not provide better security guarantees than conventional computing under the adversary models considered in CC. This is a consequence of the fact that without attestation, a remote user cannot distinguish between a malicious platform and a genuine one. This holds even with alternatives of attestation, such as authentication. Therefore, the definition of CC is incomplete without the fundamental process of attestation.

CCC acknowledges the importance of attestation by devoting a complete section (Sect. 6) in the white paper (Confidential Computing consortium 2021a) to attestation and by stating:

“Any attack that could compromise the attestation of a TEE instance could lead to a workload or data being compromised in turn” [Sect. 5.2.1, p. 11 in Confidential Computing consortium (2021a)].

However, it is not reflected in the definition of CC.

In summary, the definitions by CCC are imprecise, incomplete and even conflicting. Table 1 provides a summary of issues and some recommendations.

Comparison of CC with related technologies

This section presents a review of the survey conducted by CCC TAC regarding the comparison of CC with other related technologies. One of the most important criteria—threat model—for the security comparison of technologies is not specified by CCC. Moreover, only a few references are provided by CCC on the survey. The references provided are too broad (such as Wikipedia pages) and unreviewed (such as blog posts). Additionally, wherever provided, argumentation and reasoning are generally poor. Hence, there is insufficient scientific evidence, in general, for a reader to trust the survey results, e.g., figures and tables.

In the following, we present some of the key issues concerning the comparison of CC with related technologies:

  1. 1.

    One of the most important criteria for any meaningful comparison of security properties is the specification of the threat model. Unlike TEEs, neither the hardware nor the processor manufacturer needs to be trustedFootnote 3 in FHE (Gentry 2009). Among the software privilege levels, at least one of the application, operating system or hypervisor needs to be trusted in the commercial TEE solutions available, whereas none of these needs to be trusted in FHE. Therefore, there is not a TCB anymore in FHE in some sense. On the contrary, any bug or vulnerability in the TCB in TEEs can be exploited to nullify the security protections, e.g., System Management Mode (SMM)-based rootkits (Embleton et al. 2013) and platform management engine-based attacks. Additionally, TEE users have to trust the code running as part of the TCB, which is often proprietary, notably for the security engine, with no runtime monitoring or reporting capabilities, leading to security through obscurity. Typically, side channels are not a part of the threat model of commercial TEEs, whereas in FHE plaintext information is not available anywhere on the system that could leak out (Szefer 2018). Therefore, with an unspecified threat model in Sect. 4.1, a security comparison by CCC (2021a) shown in Table 2 has limited value.

  2. 2.

    CCC claims that TPM is a TEE (Confidential Computing consortium 2021a). This claim is made by showing TPM completely within TEEs in the Venn diagram shown in Fig. 1, where according to CCC, the elements of sets are existing definitions of various concepts (Confidential Computing Consortium 2020). Although there is a disclaimer about multiple competing definitions of the terms, no supporting evidence, reference or argument is provided that justifies or even implies that all TPMs are TEEs. Assuming this claim to be true, TPM must satisfy the CCC definition of TEEs, i.e., satisfy the three properties of data integrity, data confidentiality and code integrity. However, this is contradicted by Table 2 in CCC white paper itself (Confidential Computing consortium 2021a), where it is shown that TPM can provide integrity and confidentiality for keys only, as opposed to arbitrary data. The clear contradiction to the claim is further confirmed by the statement of Dave Thaler, the chair of CCC TAC, in one of the CCC webinars (2020d): “If something does not have a Y, Y, Y (each Y corresponding to ‘Yes’ for the properties data confidentiality, data integrity, and code integrity), then we don’t call it a TEE, we call it something else.” More formally, according to the definition of TEE by CCC, each element of the TEE set should satisfy the three properties. We represent this as follows:

    $$\begin{aligned} TEE ={} & {} \{ x: (x \in DataConf) \wedge (x \in DataInt) \nonumber \\{} & {} \wedge (x \in CodeInt) \} \end{aligned}$$

    where DataConf, DataInt and CodeInt represent the sets of technologies satisfying data confidentiality, data integrity and code integrity, respectively. Now, from Fig. 1 by CCC, TPM is a proper subset of TEE, i.e.,

    $$\begin{aligned} TPM \subset TEE \end{aligned}$$

    Since TPM is a subset of TEE, each element of TPM should also satisfy the three properties of TEE. This contradicts Table 2 by CCC, where TPM provides confidentiality and integrity for keys only, as opposed to TEE which provides confidentiality and integrity for arbitrary data. Hence, CCC literature itself contradicts the claim of TPM as a TEE.

  3. 3.

    The only place in the CCC white papers where some argumentation is provided is related to Table 2 in Sect. 4.1 in Confidential Computing Consortium (2021a). Here we list a couple of issues related to Table 2:

    • Although some reasoning is provided in Sect. 4.1 for TPM, it does not trivially lead to the results concluded for all Secure Elements in Table 2. Whatever is reasoned about TPM cannot be generalized to all Secure Elements without further reasoning. A logical way of reasoning would be to justify it for Secure Element, and then it can be applied to TPM as a special case.

    • We argue that the comparison criteria in Table 2 are sometimes misleading. A “No” does not necessarily mean that technology offers lower security than a “Yes”. It may be the case that the property is not relevant. For example, attestability may not be required for HE for semi-honest adversaries.

  4. 4.

    Trusted Computing is a related technology that is often confused with CC. For example, some authors, such as Costan et al. (2016, 2017a, 2017b) use Trusted Computing as a synonym for CC (Ahmad-Reza Sadeghi 2021). Similarly, the Wikipedia page for Trusted Computing states, “Trusted Computing, also often referred to as Confidential Computing (2021).” To avoid confusion, it is important to clearly distinguish CC from Trusted Computing, whereas CCC does not mention Trusted Computing in white papers.

  5. 5.

    It is not clear why related technologies, such as HSMs (Anderson 2020), MPC (Evans et al. 2018) and Zero-Knowledge Proofs are not considered for a fair comparison in Sect. 4 in Confidential Computing consortium (2021a).

  6. 6.

    CCC claims that ambiguity in definitions of HE and MPC leads to an intersection between the two sets in Fig. 1 (Confidential Computing consortium 2021a). However, the ambiguity is not specified. Similarly, the reasoning for the overlap between TPM and HW TEEs in Fig. 1 is not presented. Such ambiguities should be justified with precise definitions, references and arguments.

Table 2 Comparison of security properties of hardware-based trusted execution environment (HW TEE), Homomorphic encryption (HE) and trusted platform module (TPM) by CCC (cf. Table 1 in Confidential Computing consortium (2021a)


Despite the undeniable importance of formal definitions, CC and its related terms still have ambiguous, incomplete, and conflicting definitions. We demonstrated this with the help of concrete examples of various terms, including TEEs, hardware-based TEEs and attestation. We also demonstrated that the security comparison among the various technologies presented by CCC without a clear threat model is neither fair nor scientific. We also highlighted other issues, such as lack of scientific evidence and argumentation in the comparison. We provided some initial recommendations for fixing definitions as well as comparison. However, formal definitions of the terminology related to CC and a detailed scientific survey of the technologies for a fair comparison remains a crucial area to be explored in the future. We are actively engaging with the CCC TAC to address the identified issues.

Availability of data and materials

Not applicable.


  1. Typically with less technical knowledge.

  2. The definition of programmable itself in Confidential Computing consortium (2021a) is ambiguous (more details in "Programmability" Section). However, our argument still holds whatever definition of programmable is considered.

  3. The discussion here is not relevant for availability because none of the commercial TEEs currently address availability issues.



Confidential Computing


Confidential Computing Consortium


General Data Protection Regulation


Fully Homomorphic Encryption


Homomorphic Encryption


Hardware Security Module


Hardware-based Trusted Execution Environment


Secure Multi-Party Computation


Technical Advisory Council


Trusted Execution Environment


Trusted Platform Module


Download references


We would like to thank Andrey Brito, Mark F. Novak and Satyadharma Tirtarasa for their feedback on the initial drafts of the paper.


Funded by DFG Grants 389792660 as part of TRR 248—CPEC and 390696704 as part of CeTI.

Author information

Authors and Affiliations



MUS created the initial draft of the paper, based on extensive discussions on each point with CF. CF provided key insights. Both authors read and approved the final manuscript

Authors’ information

Muhammad Usama Sardar Since October 2021, he is a Research Associate at TU Dresden. From 2017 until 2021, he was recipient of the prestigious DAAD research grant for his Ph.D. at TU Dresden. His current research interests include the formal specification and verification of the remote attestation process in Trusted Execution Environments, with a special focus on Intel SGX and TDX. He is also a tutor for the master’s courses: Systems Engineering 1, Systems Engineering 2, Principles of Dependable Systems and Software Fault Tolerance. He is also serving as a volunteer at CAVlinks. He has received best poster award in Postgraduate category in the International Conference on Digital Futures and Transformative Technologies (ICoDT2) in 2021, South Asia Triple Helix Association (SATHA) Innovation Award in 2018, best researcher of the year award in System Analysis and Verification lab in Pakistan in 2017, and best speaker awards at Workshop on Applications in ASIC Design (December 2016) and Workshop on Recent Trends in Theorem Proving (April 2016). His research work has resulted in publications at top international forums, such as the Journal of Parallel and Distributed Computing, the NASA Formal Methods Symposium, and Journal of Automated Reasoning.

Christof Fetzer has received his diploma in Computer Science from the University of Kaiserslautern, Germany (Dec. 1992) and his PhD from UC San Diego (March 1997). He joined AT&T Labs-Research in August 1999 and had been a principal member of technical staff until March 2004. Since April 2004 he heads the endowed chair (Heinz-Nixdorf endowment) in Systems Engineering in the Computer Science Department at TU Dresden. He is the chair of the Distributed Systems Engineering International Masters Program at the Computer Science Department. He has published over 150 research papers in the field of dependable distributed systems. Prof. Dr. Fetzer has been member of more than 50 program committees, has won three best paper awards (DEBS2013, LISA2013, SRDS2014), his PhD students have won two best student paper awards (IEEE Cloud 2014, DSN2015), and the EuroSys Roger Needham Award 2014. As a student, he received a two-year scholarship from the DAAD and won two best student paper awards (SRDS and DSN). He was a finalist of the 1998 Council of Graduate Schools/UMI distinguished dissertation award and received an IEE mather premium in 1999.

Corresponding author

Correspondence to Muhammad Usama Sardar.

Ethics declarations

Ethics approval and consent to participate

Not applicable.

Competing interests

All authors read and approved the final manuscript

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Sardar, M.U., Fetzer, C. Confidential computing and related technologies: a critical review. Cybersecurity 6, 10 (2023).

Download citation

  • Received:

  • Accepted:

  • Published:

  • DOI: