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

TrustZone ships on nearly every Arm processor produced today, and that ubiquity is also its ceiling. The architecture partitions memory statically between a single Secure world and a Normal world, a design that made sense in 2004 when the threat model was narrow. Today, a Trusted OS running inside the Secure world holds unrestricted access to both worlds' memory, meaning a single exploit against that OS can compromise the entire system. Researchers have demonstrated exactly that: exploit chains that hijack the Trusted OS and achieve full system control. The constraint is structural, not incidental.

For machine learning specifically, the limitations compound in ways that become obvious once you try to actually host a model stack there. The memory budget is too small, and the isolation boundary is shared rather than per-workload. Cloud confidential compute solved an analogous problem years earlier: Intel TDX and AMD SEV protect at the VM level, giving each workload its own isolated boundary, scalable with available memory, independent of other tenants. TrustZone offers no equivalent. AI inference wants dynamic, large, per-workload isolation; TrustZone offers static, small, shared isolation. That raises an important question: if the cloud already solved this, why does the edge remain exposed?

ARM introduced the Confidential Compute Architecture in Q2 2021 as part of Armv9-A, formalized as the Realm Management Extension. RME adds two new execution worlds on top of TrustZone's existing Normal and Secure worlds. The Root world is restricted to EL3 and hosts the secure monitor. The Realm world is the structurally interesting addition, and "structurally different" here carries specific technical weight rather than marketing register.

A Realm is a second independent address space, orthogonal to privilege levels, entirely separate from the Normal world. Software executing in the Normal world cannot access CPU state or memory belonging to a Realm, and that property is enforced in hardware rather than by software policy. But why does hardware enforcement matter here? Software-enforced boundaries depend on the trustworthiness of the enforcing software, which is precisely what an attacker targets first. That circularity is the reason hardware enforcement matters. Realms are VM-shaped, each capable of running multiple virtual CPUs, and the number of concurrent Realms is bounded only by available physical memory.

The relationship to TrustZone is additive rather than competitive, a point that sometimes gets lost in comparisons. TrustZone remains appropriate for static, silicon-provider or OEM security tasks: secure boot, key provisioning, DRM enforcement. Realms serve a different purpose, offering developer-controlled, dynamically instantiated isolation for workloads that require confidentiality guarantees the platform operator cannot override. The analogy to AMD SEV and Intel TDX is intentional; CCA brings that cloud confidential compute threat model to edge and mobile silicon, and gives application developers a TEE they can actually enter and manage themselves.

How Granule Protection Checks Enforce Isolation at the Hardware Level

The mechanism that makes the Realm world's isolation real rather than nominal is the Granule Protection Check. GPC is hardware-level access control enforcing which physical memory granules belong to which world. Enforcement extends across bus transactions and address translation for I/O operations, not just CPU cores. CCA-enabled peripherals can therefore securely access Realm memory, which means the isolation boundary reaches hardware accelerators.

The underlying data structure is the Granule Protection Table, managed by the EL3 monitor in the Root world. The GPT records the world assignment of each memory granule; attempts to cross those assignments are rejected by hardware before any data transfer occurs.

Inside the Realm, the guest's address space is split in two. The lower half is protected: the Normal world cannot observe memory mapped there, and the RMM restricts what operations the Normal world can perform on that region. A compromised hypervisor cannot silently replace pages in this region without the guest's cooperation. The upper half is shared with the Normal world, enabling the communication that any real workload requires. This split is where most of the interesting engineering decisions in a real deployment actually live, and where underestimating the design surface leads to problems that hardware guarantees alone cannot fix.

An untrusted hypervisor can stop scheduling a Realm and reclaim its memory, but it cannot read or write Realm CPU registers or memory contents. Before CCA, a hypervisor exploit was sufficient to extract VM secrets. GPCs close that path at the hardware level. For AI workloads, the practical consequence is direct: model weights and private inference data loaded into the protected lower IPA cannot be exfiltrated by a compromised host OS or hypervisor, regardless of how deep the compromise runs.

The Software Stack That Manages Realms: RMM, RMI, RSI, and Why the Small TCB Matters

The Realm Management Monitor runs at R_EL2, the Realm-world equivalent of hypervisor privilege, and its scope is deliberately narrow. The RMM manages context switching and enforces confidentiality and integrity of Realm state; it also provides attestation services. What it does not do is make policy decisions. Questions of which Realm to schedule, how much memory to allocate, how many vCPUs to provision: those remain with the host hypervisor.

Narrow scope means the RMM can be orders of magnitude smaller than a conventional hypervisor. Fewer lines of code means fewer surfaces for vulnerability and a more tractable formal verification target. It is also worth considering what this means in practice: this is not a minor engineering convenience. It is one of the more defensible arguments for CCA's security posture relative to systems that fold virtualization and security enforcement into a single large software component, an architecture that has repeatedly produced high-severity privilege escalation vulnerabilities in practice. The TCB argument is not theoretical; it reflects lessons from a decade of hypervisor CVEs.

