ARM TrustZone vs Intel SGX for Attestation Workflows

ARM TrustZone and Intel SGX solve the same problem, proving to a stranger that a piece of code is running untampered inside a protected chip, but they start from opposite architectural premises. TrustZone splits a whole system-on-chip into two worlds and trusts everything inside the secure one; SGX carves out a single process at a time and trusts nothing else, not even the operating system underneath it. That one design fork, whole-SoC versus per-process, turns out to explain almost everything about how attestation gets built, standardized, and deployed on each platform, and this piece walks through why.

What attestation is actually doing in each architecture

Attestation, stripped down, is a proof. A piece of software has to convince someone who cannot see the hardware, cannot touch the chip, and has no reason to trust the operator running it, that the code in question is exactly what it claims to be and that it is executing inside a genuine trusted execution environment. There are two flavors worth separating here. Local attestation happens between two components sitting on the same machine, enclave to enclave, and it's a comparatively low-stakes handshake. Remote attestation is the harder version: it has to work across a network, against a challenger who has zero physical access and zero reason to extend the benefit of the doubt.

A working remote attestation scheme has to nail down three things at once: who the application is, whether it's been altered since it was built, and whether the environment it's running in is the real thing rather than a software simulation pretending to be one. The workflow itself follows a predictable shape. A challenger asks for proof, the TEE produces evidence, that evidence gets signed, a verifier somewhere checks the signature chain, and trust either gets granted or it doesn't. The interesting part, and the part where SGX and TrustZone part ways almost immediately, is who signs that evidence, what key they use, and who is willing to stand behind that key.

SGX answers this question in silicon. Intel built a global public key infrastructure directly into the chip and the provisioning process, so the answer to "who vouches for this" is baked in before the developer writes a line of code. TrustZone doesn't answer the question at all, at least not out of the box. Whatever attestation TrustZone ends up doing is something the implementer has to bolt on afterward, and that difference alone accounts for a lot of what follows in this piece.

SGX's built-in attestation pipeline: from REPORT to QUOTE to DCAP

Local attestation on SGX starts with something called a REPORT: a hardware-generated structure, authenticated with a MAC, that lets one enclave prove its identity to another enclave on the same machine. On its own, a REPORT is useless to anyone outside that machine. It has to get converted into something a remote party can actually check, and that conversion is where the real engineering lives.

That job belongs to the Quoting Enclave, or QE, a special enclave whose entire purpose is to turn a local REPORT into a remotely verifiable QUOTE, signed with a platform-unique asymmetric key. The QE calls the EGETKEY instruction to pull a seal key, then derives an ECDSA attestation key from it. From there, the QE hands its public key, its identity, and its current TCB (trusted computing base) version over to a second enclave, the Provisioning Certification Enclave, which certifies the whole package using something called the Provisioning Certification Key. What comes out the other end is an X.509 certificate chain, rooted in a well-known Intel certificate. This is the DCAP attestation collateral, and it's the backbone of every SGX remote attestation flow running today.

Intel didn't always do it this way. The original scheme used something called EPID, and that system was deprecated, reaching end-of-life for production use on April 2, 2025. DCAP replaced it, and the shift matters for more than just cryptographic hygiene: it means cloud providers and enterprises can run their own attestation verification service instead of routing every single check through Intel directly. Microsoft Azure, for instance, built its own remote attestation protocol on top of DCAP for SGX workloads running on Xeon Scalable chips, which is a meaningfully different operational posture than "call Intel every time."

There's a companion mechanism worth mentioning here too: sealing. An enclave can encrypt data meant to persist on disk using a seal key tied to its own identity and the specific platform it's running on, so that data can only be decrypted later by that exact enclave on that exact machine. It's a neat way to store secrets outside the enclave's tiny memory footprint without ever exposing them to the host OS.

Step back and look at the whole pipeline. The QE, the PCE, the DCAP provisioning flow: none of this is a feature someone added after the fact. It's load-bearing structure, designed into the enclave model from day one.

TrustZone's attestation gap and how implementers fill it

Here's where the architectures really diverge. TrustZone's specification, as written, includes no native remote attestation mechanism at all. The Secure World can hold onto secrets just fine, and it can run trusted code, but it has no built-in way to prove to a remote party what state it's actually in. There's no equivalent of Intel's global PKI sitting underneath TrustZone, which means cross-vendor verification, checking a Qualcomm chip's Secure World against a MediaTek one using the same trust root, isn't something the architecture gives you for free.

