Confidential Computing for Health Data Explained
Confidential computing protects health data while it is being processed by running the computation inside a hardware-isolated trusted execution environment (TEE), a sealed region of a processor whose memory is encrypted and cannot be read by the host operating system, the hypervisor, or the cloud operator. Combined with remote attestation, it lets a data custodian verify exactly which code will touch sensitive records before releasing them. For health research, it closes the last gap in encryption coverage: data at rest and in transit were already protected, and confidential computing protects data in use.
Why confidential computing matters for health data now
Health data custodians have long been able to encrypt records on disk and on the network. The weak point has always been the moment of analysis. To run a regression or train a model, data has to be decrypted into memory, and at that point anyone with administrative control of the machine can, in principle, read it. For a hospital running its own servers, that risk sits with trusted staff. For a biobank or a ministry of health running workloads in a public cloud, it extends to the cloud provider’s infrastructure and personnel.
Three pressures have pushed this from an academic concern into procurement checklists. First, regulation now expects technical controls rather than contractual promises alone. The European Health Data Space (EHDS) regulation requires secondary use of health data to happen inside secure processing environments, and the General Data Protection Regulation (GDPR) treats health and genetic data as special category data that demands state-of-the-art safeguards. Second, sovereignty requirements increasingly ask whether a foreign cloud operator could be compelled to hand over data. Third, the 2026 UK Biobank incident showed that the most damaging exposures do not always come from attackers. They can come from ordinary workflows that were never designed to stop approved users from taking data home.
Confidential computing answers the first two pressures directly. It does not, on its own, answer the third, and that distinction shapes how it should be used.
How trusted execution environments work
The Confidential Computing Consortium, a Linux Foundation project, defines confidential computing as the protection of data in use by performing computation in a hardware-based, attested TEE. Four building blocks make that definition concrete.
Hardware isolation
The processor reserves a protected region of memory for the workload. Data inside that region is encrypted with keys held in the processor itself, so a memory dump taken by the host shows only ciphertext. Current implementations include Intel Software Guard Extensions (SGX), which isolates individual application enclaves; Intel Trust Domain Extensions (TDX) and AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), which isolate entire virtual machines; and Arm Confidential Compute Architecture (CCA). GPU vendors have added confidential modes as well, which matters for model training on imaging or genomic data.
Remote attestation
Before a custodian releases a decryption key, the TEE produces a signed measurement of the code and configuration it is running. The custodian, or an attestation service it trusts, checks that measurement against an approved value. If the code has changed by a single byte, the key is not released. This is what turns hardware isolation into governance: the data owner can bind access to a specific, reviewed analysis image.
Sealed keys and secrets
Keys are provisioned only after successful attestation and never leave the protected boundary in plaintext. Key management services can be held by the data custodian rather than the cloud provider, which keeps the custodian in control even when the hardware belongs to someone else.
Cloud availability
All major cloud providers now offer confidential virtual machines or enclave services, which means health organizations can adopt the technology without buying specialist hardware. The practical question is no longer whether confidential computing exists, but where in a research architecture it adds real protection.
The federation angle: TEEs and TREs solve different problems
The acronyms are one letter apart, and they are often confused. A trusted execution environment is a hardware feature that protects a single computation. A Trusted Research Environment (TRE) is a governed platform that controls who can access data, what they can run, and what results can leave. The ONS Five Safes framework (safe people, safe projects, safe settings, safe data, safe outputs) describes the TRE’s job. A TEE strengthens one of those five, safe settings, and has nothing to say about the other four.
This is where the architecture of the TRE matters more than the chip. A centralized TRE that copies data from many hospitals into one cloud account can wrap its compute in TEEs, but the data still had to move, the central store still exists, and an approved researcher can still export results that were never checked. A federated Trusted Research Environment starts from a different premise: compute travels to each custodian, data never leaves the source, and every output passes an airlock review before release. Federation removes the central copy. Confidential computing then hardens the compute node inside each custodian’s boundary, protecting data in use even from the infrastructure operator at that site.
Put simply, federation decides where data lives and what can leave. Confidential computing decides who can see data while it is being processed. Programs that need both, for example a national genomics program running on a hyperscale cloud in its own jurisdiction, get the strongest result by layering them rather than choosing one.
Confidential computing compared with other protections
| Protection | What it protects | Performance cost | What it does not cover |
|---|---|---|---|
| Encryption at rest and in transit | Stored files and network traffic | Negligible | Data while it is being analyzed |
| Confidential computing (TEE) | Data in use, including from the host and cloud operator | Low to moderate for most workloads | What an authorized user does with results; hardware side-channel risks |
| Homomorphic encryption | Data in use, mathematically, with no trusted hardware | Very high; limited operations | Output disclosure; practical for narrow computations only |
| Federated TRE | Data location, access, and outputs across many custodians | Depends on the network of sites | Memory-level protection at each node unless paired with a TEE |
| Automated airlock and disclosure control | What leaves the environment | Seconds to minutes per output | Protection during computation |
The table shows why no single control is sufficient. Confidential computing is strong on the one axis the others leave open, and weak on the axis where most real-world health data exposures actually happen: outputs.
A practical framework for adopting confidential computing
For a biobank, hospital network, or national program evaluating confidential computing, the following sequence keeps the investment tied to real risk.
- Map the threat you are addressing. If the concern is the cloud operator or a compromised host, TEEs are a direct fit. If the concern is approved users exporting data, the answer is architecture and output control, and TEEs are secondary.
- Choose the isolation granularity. Confidential virtual machines are the easiest path for existing analysis tools such as R, Python, and workflow engines. Application enclaves offer a smaller trusted code base but usually require code changes.
- Put attestation under custodian control. The organization that owns the data should decide which measurements are approved and should hold the keys. Attestation delegated entirely to a vendor weakens the guarantee.
- Bind attestation to approved workflows. Link each attested image to a data access committee approval, so that the code a committee reviewed is the code that runs.
- Keep output checking in place. Every aggregate, model, or file leaving the environment should still pass statistical disclosure control. A TEE does not know whether a table contains a cell with three patients.
- Plan for patching. TEE vendors issue microcode and firmware updates in response to research findings. Budget for regular re-attestation after updates.
Real-world context
National genomic medicine programs illustrate why layering matters. Genomics England, a Lifebit customer, operates a research environment for whole-genome data from participants in England, and its governance model depends on approved researchers working inside a controlled environment with outputs reviewed before release. That model is a Five Safes design first. Hardware-level protection of data in use is a complementary control that programs of this kind can add to compute nodes, but it would not replace access governance or output review.
Across Europe, the EHDS secure processing environment requirement is pushing health data access bodies toward the same conclusion. Regulators describe outcomes (no unauthorized access, no unreviewed export, full audit) rather than specific chips. Confidential computing is one way to evidence the “no unauthorized access” outcome at the infrastructure layer. Federation and airlocks evidence the rest.
Common pitfalls and objections
“TEEs make the TRE unnecessary”
They do not. A TEE protects a computation from the machine it runs on. It does not vet researchers, approve projects, or check outputs. Treating it as a replacement for a TRE confuses a component with a system.
“Side-channel attacks make TEEs useless”
Published attacks against earlier enclave designs, such as the 2018 Foreshadow research on Intel SGX, were real and led to hardware and firmware fixes. The fair conclusion is that TEEs reduce risk substantially but are not absolute, which is exactly why they should sit inside a defense-in-depth design rather than carry the whole load.
“Performance will be unusable for genomics”
For confidential virtual machines, overhead on typical analysis workloads is modest, because memory encryption is performed in hardware. Workloads with heavy input and output traffic need benchmarking, but the cost is far lower than cryptographic alternatives such as fully homomorphic encryption.
“Attestation is too complex to operate”
It is operationally new for most research IT teams. The fix is to automate it as part of the workflow approval pipeline, not to skip it. An unattested TEE provides much weaker assurance.
What to do next
Start with the architecture question before the hardware question. If data is still being copied into a central store, confidential computing will harden that store but will not remove the risks that come with it. A federated design, as described in Lifebit’s overview of the federated Trusted Research Environment, removes the central copy first. From there, add TEEs to compute nodes where the threat model includes the infrastructure operator, and keep the automated airlock as the control on everything that leaves. Teams comparing cryptographic options should also review how secure multi-party computation fits alongside hardware-based approaches.
Frequently asked questions
What is confidential computing in healthcare?
Confidential computing is the protection of health data while it is being processed, by running analysis inside a hardware-isolated trusted execution environment whose memory is encrypted and cannot be read by the host system or cloud operator. It complements encryption at rest and in transit.
What is the difference between a TEE and a TRE?
A trusted execution environment (TEE) is a processor feature that protects a single computation. A Trusted Research Environment (TRE) is a governed platform that controls researcher access, approved projects, and output release. A TEE can strengthen a TRE’s compute layer but cannot replace its governance.
What is remote attestation?
Remote attestation is a signed report from the TEE proving which code and configuration it is running. The data custodian checks this report against an approved value before releasing decryption keys, so only reviewed code can access the data.
Does confidential computing prevent approved researchers from exporting data?
No. It protects data from the infrastructure, not from authorized users. Preventing unreviewed export requires output controls such as an automated airlock and statistical disclosure control, ideally within a federated architecture where data stays at the source.
Is confidential computing compatible with a federated TRE?
Yes. Federation keeps data at each custodian and controls what leaves. Confidential computing can be added to compute nodes at each site to protect data in use from the local infrastructure operator. The two address different layers and work well together.
How much does confidential computing slow down analysis?
For confidential virtual machines, overhead on typical statistical and machine learning workloads is generally modest because memory encryption happens in hardware. Input and output heavy pipelines should be benchmarked before deployment.