Trusted Execution Environments for Trusted Research Environments

Introduction¶

Trusted execution environments provide an unrivaled level of privacy when using a computer. They fill an critical security gap, by keeping data secure while in use through encryption. This is in addition to existing methods to encrypt data at rest and while in transit.

Trusted research environments play an important role in research, allowing researchers to work with sensitive data in a way that is effective, efficient and secure. Integrating TEEs in to TREs could open new possibilities for trusted research, both in terms of the kinds of data we can use for research and for where that research can be conducted. In particular, the strong isolation of a TEE from the rest of the computer could enable us to deploy TREs to third-party infrastructure (such as supercomputers or cloud services) or run them on untrusted devices (such as personal laptops).

However, using TEEs is not trivial and requires careful design of policy, compliance checks and investment in hardware. Furthermore, though the isolation of a TEE from the rest of the computer is strong, all processes in the TEE must be trusted, so we must think critically about what a TEE does and does not protect you against. Here we evaluate the situations where TEEs add value to TREs considering the costs against the benefits for TRE security.

Trusted Execution Environments¶

A TEE is a reserved portion of hardware (CPU, memory and possibly GPU) that is cryptographically segregated from the rest of the system (the host, and any other TEEs). The contents of a TEE are unable to be read, or modified by any processes outside of the TEE, including those running on the same host. TEEs are the enabling technology for confidential computing The Confidential Computing Consortium, 2022. They operate by selectively encrypting sections of memory belonging to TEEs with enclave-unique keys, which ensure encrypted memory can only be read as plain text by the correct TEE. Implementations vary as to how this is achieved but generally involve some kind of memory address virtualisation or remapping in addition to encryption. A TEE can prove its state (and hence that it has been configured correctly) though an attestation process, so its users can make an informed decision whether to trust it or not.

Both memory encryption and gathering evidence for attestation are performed by a trusted secure processor. This is a section of the CPU dedicated to confidential computing functions and enforcing the security of TEEs. It provides an API for managing the TEE platform and enclaves for example, reporting firmware versions, creating an enclave, generating attestation evidence. However, it cannot be arbitrarily controlled by the host to bypass enclave isolation for instance, decrypting TEE memory outside of the enclave or returning enclave encryption keys. The secure processor therefore plays a critical role in the operation of a TEE.

TEE security¶

TEEs provide very strong, cryptographic isolation between the enclave and the host. Memory encryption and address remapping ensure TEE processes are confidential and their memory cannot be read in plain text outside of the enclave. This confidentiality includes privileged users on the host OS or hypervisor.

A TEE implementation may also protect against some physical, hardware-based attacks such as reading memory directly (bypassing the CPU), or malicious code running early in the boot process. Furthermore, as the lifecycle of a TEE and the attestation process do not depend on trust in the host, a TEE remains secure even in the case of the host OS, hypervisor, software, drivers or firmware being compromised.

The TCB of a TEE can vary based on the design of the TEE. However, it will always exclude the host OS and any hypervisor as the TEE is cryptographically segregated from these and they play no role in attestation The host CPU, and its firmware and microcode, are critical to the security of a TEE, and so are in the TCB. They form the hardware root of trust. The CPU and CPU manufacturer are therefore the root of the chain of trust for the entire TEE and ultimately you must trust these organisation and their products. An overview of the TCB and hardware root of trust are shown in Figure 1.

TEEs don’t address vulnerabilities of code or processes inside the TEE. Malicious software (including a guest OS) inside an enclave may still have access to secrets and be able to exploit these or expose them outside the TEE.

Similarly, TEEs do not protect against users able to interact software inside a TEE, such as an OS or API. Users may be able to use their privileges, or exploit a vulnerable software inside the TEE, to access or leak sensitive data. TEEs do not, therefore, rule out the need for security best practices regarding user access and the application running inside the enclave.