Two interfaces structure the communication hierarchy. The Realm Management Interface runs between the host hypervisor and the RMM, used to create, populate, execute, and destroy Realms. The Realm Services Interface runs between the RMM and the Realm VM, allowing Realm software to request services from the RMM, including attestation token generation. The reference implementation, TF-RMM, is open-source under a BSD-3-Clause license. As of mid-2026, the RMM specification is at version 2.0-bet2, with version 2.1 in alpha draft.

The layered design carries a deployment implication that is easy to overlook: existing Linux-based hypervisors such as KVM and Xen can serve as the resource manager without being trusted with Realm secrets. Edge hardware already running stock Linux can adopt CCA without replacing its hypervisor, only constraining what the hypervisor can observe. That is a narrower adoption barrier than it first appears, and it matters for anyone thinking about migration paths rather than greenfield deployments.

How Attestation Lets a Remote Party Verify What Is Running Inside a Realm Before Trusting It with Sensitive Data

Attestation transforms hardware isolation from a local property into a verifiable claim a remote party can act on. The practical problem is specific: a model provider shipping proprietary weights to an edge device needs evidence that those weights will execute inside a genuine, unmodified Realm and not inside a software emulator or a compromised environment. Without attestation, hardware isolation is a promise the relying party cannot inspect, and in commercial AI deployment, uninspectable promises have limited value. But how does attestation actually close that gap?

The CCA attestation token is a profile of the Entity Attestation Token, encoded as CBOR and cryptographically signed. It contains platform software component measurements expressed as SHA-256 values, alongside Realm-specific claims. The current CCA platform profile string is tag:arm.com,2024:cca_platform#2.0.0. The IETF token specification, draft-ffm-rats-cca-token, was published in July 2024 at revision -03.

Three components cooperate to produce attestation evidence. The main bootloader measures the Realm world TCB at boot time. A hardware security element anchors the chain as the Root of Trust. The RMM contributes Realm-specific measurements at runtime. The result is a layered evidence structure that a verifier can decompose, checking platform integrity and specific Realm state independently.

The Realm Initial Measurement is the claim a relying party will scrutinize most carefully. The RIM is a stable, unique identifier for a Realm's initial state; a relying party compares it against a known-good value to confirm the Realm is running exactly the code it expects before transmitting any secrets. Linaro provides an attestation verifier for pre-silicon CCA platforms; the Veraison project provides open-source verification infrastructure adaptable to production deployments. The verifier ecosystem is still nascent, and that is a genuine gap, not a footnote.

For AI specifically, attestation is what allows a model provider to operationalize a service agreement in hardware terms rather than contractual ones. Weight delivery can be conditioned on a verified RIM, ensuring the model executes only in Realm configurations the provider has explicitly authorized. The policy becomes cryptographically enforced, which is a qualitatively different assurance than a terms-of-service clause.

How an AI Workload Is Structured Across Normal World and Realm to Balance Security with Practical Resource Limits

The resource constraint shaping every design decision here is simple: hosting an entire large model stack inside a TEE is prohibitive on edge hardware. Memory is finite, and Realm memory competes with everything else the system needs. The practical response is a hybrid architecture, placing only security-critical components inside the Realm, and the line between what goes inside and what stays outside is where most of the real engineering judgment gets exercised.

In a well-designed split, the Normal world handles user interactions, the network stack, initial data pre-processing, and non-sensitive I/O. The Realm holds the inference runtime, proprietary model weights, private cryptographic keys, and any sensitive system prompt. Input data can be sanitized in the Normal world before crossing the security boundary, which reduces the Realm's attack surface without requiring it to process raw, untrusted input directly.

The host OS and hypervisor cannot read the weights; IP protection is hardware-enforced by GPC. User inference data processed inside the Realm cannot be logged or exfiltrated by the platform operator. Attestation before weight delivery means the model provider controls which Realm configurations are authorized to receive those weights at all. The privacy implication is architectural: inference stays on-device, data never traverses to a cloud API, and the device's own OS stack cannot observe the computation.

There is a genuine tension at the Realm/Normal boundary, and anyone designing for production should resist the urge to treat hardware isolation as a complete solution. But what if the interface between the two worlds is itself poorly designed? GPC-level enforcement is real and meaningful, but poorly designed shared-memory interfaces can leak timing information or content information across the boundary even when that enforcement is intact. The hardware enforces isolation; the software design determines whether that isolation is actually exploited correctly. Experienced engineering judgment matters here in ways that no specification document fully captures.

What Empirical Benchmarks Show About the Performance Cost of Running AI Inside a Realm

The headline result from Abdollahi et al. (SysTEX 2025) is that CCA achieves an overhead of at most 22% when running models across different sizes and application types, including image classification, voice recognition, and chat assistants. That figure needs context before it does any work.

Twenty-two percent is a bounded, predictable cost for workloads that are already compute-bound. Large matrix multiplications dominate inference time, and the TEE boundary does not fundamentally change how those operations execute on-chip. The overhead comes primarily from world-switch latency, memory management overhead at the Realm boundary, and the cost of enforcing GPC on memory accesses. For many edge deployments, that tradeoff is reasonable: hardware-enforced confidentiality for a fraction of raw throughput.

