ARM CCA Realms as a TEE Model for Mobile and Edge AI

Arm's Confidential Compute Architecture (CCA) replaces TrustZone's two-world security model with a four-world design built around the Realm Management Extension. This shift matters for on-device AI specifically: if you run a proprietary model or sensitive user data on a phone or edge device, you need isolation guarantees that TrustZone's original split was never built to provide.

Why TrustZone's two-world model struggles with modern AI workloads

TrustZone splits a device into a Normal World and a Secure World, and that split was adequate for what it was designed to do: protect a small number of fixed platform services, things like key storage, biometric matching, and content protection. The Linaro CCA overview is direct about the limit this creates. The Secure World is one statically partitioned trust domain, usually owned by the platform vendor, so it has no structural room for many mutually distrustful tenants who also distrust the host device itself. An AI deployment scenario often needs exactly that: a model owner who doesn't trust the device manufacturer, a device manufacturer who doesn't trust the app developer, and a user who trusts none of them with raw data.

The shared trust domain carries a real structural risk. Any trusted application inside the Secure World has to share that domain with everything else placed there. The ReZone paper traces the privilege escalation chains this allows: a compromised trusted OS running at S.EL1 can access and reconfigure both secure and non-secure memory. So if one component in the Secure World is flawed, it can reach across everything else that shares that space.

Vendors have responded by narrowing what TrustZone is allowed to do, and the restrictions land hardest on AI workloads. The Imperial College CCA study notes that typical TrustZone deployments block GPU access and cap memory tightly, both measures meant to shrink the attack surface. But modern model weights, even for relatively small on-device models, routinely exceed what a Secure World memory ceiling allows, which makes running full model weights inside the TEE boundary impractical. So developers have tried running only the sensitive partitions of a model inside TrustZone and leaving the rest exposed. Research shows the workaround doesn't close the gap: partial weights still leak enough information to expose training-data membership, so partitioning is not equivalent to full protection.

A memory management limitation causes this: TrustZone enforces its boundary using an Address Space Controller and bus-level protection, which forces physical memory into coarse-grained regions at the TZASC level. The MMU's NS-bit does allow page-level tagging of secure and non-secure pages, but the enforcement boundary that actually matters, the one at the bus and controller level, stays coarse. That coarseness is part of why flexible, dynamic multi-tenant workloads don't fit comfortably inside TrustZone's model.

CCA's four-world architecture at the hardware level

CCA is a coordinated set of changes across the CPU, the memory system, the interconnect, and the System MMU, paired with a new software stack. Its central mechanism is the Realm Management Extension, which takes TrustZone's two security states and turns them into four: Normal, Secure, Root, and Realm, as specified in the Arm CCA architecture document (v4.0, March 2025) and laid out in the Linaro overview.

Each new world answers a specific gap from the TrustZone model. The Root world holds the EL3 Monitor, which is the small, most privileged firmware that switches between worlds. If you give the Monitor its own world instead of folding it into the Secure World with ordinary trusted applications, that most-privileged code stays small and auditable, separate from everything it has to arbitrate between. The Realm world is built specifically so a Realm runs in its own set of Exception Levels, as a second, independent execution environment isolated from both Normal and Secure worlds. A compromised Secure World service no longer has a path into Realm memory, and a compromised Realm has no path back out.

The enforcement behind this separation is called Granule Protection Checking. Every page-sized granule of physical memory gets assigned to one of the four Physical Address Spaces, each corresponding to one of the four worlds, and that assignment is recorded in the Granule Protection Table. Checks happen at the memory subsystem level, so no software reaches the data first. This enforcement layer differs from TrustZone's bus-level controller in granularity: CCA uses standard page tables and the MMU to enforce isolation, as the Imperial College study explains, instead of relying on coarse-grained physical regions.

Day-to-day management of Realms falls to the Realm Management Monitor, and it acts as a thin hypervisor dedicated to Realm isolation. The CAGE paper describes the division of labor directly: an untrusted host hypervisor can still schedule Realms and manage their memory resources, handling the practical logistics of running multiple workloads on one device, but it cannot reach into a Realm's contents. Confidentiality runs one direction only. A Realm can choose to expose a window of its own memory for I/O, for shared buffers feeding data in or out, but the host hypervisor can never reach inward uninvited. That one-way boundary, paired with page-level granularity, is what sets up the practical case for AI deployment covered next.