Advanced side-channel, physical-access attacks have been use to expose TEE secrets. Proven attacks include tee.fail Chuang et al., 2026 and wiretap.fail Seto et al., 2025. Another class of attacks, which modify communications between CPU and memory on the memory bus, have also been demonstrated BadRAM De Meulemeester et al., 2025, Battering RAM De Meulemeester et al., 2026. One attack of this kind, DDRop De Meulemeester et al., 2026 has been shown to be able to corrupt memory in an Intel TDX CVM, enabling a debug mode where CVM memory can be obtained in plaintext by the hypervisor.

Roles and entities¶

The language used to describe TRE systems varies. To help clarify the recommendations the following roles and entity definitions are used.

Entities¶

Roles¶

Recommendations¶

By considering the design of TREs and the scope of TEEs protection we have arrived at the following situations where TEEs add substantial value to TREs and should be considered.

1. When strong isolation from the host is required¶

Providing a way for compute to be run on an untrusted host, or host with untrusted users, is the central goal of confidential computing. This aligns well with many existing TRE scenarios, particularly where TREs are deployed to systems not entirely dedicated to trusted research (for example, local HPC or private cloud), or where a TRE is deployed to a third-party’s system. In these cases, although there is likely a high level of trust in the host, protection from attacks targeting the host or vulnerabilities on the host infrastructure is valuable. Only when the same party holds the TRE operator and infrastructure operator roles and the TRE infrastructure is dedicated (that is, it isn’t used for non-sensitive work) is isolation from the host not a strong benefit.

1.a. TRE operator and infrastructure operator are different parties¶

When the TRE operator and infrastructure operator roles are not held by the same party, the TRE infrastructure is not controlled by the TRE operator. The infrastructure operator will have a high degree of privilege and access to the TRE infrastructure, which potentially allows them to observe sensitive processes in breach of TRE governance. The cryptographic isolation of a TRE from the TRE infrastructure using a TEE ensures that the infrastructure operator is not able to access data in use, whether maliciously or accidentically.

Precisely how important this is will depend on the trust in the infrastructure operator and the guarantees they provide. For example, large cloud providers rely on their ability to isolate tenant from each other, and from the cloud provider’s staff to operate. Their processes are documented and audited as part of their certification and compliance with information security standards, for example AWS, Azure and GCP. In particular, the ISO/IEC 27017 standard (part of the ISO/IEC 27000 family) focuses on the challenges of cloud services including isolating tenants environments.

However, even in cases where there is absolute trust in the infrastructure operator TREs are still vulnerable to attack from a compromised TRE infrastructure. Other scenarios where TEEs provide valuable isolation to TREs more appropriate solution are,

• Satellite TREs using a shared responsibility model (such as FRIDGE deployed on HPC)

• Federated research where one TRE operator runs a workload or deploys an ephemeral TRE within another TRE

1.b. TRE infrastructure is not exclusive¶

When the TRE infrastructure is not used exclusively for trusted research, the risk of non-authorised administrators accessing sensitive data (whether accidentally or maliciously) is raised. In this scenario, different rules and processes for the administration of sensitive and non-sensitive environments could lead to errors. An example of this would be an HPC system which provides a service for both sensitive and non-sensitive workloads. This model could be particularly effective on a private cloud, a TRE project would be allocated a CVM while non-sensitive work is conducted with conventional VMs.

2. When using low trust devices¶

Another possible scenario is low-trust, end-user devices or “bring your own compute”. As a TEE does not depend on trust in the host operating system or software, you can use a TEE to run trusted computation on an untrusted device.

For example, individual laptops or institutional servers which are not designed for secure, multi-tenant use.^[1] In the extreme, widespread support of TEEs could allow distributed trusted research across untrusted devices, which would currently be far too risky to consider. Perhaps this could scale to large pools of workers similarly to how non-sensitive distributed research has been conducted by Folding@Home or SETI@Home.

3. When highly sensitive data must be used¶

When dealing with highly-sensitive data, computer security is not the only option for protecting against unauthorised disclosure. Instead, in line with the Five Safes framework Ritchie, 2003, a more holistic approach to security should be taken and the data should be modified to reduce disclosure risk if possible (for example pseudononymisation, data minimisation or the use of synthetic or dummy data).

