What are Trusted Execution Environments & Comparing the Top 5 TEEs.

Introduction to Trusted Execution Environments

Trusted Execution Environments (TEEs) are one of the most widely deployed security primitives in modern computing, and also one of the least understood outside security circles. They are the reason you can run sensitive code on a cloud provider you do not own, pass cryptographic operations to a chip you did not manufacture, and verify that a compute task ran on the right hardware without needing to see the hardware yourself.

At SpaceComputer, we are moving secure compute on TEEs to orbit, and one of the core hardware design decisions is which TEE to use, with consideration to how it performs in orbit. This piece walks through what TEEs are, how the different major TEE options compare, and what their limitations on Earth versus in low Earth orbit (LEO).

What is a TEE? What are TEEs used for?

What is a TEE?

A TEE is a protected area of a computer's processor where sensitive code can run in isolation from the rest of the system. When code runs inside a TEE, the processor itself prevents other software on the same machine, including the operating system, from reading or tampering with what is happening inside.

A TEE also produces remote attestation: proof that a specific piece of software is running, unmodified, inside an actual TEE on a specific piece of hardware. Attestation is what lets someone who does not own the machine confirm that their code is running where and how they expect.

What are TEEs used for?  

TEEs are useful anywhere a workload needs to run on infrastructure the workload owner does not fully control. Common applications include confidential cloud compute, privacy-preserving machine learning, custodial key management, and multi-party computation where no single party sees the full input.

TEEs fall into two families: process-based, which isolates a single application or function, and VM-based, which isolates an entire virtual machine. We broke down the tradeoffs between these two families in this post. 

The short version: process-based keeps the amount of trusted code small but requires application rewrites. VM-based runs unmodified workloads at the cost of a much larger trust boundary.

Comparing Common TEEs Across the Industry 

The commercial TEE landscape is dominated by a handful of platforms. Each makes different tradeoffs in auditability, vendor dependence, and where cryptographic secrets come from. The comparison below is adapted from Table 1 of the Space Fabric paper.

Every TEE has a trust assumption, something the verifier has to believe is true for the security argument to hold. Good design minimizes these assumptions and makes the ones that remain auditable.

Intel SGX roots its attestation in a signing key that Intel provisions into the processor during manufacturing. Verifiers trust Intel to have held that key securely and erased its copy. SGX is process-based, isolating individual enclaves within an application.

Intel TDX extends the SGX model to entire virtual machines and uses the same underlying Intel attestation infrastructure. Where SGX protects a single enclave, TDX protects an entire confidential VM. Both are fully proprietary.

AMD SEV-SNP uses a unique secret burned into each chip at production, with attestation flowing through AMD's Key Distribution Service. Similar to Intel, it requires trust in a single vendor's chip and their ongoing operation of an attestation service. Fully proprietary.

ARM CCA uses a platform attestation key provisioned by the manufacturer, with attestation tied to a manufacturer-operated certificate authority. Architecture is published; implementation is not.

ARM TrustZone provides system-wide isolation between a Secure World and a Normal World but includes no built-in remote attestation. Attestation has to be built in software, typically through open-source frameworks like OP-TEE. That makes TrustZone less plug-and-play than SGX or TDX, but much more flexible: the trust anchor is whatever the operator builds, not a vendor's opaque service.

OpenTitan is a fully open-source compute processing chip designed as a root of trust, the foundational component at the bottom of the security chain. Its keys are derived from a Physical Unclonable Function (PUF) and written to one-time-programmable memory during a manufacturer-controlled personalization step. After ownership transfer, the operator deploys their own Public Key Infrastructure (PKI). OpenTitan is the closest thing the industry has to an auditable commercial option, though the personalization step still introduces a pre-deployment trust window.

Two things are worth analyzing about these TEEs:

1. Every one of these platforms requires you to trust a vendor for something: that a key was erased, that infrastructure is secure, that a certificate authority will keep operating. 
2. Second, attestation proves what code is running but says nothing about where it runs. Recent work on Intel's Platform Ownership Endorsements and the Data Center Execution Assurance protocol is starting to close that second gap for terrestrial deployments, but the problem remains open.

The physical access problem for TEEs

There is a common pattern across recent TEE attacks that shows physical hardware access is still the biggest problem facing TEE security.

TEE.fail (October 2025) extracted attestation keys from Intel TDX, AMD SEV-SNP, and Nvidia GPU confidential computing using a DDR5 memory bus interposer that costs about $1,000 to build. WireTap and Battering RAM, published in parallel, demonstrated related DDR5 interposition attacks on server SGX and confidential VMs. Intel and AMD responded by pointing out that their TEEs were never designed to withstand physical access.

Which is the real issue. Terrestrial TEEs can be hardened against two common types of software-only attacks: side-channel attacks, where an attacker infers secrets by observing indirect signals like timing variations or power consumption rather than reading the data directly, and speculative execution attacks like Spectre and Meltdown, where an attacker exploits the processor's habit of guessing ahead on likely instructions to leak data across isolation boundaries. These are solvable problems. What is not solvable at the processor level is an attacker who can physically reach the chip. Bus probing and memory interposition are not defended against by better microcode; they are defended against by not letting the attacker near the hardware.

The Flashbots ZTEE research on trustless supply chains makes a related point from a different angle: even if the processor is perfectly secure, the keys provisioned during manufacturing create a trust window that the verifier cannot independently audit. Both problems compound. You are trusting the vendor's hardware and the vendor's key management practices, with no way to verify either.

Space Fabric: a different set of TEE assumptions

Space Fabric is SpaceComputer's proprietary hardware and software architecture, designed to provide standardized, trusted compute infrastructure for the space internet. It uses trusted execution environments specifically scoped for orbit, named ‘SpaceTEEs.’

Two architectural choices distinguish it from terrestrial TEEs.

1. Space Fabric runs on hardware that is post-launch physically inaccessible. 

Once deployed, the satellite is beyond the reach of any adversary short of a nation-state with anti-satellite capabilities. Adversarial attacks that defeat terrestrial TEEs, like bus probing, memory interposition, and side channels that require physical proximity, are not possible in LEO.

2. Space Fabric distributes its hardware trust anchor across two independent secure computing chips from two different vendors. 

One co-processor is closed-source and certified, the other is fully open-source and auditable. Both must co-sign attestation evidence. Forging a valid attestation would require compromising both vendors simultaneously. The underlying TEE is ARM TrustZone, a process-based design chosen for its smaller trusted computing base and for the open-source software stack we built on top of it.

All cryptographic security keys are generated after launch, inside the secure computing chips, with no persistent secrets existing on Earth at any point. The pre-launch trust window that every terrestrial TEE carries is eliminated.

The takeaway

Different TEEs fit different threat models. SGX and TDX make sense for cloud confidential compute where the operator trusts the vendor ecosystem. SEV-SNP fits workloads that need VM-level portability. TrustZone and OpenTitan support custom deployments where the operator wants auditability over plug-and-play convenience.

What none of them can do is defend against an adversary with sustained physical access to the hardware. Physical inaccessibility is not a substitute for hardware security; it is a supplement that moving TEEs and computing to orbit can provide.

Visit the SpaceComputer website.

Follow us on X (Twitter) and LinkedIn.

Read the full Space Fabric paper here.

Discover your next read:

SpaceComputer’s Satellite Security Services

SpaceComputer delivers satellite security services from low Earth orbit: confidential compute, key management, and verifiable randomness, all accessible through a single API on Orbitport.

SpaceComputer BlogTara Jean