Dynamic memory management and multi-tenancy for on-device AI

Two things kept full AI models out of TrustZone in practice: the fixed memory ceiling and the single shared trust domain. CCA's page-level granularity and multi-Realm isolation remove both at once, and that combination is what makes full-model deployment inside a TEE boundary realistic rather than theoretical.

The Imperial College study tests this directly rather than assuming it. Deploying an entire model inside a Realm's boundary, instead of partitioning it the way TrustZone deployments were forced to, is the approach that actually prevents membership inference attacks reliably. The mechanism is specific: full containment reduces what would otherwise be a white-box adversary, one with access to internal weights and activations, down to a black-box adversary who can only observe inputs and outputs. So that reduction is what closes the leak that partial-model TrustZone strategies left open.

Realms achieve this without inheriting extra platform privilege. They're de-privileged by design, with only virtualized access to system resources, so a Realm behaves like a TEE in terms of the protection it offers the workload inside it, but it carries no path to escalate and compromise the broader platform around it. That matters for multi-tenancy specifically: a device can host several Realms belonging to different, mutually distrustful parties, and a flaw in one does not hand an attacker a foothold against the others or against the host.

The protection maps onto two concrete attack categories. One is data-privacy risk to the end user, chiefly membership inference attacks, where an adversary checks whether a specific individual's data was part of a model's training set. The other is intellectual-property risk to the model owner, protecting weights from extraction or reconstruction. The Imperial College study puts a number on the first category: CCA reduces an adversary's membership inference success rate by 8.3%, measured directly across the models tested in that work. That's a measured reduction tied to a specific experimental setup, not a general guarantee, and a concrete result that TrustZone's partial-model approach could not produce.

CCA's attestation mechanism for verifying a Realm before trusting it with secrets

Isolation answers how a Realm stays protected once a workload is running inside it. Attestation answers a different question: how does a remote model owner know, before handing over anything sensitive, that the Realm receiving it is actually what it claims to be, running on genuine hardware, in the state it's supposed to be in? TrustZone has no answer to that question at the hardware level. The Linaro overview states it directly: a workload placed in the Secure World inherits its trust from the platform vendor's chain, and no independent mechanism exists for a third party to verify what's actually running there.

CCA closes that gap with a token-based attestation scheme. The CCA attestation token is a profile of the Entity Attestation Token (EAT) format, and it covers two things at once: the state of the Realm itself and the state of the broader CCA Platform underneath it. The token gets produced on request, from the Realm to the Realm Management Monitor, and verification services outside the device entirely are meant to consume it. This structure is specified in an individual Internet-Draft submitted to a standards body for the CCA attestation token, identified by a draft name and version, with a stated publication date and expiration date, which carries no assigned standards-track stream or finalized standard status, a working draft rather than a ratified specification. What the draft establishes clearly is the trust relationship it enables: a Realm owner doesn't have to inherit trust from the untrusted host hypervisor that schedules and manages it. Attestation gives that owner an independent path to trust, one that bypasses the hypervisor layer rather than routing through it.

A second, complementary mechanism strengthens this further. DICE-anchored Realms derive Realm-specific cryptographic keys from a device-rooted secret combined with measurements taken at successive boot stages. That derivation enables what's called implicit attestation, the ability to infer execution integrity just from how a key behaves in use, without needing an explicit signed token for every check. Implicit attestation via DICE and explicit attestation via the CCA token work together, with DICE handling continuous, low-overhead integrity inference and the token mechanism handling formal, on-demand verification.

Put together, this is what lets a model owner provision a proprietary model to an edge device it doesn't physically control. DICE-anchored Realms can protect model weights, prompts, and inference outputs while also producing verifiable evidence of the execution context those assets ran inside. Because the resulting tokens get consumed by verification services outside the device, often across different vendors and ecosystems, the IETF draft has to define exact syntax, exact semantics, exact encoding, and exact cryptographic protection. Interoperability has to be precise, or the verification chain breaks the moment it crosses an organizational boundary, which is exactly the boundary this whole mechanism exists to cross.