When highly-sensitive data must be used, however, it is appropriate to reduce risk in other dimensions. In these cases, the use of TEEs may be beneficial. It would offer most benefit when dealing with data which would encourage high-motivated attackers to launch sophisticated attacks targeted at the TRE infrastructure. For example, compromising the host OS, BIOS or a social engineering attack targeting the infrastructure operator.

Considerations¶

The above recommendations outline the situations when TEEs add value to a TRE, in terms of the TREs design and usage. However, the decision of whether to use TEEs must also include a consideration of the costs involved, so that an assessment of the net benefit can be made.

Hardware support and availability¶

Although confidential computing is not new, it has not reached a maturity where all or most devices can be used to provision TEEs. For CVM solutions, only the most recent, perhaps two or three generations, of devices will have support. Furthermore, as the technology is still evolving, older CPU generations may lack the features, and enhanced security, or more modern processors. TEE support is often only available in datacentre CPUs and not present on consumer devices.

Integration of devices into TEEs is not generally solved, although the latest generations of GPUs from Nvidia and AMD can be incorporated into a TEE. For many, it may therefore not be possible to build on TEEs without a large investment in new hardware.

TEE and host configuration¶

In addition to capital investment in hardware, an organisation implementing confidential computing on-premises will need to perform the necessary configuration and setup. Vendor guides give an impression of the work involved, for example these setup guides from AMD and Intel. This may include,

• BIOS (UEFI) configuration

• Installing a compatible Host OS

• Host OS configuration

• Guest OS configuration (for example, building a minimal guest image with necessary tools)

• Configuring other trusted hardware, such as GPUs or NICs

Configuration costs may be avoided by using a third-party, such as a cloud computing provider, to provision TEEs as a service. This may however be a trade in upfront expense for larger operational expenses.

TRE design and implementation cost¶

There is a tremendous diversity in TRE implementations. It is still common for organisations to build or commission their own TRE and they are often designed for the needs of one organisation. As such, despite the emergence of archetypes and common tools, there is no standard TRE implementation or architecture. This makes it difficult to make blanket statements about how TEEs should be used in TRE implementations. Incorporating TEEs into a TRE implementation is not a trivial change.

TRE builders should take care to consider how and where to use confidential computing to protect sensitive workloads inside a TRE A key consideration is how the use of a TEE affects the size of the TCB. The focus for TRE developers should be to,

• Move sensitive processes into TEEs first

• Minimise the size of TEEs (and hence the TCB)

Moving large, monolithic TRE components into a TEE may not produce much benefit. As explained above, all code moved into a TEE remains part of the TCB and vulnerabilities in the TCB will compromise security, irrespective of the secure TEE boundary. For example, moving large “workspace VMs” to CVMs, while providing isolation from the host, will not provide any mitigation for vulnerabilities in the workspace OS or software.

With a clear design the development effort or introducing TEEs can be assessed. In some cases, it may be a simple task of shifting existing entities from VMs to CVMs, or pods from a conventional runner to confidential containers. However, in other cases it may require significant code changes like the splitting of confidential and non-confidential code, building on CC APIs, or major architectural changes to the TRE implementation.

Attestation infrastructure¶

Enabling secure virtualisation should give a high level of confidentiality from the host, whether or not the state of a TEE is verified through attestation. However, by skipping the attestation, systems which interact with the TEE (and may rely on it being secure and confidential) cannot determine where the TEE is trustworthy.^[2] The Confidential Computing Consortium (2026) outlines levels of adoption of confidential computing, emphasising the importance of attestation in verifying that a TEE is trustworthy, and further the integration of attestation into workload-level logic.

In order to effectively use confidential computing, a suitable policy, which attestation reports will be measured against, must be developed and maintained. While it would be possible for attestation reports to be inspected manually, it is more likely that a relying party will establish infrastructure to handle reports. Furthermore, processes to react to reports, for example excluding non-compliant TEEs from running sensitive workloads, must be implemented. It would be best for these processes to be automated, which adds to the complexity of the attestation infrastructure. This aspect could become a significant part of the task of incorporating TEEs into a TRE implementation, especially if attestation is conducted on a per-job basis and includes verification of the workload itself The Confidential Computing Consortium, 2026.