So what do implementers actually do? Three approaches show up repeatedly in practice. The first leans on a hardware TPM or a firmware-based equivalent, like Microsoft's fTPM, where the TPM holds a chain of platform measurements and can produce a signed attestation report; firmware TPMs offer guarantees similar to hardware ones, though the strength of the chain depends heavily on how well that particular TPM implementation was built. The second is ARM's own Platform Security Architecture, or PSA, which introduces a software-based attestation approach. It's weaker than anything hardware-rooted, and it isn't in the same league as SGX's QUOTE mechanism. The third option is an external attestation service that consumes TPM or PSA evidence and turns it into a verifiable token for whoever's relying on it downstream.

One might argue this flexibility is a feature: TrustZone lets you pick your own attestation strategy rather than locking you into one. But that flexibility comes with a cost that's easy to underestimate. Most existing TrustZone remote attestation research relies on unidirectional attestation, which opens the door to collusion attacks, since only one side is proving anything to the other. And a lot of real-world deployments only attest at boot time, which tells a verifier nothing about what's happened since the device powered on. Runtime integrity, the question of whether the Secure World is still trustworthy right now, largely goes unverified.

What does this mean in practice for the developer? Someone building a TrustZone-based workflow that actually needs remote attestation has to make a set of explicit design decisions, key management, certificate chains, who runs the verifier, that SGX developers get for free just by using the platform as intended.

ARM CCA: the architectural redesign that adds hardware-backed attestation

ARM clearly noticed the gap, because Confidential Compute Architecture, a core piece of Armv9-A, is essentially a redesign built to close it. CCA introduces a new execution context called a realm, sitting orthogonal to the existing Secure World and Normal World split. Realms are hardware-isolated virtual machines, and the Realm Management Extension, or RME, is what enforces that isolation at the hardware level. The ambition here is bigger than phones and embedded chips too: CCA is aimed squarely at large, compute-intensive server workloads, which is a real departure from where TrustZone has traditionally lived.

The attestation story is where CCA actually breaks from TrustZone's habits. Realms can produce attestation tokens signed with a CCA Platform Attestation Key, provisioned directly by the hardware, the same instinct that drove SGX's design, just arriving on ARM roughly a decade later. That token follows the Entity Attestation Token format, specified as a CCA-specific profile in IETF draft-ffm-rats-cca-token-00, published in July 2024. What's notable structurally is the split: a platform token, signed by the CPAK, is kept separate from the realm token, which lets a verifier check the underlying hardware and the specific workload running on it independently rather than as one bundled claim.

CCA stops short of finishing the job, though. It defines the token format carefully, but it deliberately leaves the attestation protocol itself unspecified, meaning each realm implementation has to work out its own way of presenting evidence and negotiating with a verifier. Projects like Confidential Containers and the Veraison verifier are stepping into that gap, building tooling that fits inside the broader IETF RATS model discussed later in this piece.

Worth being honest about where this stands: CCA isn't widely deployed yet. The hardware is still rolling out, and the surrounding attestation tooling is being built in parallel rather than arriving pre-packaged, which is a very different maturity curve than the one SGX has already walked.

EPC memory constraints and what they mean for SGX attestation at scale

SGX's isolation guarantee comes at a real cost, and that cost shows up as a hard number: the Enclave Page Cache, or EPC. This is hardware-managed, encrypted memory, and every byte of enclave code and data either fits inside it or gets paged in and out at a real performance penalty.

Early SGX implementations used a Merkle Tree-based integrity scheme, called the Memory Encryption Engine, which put a hard ceiling on how big the EPC could get. Intel's later move to AES-XTS got rid of that fixed on-die Merkle Tree, and with it, the structural cap. The practical outcome shows up on the spec sheet: newer Xeon chips can expose up to 512 GB of SGX EPC, as on the Xeon 6517P, compared to 128 GB on other current tiers. That's not a free upgrade, though. At 512 GB, the chip drops a specific physical-attack integrity protection that smaller EPC configurations retain, trading a security property for raw capacity.

Why does any of this matter for attestation specifically? Because attesting a large workload, AI inference, bulk key management, heavy data processing, may force paging, and paging adds latency on top of an attestation handshake that's already not exactly instant. TrustZone doesn't have an equivalent constraint, but that's not a point in its favor so much as a reflection of what it's isolating in the first place: the Secure World can use whatever memory the SoC hands it, because TrustZone was never doing per-process accounting to begin with.

The practical lesson for anyone building on SGX: keep the attestation infrastructure itself, the QE, the PCE, the verification logic, comfortably inside EPC limits, and push the heavy data processing into separate, attested components wherever the workload allows it.

The side-channel and physical attack record each architecture carries