The real performance trade-off between CCA and TrustZone

None of this isolation and attestation comes free, so the honest accounting has to start with address translation. CCA needs two-stage address translation where TrustZone needed only one, because a Realm's addresses have to be translated and then checked against the Granule Protection Table before memory access completes. That's a genuine, structural cost in memory-intensive operations, and it would be a mistake to wave it away.

The cost doesn't run in one direction for every kind of workload. For I/O-intensive operations, the comparison reverses. Applications running inside Realm VMs under CCA can access files through VirtIO, and this path turns out to be more efficient than what TrustZone relies on. For workloads that lean heavily on I/O rather than raw memory throughput, CCA performs better than TrustZone, not worse.

For AI inference specifically, where workloads mix computation and I/O rather than leaning entirely on one or the other, the Imperial College study measured where the real cost lands: a maximum performance overhead of 22%, tested across image classification, voice recognition, and chat assistant applications of varying size. Twenty-two percent is a real cost that any deployment has to plan around, but it's a bounded one, measured directly against workloads that resemble what on-device AI actually looks like in practice.

It also helps to weigh that overhead against what TrustZone's restrictions cost in a different currency. TrustZone imposed its no-GPU-access rule and tight memory ceiling to shrink the attack surface, but limits like these can block certain AI deployments outright rather than just slow them down. CCA's trade is different in kind: it spends some runtime efficiency, measurable and bounded, in exchange for removing those functional ceilings. Whether that trade is worth making depends on the deployment, but it's a trade with numbers attached, not a blank check.

The accelerator boundary problem: where CCA's isolation model breaks under GPU and FPGA workloads

The sharpest limitation in CCA as currently specified is at the accelerator boundary, and it deserves a direct look rather than a soft one. External accelerators connected over PCIe are not permitted to access Realm memory under existing CCA specifications. The restriction exists for a clear structural reason: letting an external accelerator reach into Realm memory directly would break granule protection, the exact mechanism that makes CCA's isolation guarantees hold in the first place, a problem the research context around the ACAI paper (USENIX Security 2024) lays out clearly.

So that restriction cuts directly against where AI workloads create the most value. The large inference workloads that would benefit most from running inside a Realm, the ones large enough that isolation and attestation actually matter, are also the workloads that depend most on GPU acceleration to run at acceptable speed. A TEE model that can't safely extend its protection boundary to include the accelerator leaves exactly the most compute-intensive part of the pipeline unprotected. Stated as the strongest version of the objection: if CCA can't protect GPU-based inference without an architectural extension that isn't yet part of the standard, its advantage over TrustZone's partial-model approach narrows considerably for the large models where acceleration is not optional.

The CAGE paper (IEEE TDSC, Vol. 2026) takes on this gap directly rather than treating it as out of scope. It proposes a shadow task mechanism so you can manage confidential accelerator applications with more flexibility, paired with optimizations to the security operations inside memory isolation, aimed at cutting the performance overhead those protections add. CAGE implements this across two accelerator types, a unified-memory GPU and a generic FPGA, and does so without requiring any hardware changes. The security modules run inside the Root world Monitor, where device mediation already happens, and the access problem is resolved through mode-based memory delegation rather than a direct access grant.

It remains a demonstration rather than a shipped standard. CAGE shows the extension is implementable on existing accelerator hardware without new silicon, and it keeps the scope limited to the unresolved problem of securing the accelerator boundary. The Realm itself, along with the CPU-side portion of an inference pipeline, stays fully protected under CCA as it exists today. What remains open is adoption. Commercial devices with CCA enabled are only beginning to reach the market, and until CCA ships at scale in production silicon, any accelerator extension built on top of it, CAGE's approach included, remains a research demonstration rather than a deployed capability. The isolation argument for CCA over TrustZone holds strongly for the CPU-side path. For GPU-dependent inference at scale, it holds only conditionally, pending the kind of extension CAGE has shown is possible but which the standard hasn't yet absorbed.