The GuaranTEE benchmark (Siby et al., EuroMLSys 2024) evaluated a TensorFlow Lite MobileNet model for image recognition, comparing a Normal-world VM baseline against a Realm VM. All evaluations ran on ARM's Fixed Virtual Platform, emulating Armv9-A. The FVP caveat is material: emulated results do not capture cache effects, memory bandwidth contention, or interconnect latency that appear on real silicon. The published figures are directionally informative, not production-validated.

Most published results originate from simulation or early pre-silicon platforms. Performance characteristics on production Armv9-A silicon with full peripheral support, real cache hierarchies, and real memory pressure remain to be confirmed at scale. The gap between emulated and silicon behavior in TEE contexts has historically been wider than architects expect, and anyone making procurement or architecture decisions based on these numbers should weight that uncertainty accordingly.

For edge AI, the relevant comparison is not CCA versus no-TEE in isolation. CCA versus sending data to a cloud endpoint is the more useful frame, where round-trip network latency frequently dwarfs a 22% local compute overhead, before privacy implications of cloud transmission enter the calculation at all.

The Research Directions Pushing CCA Beyond CPU-Only Isolation: Accelerators, Multi-Realm Systems, and User-Space Enclaves

CCA's base design leaves a gap that becomes apparent immediately when you try to run inference on real mobile hardware: GPU and NPU accelerators are outside the Realm boundary. Model inference that offloads to a neural engine does so through the untrusted Normal world. The hardware isolation buys confidentiality for CPU-side computation; without extensions, it does not cover the path through an accelerator. For any serious on-device AI use case, that is not a peripheral concern.

ACAI (Sridhara et al., USENIX Security 2024) addresses this directly, extending CCA to cover GPU and FPGA accelerators by proposing a mechanism through which CCA-enabled peripherals participate in the Realm's confidentiality guarantees. CAGE (Wang et al., NDSS 2024) takes a complementary approach, focusing specifically on GPU-level isolation extensions. Both projects build from CCA's hardware primitives upward rather than proposing a new substrate, which is a meaningful signal about the architecture's foundational stability.

SHELTER (Zhang et al., USENIX Security 2023) extends CCA downward in granularity, enabling user-space isolation that produces finer-grained enclaves within the Realm model, closer in user experience to the SGX enclave model but built on CCA's VM foundation. CubeVisor (Chen et al., ACSAC 2024) addresses the operational challenge of multi-realm systems: managing many concurrent Realms efficiently, a problem directly relevant to edge servers running inference for multiple tenants simultaneously.

GuaranTEE (Siby et al., EuroMLSys 2024) demonstrates the full stack end-to-end: attestable, private ML on edge devices using CCA Realms, from Realm instantiation through attestation through inference. The pattern across all of these projects is consistent. CCA's hardware primitives, GPC, RMM, and attestation, are stable enough to build on seriously. The base architecture is not complete for all AI hardware paths, but it is coherent enough that meaningful research is accumulating in both directions simultaneously.

Where CCA-Based Confidential AI Fits Into the Broader Case for Privacy-Preserving On-Device Inference

The convergence CCA makes possible is genuinely novel at the edge, even though each of its three properties exists in other systems individually. Local inference keeps data off the network. Hardware isolation keeps data away from the platform OS and hypervisor. Attestation lets a remote party verify both properties before trusting the device with sensitive material. One might argue that achieving one or two of these properties is sufficient for most deployments — but systems achieving all three on edge silicon, through an open, standardized architecture, are not common, and the distinction matters.

The beneficiaries of each property are distinct. Users gain assurance that inference data is not observable by the device OS, the hypervisor, or a cloud backend. Confidant AI, a privacy-preserving AI assistant built so user data is never collected or monetized, represents the kind of product that depends on exactly this class of architectural guarantee. Model providers gain hardware-enforced IP protection and the ability to condition weight delivery on verified Realm configurations. Device manufacturers gain a path to differentiation on privacy claims that are architecturally grounded rather than asserted in marketing copy.

The competitive context matters. Apple's on-device inference stack and Google's on-device model work both benefit from tight hardware-software integration that is not generally available to third-party developers. CCA is significant precisely because it offers an open, standardized path toward equivalent confidentiality guarantees on hardware that third parties can actually build on. The RMM specification is public; the reference implementation is open-source; the attestation token format is under IETF standardization. That openness is what makes CCA a credible foundation for an ecosystem rather than a proprietary feature, and it is the dimension where the comparison to Intel and AMD's cloud confidential compute trajectory becomes most instructive.

Production deployments of CCA-based confidential inference at scale are limited. The benchmark data comes primarily from simulation. The accelerator extensions are research prototypes. The attestation verifier ecosystem is nascent. None of that is hidden, and none of it changes the underlying architecture.

The isolation model is sound; the TCB is demonstrably smaller than TrustZone's; the attestation chain is cryptographically rigorous; and the performance overhead, at least on simulation, is bounded at a level that does not obviously preclude practical deployment. Whether the ecosystem matures fast enough to matter before alternative approaches consolidate the market is a question the architecture alone cannot answer, and anyone who tells you otherwise is selling something.