A number of projects are beginning to build open source tools for managing TEEs (VirTEE, Islet) handling attestation (VERASION) and abstracting TEEs for containers and applications (dstack, Ernax). As these tools mature the use of TEEs will become easier and more accessible.

Ongoing management and support¶

Cost of the upkeep associated with maintaining an applying an attestation policy. The enforcement of policy can be automated, however, there will unavoidably be a cost in reviewing the policy and keeping it up to date as new hardware is released and if vulnerabilities are discovered in older TEE implementations.

Vendor lock-in and portability¶

Introducing TEE support may involve building on vendor-specific hardware, services and APIs. In these cases, the benefits of TEEs must be balanced against the long-term ability to migrate a TRE instance and the short-term potential for other organisations to deploy your TRE in their own context. Appetites for lock-in may greatly differ; some organisations may have longstanding good relationships with a vendor, or may have no ambition for their TRE to be deployed by others.

Cloud platforms may provide a more generic interface to deploying CVMs. However, that comes at the cost of significant buy-in with the cloud platform as a whole. Some open source projects focus on abstracting TEE management, such as Open Enclave SDK, providing a generic interface to multiple TEE implementations. As these mature they may make migration between vendors or using multiple vendors in a single system easier.

Furthermore, attestation reports will contain vendor-specific fields, related to that vendor’s suite of confidential computing capabilities. Therefore, incorporating new hardware (in particular hardware from a new vendor) or migrating to different hardware will likely require updating attestation policy.

Discussion¶

To understand whether TEEs add value to a TRE, it is critical to remember that TEEs protect data in use by cryptographically isolating workloads. This is protection against privileged users on the host, and sophisticated attacks aimed at the OS, hypervisor or BIOS. Only in situations where attack from the host is a viable risk do TEEs provide a substantial benefit.

As the administrators of TREs and the infrastructure they run on have, in principle, access to sensitive data it is common to use policy and training to reduce the risk of unauthorised data access or disclosure. It is common to have a high level of trust in the infrastructure operator, in which case a TEE will not significantly reduce risk. In these cases, while the use of TEEs would reduce the attack surface and make a TRE more secure, the cost and added complexity may not be justified. Effort would be better spent addressing the more likely risks before considering TEEs.

Beyond the effective and appropriate use of TEEs within a TRE implementation there are a number of key practical considerations. Most importantly, TEEs are not a simple “drop-in” solution and require investment in hardware, configuration and building the supporting infrastructure to handle attestation reports. Furthermore, support for TEEs is far from universal and requires recent hardware and modern BIOS and OS. For many organisations this will mean purchasing and provisioning new systems. Therefore, while TEEs can, in some situations, significantly improve TRE security it is possible that time spent on integrating TEEs may be wasted as access to supported systems will be low.

The situations where we recommend the use of TEEs to enhance TRE security are,

1. Strong isolation from the host is needed

   1. Third party system (TRE hosted by another org, public cloud)

   2. Multi-use system (private cloud etc.)

2. Low-trust devices or bring-your-own-compute (TREs on laptops, mesh TREs)

3. Extreme data sensitivity

Perhaps the most common instance where a TEE would add value to a TRE is when the TRE operator and infrastructure operator are different parties. This could be a TRE hosted on a public cloud, a TRE hosted by a third-party contractor, or a satellite TRE. Additionally, where highly sensitive data must be used, TEEs can play an important role in protecting data from motivated attackers who are able to exploit vulnerabilities in the TRE infrastructure.

More excitingly, TEEs could open new models of TRE and new approaches to trusted research where untrusted devices are targeted. Without confidential computing, we need to ensure a host system is trustworthy and secure to be used. However, as trust in a TEE does not depend on trust in the host it is possible, in principle, to run trusted workloads securely on compromised and insecure devices.

The use of TEEs could then widen access to TREs and make deploying TREs easier. This idea is already being explored by the ManaTEE project. It would also be possible to distribute trusted research to the public, dependent on confidential computing capability becoming common on consumer devices. This could be applied to problems which scale well to large numbers of workers, or to participants contributing to research running analysis locally their own data.