SGX carries the longest, most thoroughly documented side-channel attack history of any TEE on the market, and that's not really a knock against the design so much as a consequence of how much attention it's attracted. A February 2025 overview from Estonian cybersecurity researchers catalogued a fresh batch: HECKLER, SIGY, TDXdown, PowSpectre, and PLATYPUS, arriving on top of earlier rounds like Downfall and AVX-TSCHA. Then in October 2025, researchers from Georgia Tech and Purdue disclosed something more physically direct: a passive wiretap interposer clipped onto the DDR4 memory bus, used to observe and pull out the ECDSA private keys behind remote attestation itself, with no malware involved at any point.

It's worth pausing on a distinction that gets lost in the headlines. No published attack has broken SGX's architecture as specified. Every one of these exploits has targeted the underlying CPU microarchitecture or the memory subsystem sitting beneath the enclave model, not the isolation logic itself. That's a meaningful nuance, and it's one that gets flattened every time a new SGX vulnerability makes the rounds online.

TrustZone's exposure looks different in kind, not just in count. Because the Secure World's scope is so much broader, covering an entire trusted OS and potentially several trusted applications, a single vulnerable Trusted Application can compromise the integrity of the whole Secure World. TrustZone devices remain exposed to both boot-time and runtime attacks, and genuine end-to-end trust would require continuous runtime integrity checks layered on top of secure boot, something most real deployments simply don't build out in full. The absence of native attestation makes this worse, not better: without a way to prove current state to a remote party, a Secure World that's already been compromised may never get flagged at all.

So where does that leave someone actually designing an attestation workflow? SGX's attestation keys are a real target for anyone with physical access to the hardware. TrustZone environments are harder to verify remotely the moment runtime integrity comes into question. Neither of those is a small caveat.

Where each technology actually gets deployed and why the deployment context reinforces the architecture

SGX has found its home in servers and data centers, and blockchain infrastructure in particular has leaned on it heavily. Flashbots, Secret Network, Oasis Sapphire, Phala Network, iExec, Marlin Oyster, and Automata are all running SGX in production attestation workflows right now, not as a pilot or a proof of concept. AWS Nitro Enclaves represent a second, parallel path on the server side, widely used for AI inference workloads, and worth naming here as a different flavor of the same server-TEE instinct.

TrustZone, meanwhile, owns mobile and IoT, and for good reason: its whole-SoC model fits that context naturally. Secure key storage, biometric processing, payment credentials, these all sit comfortably inside a Secure World that's shared across the whole device. Remote attestation shows up far less often in these deployments, largely because the device is usually attesting to a local service, or in a lot of cases, not attesting to anyone at all.

That split isn't an accident, and it isn't arbitrary either. It's the direct result of the architectural tradeoffs both platforms made years ago. SGX's per-process isolation, paired with attestation that's built into the silicon, makes it the obvious choice whenever a remote party needs proof about one specific computation. TrustZone's whole-device partition fits situations where the device itself, not any single process running on it, is the unit that needs to be trusted.

One emerging deployment context is worth flagging on its own: privacy-preserving AI inference, where attestation isn't a nice-to-have, it's the entire point. A user handing sensitive data to a remote model needs to verify, before that data ever leaves their machine, that it's headed into a genuine TEE and not a convincing simulation of one. Confidant AI, a privacy-preserving AI assistant built around keeping user data from being collected, sits squarely in this category of applications. SGX paired with DCAP is currently the most mature path available for that use case, and CCA is shaping up to be ARM's answer on the server side, though it's still earlier in its build-out than SGX's decade-plus head start.

How IETF RATS is pushing toward attestation interoperability across both architectures

All of this, SGX's QUOTE format, TrustZone's patchwork of TPM and PSA options, CCA's EAT-based tokens, risks becoming a set of incompatible dialects unless something ties them together. That's the job IETF RATS, Remote ATtestation procedureS, has taken on.

The RATS model is built around three roles. An Attester produces evidence about itself. A Verifier takes that evidence and checks it against a set of reference values it considers trustworthy. A Relying Party then takes the Verifier's output and makes an actual trust decision, whether to hand over data, grant access, or proceed with a transaction. It's a clean separation of concerns, and it's deliberately built to be architecture-agnostic: nothing about the model assumes SGX's QUOTE format or TrustZone's TPM-based evidence.

What that buys the industry, at least in principle, is a shared vocabulary. A verifier built to the RATS model doesn't need to be rewritten from scratch to handle both an SGX QUOTE and a CCA attestation token; it needs to understand how to appraise evidence, wherever that evidence originated. That's the theory, and it's the direction both the SGX and ARM ecosystems appear to be leaning, even if each platform got there by a completely different architectural road. Whether that interoperability actually delivers in production, at the scale blockchain and confidential AI workloads now demand, is the open question the next few years of RATS adoption will have to answer.