Confidential Computing for AI Explained: Protecting Data While It Is Being Processed

Encryption is familiar when data sits on a disk or travels across a network. The hard part is the moment in between, when a program has to load the values into memory and compute on them. A cloud service may need to process a private dataset, a model may need to read a sensitive prompt, and an accelerator may need raw tensors while a workload runs. Confidential computing is the family of hardware-backed techniques built to shrink that exposure. This explainer covers how it works, what it protects in AI systems, and where its guarantees stop.

The National Institute of Standards and Technology (NIST) describes confidential computing as extending encryption to data in active use. Its initial public draft, NIST IR 8320E, was published on May 29, 2026, and presents an example approach for protecting the datasets used by AI workloads on cloud infrastructure. The draft's comment period closed in July 2026, so details may change before a final version appears.

Direct answer: Confidential computing protects data during processing by running code and data inside a hardware-backed trusted execution environment (TEE) and using remote attestation to let a client verify what is running before releasing keys. In AI, this can reduce exposure of training data, prompts, model weights, or inference results to cloud operators. It does not remove endpoint risk, application bugs, malicious authorized users, side channels, physical attacks on memory buses, metadata leakage, or the need for ordinary identity and key-management controls.

Why data in use is the weak link

Security teams usually describe data as living in three states. Each has a mature protection, and each protection has a gap that the next state fills.

State	Where it lives	Standard protection	Typical gap
At rest	Disks, object storage, backups	Storage encryption, key management	Whoever holds the key can read it
In transit	Networks, service-to-service calls	Transport encryption (TLS)	Endpoints see plaintext
In use	CPU registers, RAM, accelerator memory	Process isolation, access control	A privileged host can often read memory

Think of a bank that keeps documents in a vault overnight and ships them in armored trucks, but then hands them to a clerk who spreads them across an open desk to read. The vault and the truck did their jobs. The desk is where the exposure happens. Confidential computing tries to give the clerk a glass-walled booth that even the building manager cannot walk into.

Ordinary virtualization already isolates one customer's virtual machine from another's. It does not, by itself, stop a privileged host, a compromised hypervisor (the software layer that runs virtual machines), a malicious administrator, or a vulnerable device driver from reading a guest's memory. For many workloads that is an acceptable risk. For hospital records, financial models, or proprietary training sets, some organizations want a stronger boundary.

The three-state model is useful but incomplete. Metadata, access patterns, timing, outputs, logs, backups, and keys can all reveal information even when the main data buffer is protected. Keep that caveat in mind through the rest of the article.

How a trusted execution environment works

A trusted execution environment is an isolated execution area whose confidentiality and integrity are supported by hardware and firmware. Wikipedia's summary, drawn from the original mobile-industry standards work, calls it a secure area of a main processor that protects code and data. Concretely, the processor enforces rules that software outside the TEE, including the operating system, cannot override.

Two ingredients do most of the work. The first is memory encryption: data leaves the processor package encrypted, using keys that live inside the chip and are not exposed to ordinary software. Someone who pulls a memory module out of a running server, or a hypervisor that dumps guest pages, sees ciphertext. The second is access control inside the processor: the CPU refuses to let the host read or alter the protected memory, and it tracks which memory pages belong to which protected workload.

A useful analogy is a hotel safe bolted into a room. The hotel owns the building, controls the master schedule, and employs the staff. The safe still holds the guest's valuables, because the lock mechanism is not something the staff can reconfigure. The analogy breaks in one place that matters: a real safe's security is physical and obvious, while a TEE's security depends on firmware, microcode, and a threat model that has to be read carefully.

Enclaves and confidential virtual machines

Designs differ in how much code sits inside the boundary. An enclave protects a small piece of an application. A confidential virtual machine protects an entire guest operating system and everything running in it.

A small enclave keeps the trusted code base (the code you must believe is correct) compact, which makes it easier to audit. It also makes life harder for developers, because libraries and system calls have to be adapted. A confidential virtual machine is far easier to deploy, since an existing application can often run with little change, but you now trust a whole operating system and its dependencies. Neither is strictly better; the choice trades a smaller attack surface against engineering effort.

Hardware roots of trust

A root of trust is a component or key assumed to anchor other security decisions. Secure boot, measured boot, and device identity keys help establish which firmware and software are running. If the root of trust is compromised or poorly managed, every later claim about workload integrity gets weaker. This is why vendors publish security bulletins for firmware and microcode, and why operators have to apply them.

A short history of the hardware

Confidential computing did not appear all at once. The hardware arrived in waves over roughly a decade, and the dates matter because each wave fixed a limitation of the one before.

Technology	Vendor	Introduced	What it protects
Software Guard Extensions (SGX)	Intel	2015 on 6th Gen Core PCs; 2018 on Xeon E-2100 servers	Small application enclaves
Secure Execution for Linux	IBM	2020, with IBM z15 and LinuxONE	Virtual-machine-level protection
SEV-SNP	AMD	2021, with 3rd Gen EPYC	Confidential virtual machines
Confidential Compute Architecture (CCA)	Arm	2021, with the Arm v9-A architecture	Isolated confidential workloads
Trust Domain Extensions (TDX)	Intel	2023, on 4th Gen Xeon Scalable	Confidential virtual machines ("trust domains")
Confidential Computing mode	NVIDIA	2022, on H100-family GPUs	Accelerator memory and CPU-to-GPU transfers

Sources: Wikipedia's "Confidential computing" article, which cites vendor and academic sources; Intel's TDX overview; NVIDIA GPU details from the benchmark paper listed under Sources. Introduction dates reflect first availability as summarized there and can differ by product line.

Intel SGX, first shipped in 2015, was an early mainstream attempt to put an application inside a hardware-protected boundary. Victor Costan and Srinivas Devadas published a detailed public analysis, "Intel SGX Explained", in 2016. They worked from Intel's manuals, the original SGX papers, and patents, and analyzed the design's security properties while making informed guesses about undocumented details.

The industry also organized. The Confidential Computing Consortium, formed in 2019 under the Linux Foundation, brought together Alibaba, Arm, Google Cloud, Huawei, Intel, Microsoft, and Red Hat as founding premier members. Its public site now describes its mission as advancing and standardizing the technology, and states that confidential computing protects data while it is in use.

The later chips moved from "protect a fragment of an app" to "protect a whole virtual machine." Intel TDX, for example, uses hardware-isolated virtual machines called trust domains. According to Intel's overview, a CPU-measured TDX module runs in a new processor mode and handles memory encryption, with remote attestation as one of its architectural elements. The overview lists Alibaba Cloud, Microsoft Azure, and Google Cloud among the places the technology is available.

Remote attestation and key release

A protected room is only useful if the person sending secrets into it can confirm the room is the one they expect. That confirmation is remote attestation, and it is the part of confidential computing that most often gets skipped in casual explanations.

Picture a courier who will deliver a sealed envelope only to a recipient who can show a government-signed inspection certificate for the exact room, with today's date on it. Attestation works in a similar way. The processor produces a signed report that includes measurements (cryptographic fingerprints) of the firmware, the software image, and the configuration. A verifier checks the signature chain back to the hardware vendor and compares the measurements with a policy.

The steps in order

1. A client or key service asks the workload for evidence, supplying a fresh random value (a nonce) so old evidence cannot be replayed.
2. The processor signs a report covering the measured software state and the nonce.
3. The verifier checks the signature chain, the platform's identity, and the certificate status.
4. The verifier compares the measurements with an approved policy.
5. If everything matches, a key-management service releases a decryption key to that workload only.
6. The workload decrypts the data inside the protected boundary and processes it.

Notice what this does and does not prove. A measurement shows that a particular image and configuration ran. It does not show that the application logic is free of bugs, that the output is appropriate, or that the policy itself was well written. An attestation system that accepts stale evidence, ignores revoked certificates, or approves any image signed by a careless build pipeline can authorize a vulnerable workload with a perfectly valid report.

Key release is a policy decision

The key-management service should release keys only to an attested workload with the right identity, version, environment, and authorization. Organizations should decide in advance what happens when an image is updated, a vulnerability is announced, attestation fails, or a platform becomes unavailable. These decisions sound administrative, but they are where many real deployments succeed or fail.

What confidential AI looks like in practice

Protecting training data

Training data may include personal information, proprietary documents, source code, medical records, or financial data. A confidential training setup can reduce exposure to infrastructure operators during the phases where processors, storage paths, accelerators, and software are all inside the boundary. For background on what those phases involve, see how AI models are trained.

It does not remove the need for consent, data minimization, access governance, or retention rules. It also cannot undo memorization. A model trained on sensitive text can retain recoverable fragments in its weights, and protecting the memory during training does nothing about that. Privacy evaluation of the trained model, plus controls on who can download or query it, remain separate jobs.

Protecting prompts during inference

In confidential inference, a user wants a model to process a sensitive prompt without exposing the prompt or the answer to the infrastructure operator. The difference between training and inference matters here: inference happens many times, with live user data, which makes the privacy stakes more immediate.

A TEE can protect the computation path. The user still has to trust the model code, the result-handling path, and the client device. The output itself may contain private information that flows to logs, caches, or downstream tools, so a service has to say plainly which values are protected, who can see outputs, how long they are retained, and whether support staff can ever access diagnostic material. Teams that run AI observability pipelines face a real tension, since monitoring tools want to record exactly the prompts that a confidential design is trying to hide.

Private documents and retrieval

Many enterprise systems do not train on private data at all. They retrieve it at question time, as in retrieval-augmented generation. A confidential design for that pattern has to cover more than the model: the document store, the embedding step, the vector database, and the prompt-assembly code all hold plaintext at some point. Protecting the language model while leaving the index outside the boundary is a common and easily missed gap.

Multi-party and federated work

Confidential computing can complement federated learning or multi-party analytics by protecting local contributions during aggregation. It does not make participants honest, and it does not guarantee that an aggregate result cannot reveal information about individuals. Depending on the application, secure aggregation, differential privacy, access policy, and statistical disclosure controls may also be needed.

The GPU question

Modern AI runs on accelerators because matrix arithmetic is expensive, which is part of why AI needs so much computing power. A CPU-only enclave does not automatically protect data once it moves to a GPU. The security story has to cover CPU memory, accelerator memory, shared buffers, drivers, and the links between them.

NVIDIA introduced a confidential computing mode on its H100-family (Hopper) GPUs in 2022. A 2024 benchmark study, "Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study" by Jianwei Zhu and colleagues, measured the cost of turning that mode on for large language model inference. The authors report that GPU computation itself adds minimal overhead, that most of the penalty comes from CPU-to-GPU data transfers over PCIe, and that overhead stays below 7% for most typical queries. Larger models and longer sequences saw nearly zero overhead.

That is a useful data point, but not a universal number. The study covers specific models, hardware, and software versions on Hopper GPUs. A team with a different pipeline, such as heavy data preprocessing or frequent small transfers, could see different results. The reason the percentage is small for big models is intuitive: the encryption cost is paid when data crosses the bus, and a large model spends most of its time computing on data that is already inside the GPU.

A deployment team should still ask direct questions. Does attestation cover the accelerator and driver? How do keys enter the system? Where do intermediate tensors live? What happens during debugging? The honest answer might be "the accelerator is included," "the accelerator is isolated by a trusted service," or "the current design cannot protect that path." All three can be acceptable if they are documented.

A public example: Apple's Private Cloud Compute

Most confidential-computing designs are private to the companies running them. Apple published its reasoning for one in a June 10, 2024 security blog post on Private Cloud Compute (PCC), its system for processing AI requests in the cloud. The post is useful because it states the design goals as testable requirements instead of slogans.

Apple lists five. Computation on personal data must be stateless, so data is used only to fulfill the request and is not retained, including through logging or debugging. The guarantees must be technically enforceable rather than dependent on outside components such as a TLS-terminating load balancer. There must be no privileged runtime access that lets site reliability staff bypass the guarantees, even during an outage. The system must be non-targetable, so an attacker cannot go after one user's data without attempting a broad compromise of the whole system. And there must be verifiable transparency, so outside researchers can confirm that production software matches what they inspected.

The attestation piece is the notable part. Apple says user devices will send data only to PCC nodes that can cryptographically attest to running publicly listed software. It says it will publish measurements of the code in an append-only, tamper-evident transparency log, and that it will make software images of every production build available for security research. This matches the courier-and-certificate picture from earlier, with the added step that the list of approved rooms is public.

What the post cannot do is prove the system is secure. It states an architecture and commitments. Independent review, a record of how well the commitments hold up, and a clear scope (it concerns Apple's own service, not confidential computing in general) all matter when judging it.

Where the protection ends

A fair account of confidential computing has to include the research that has weakened specific claims. Security researchers treat TEEs as one layer, and the attack literature shows why.

Year	Attack or finding	What it showed
2015	Controlled-channel attacks (Xu, Cui, Peinado)	A malicious operating system could infer secrets from page-fault patterns in SGX
2015	Last-level cache attacks (Liu et al.)	Cache behavior leaked information across protection boundaries
2020	SGAxe and CrossTalk	Side-channel attacks reported against Intel SGX
2020	Off-chip memory bus attack (Lee et al.)	Targeted hardware enclaves via the memory bus
2021	CIPHERLEAKS	Ciphertext side channel against AMD SEV-SNP
2022	ÆPIC Leak	An architectural bug in Intel CPUs affecting SGX
2025	TEE.fail	Low-cost physical interposer on DDR5 memory traffic

Source for 2015 to 2022 entries: Wikipedia's "Confidential computing" article and the primary papers it cites. The TEE.fail entry comes from the researchers' project page.

A side channel is information that leaks through something other than the protected data itself, such as timing, cache behavior, or memory-access patterns. Think of a locked room where an observer cannot see inside but can hear the printer. Mitigations exist for many of these attacks, and vendors have shipped microcode and firmware fixes, but the pattern repeats: a new class of leak appears, researchers demonstrate it, and the ecosystem patches it.

The 2025 physical-attack result

The most recent entry is worth a closer look because it targets the claim that hardware memory encryption stops a malicious data-center operator. The TEE.fail project, published for IEEE Symposium on Security and Privacy 2026 by researchers at Georgia Tech, Purdue, and van Schaik LLC, used a hand-soldered DDR5 bus interposer attached to a logic analyzer to record memory traffic. The researchers estimate a setup like theirs costs under $1,000.

The attack works because Intel and AMD use deterministic memory encryption, meaning identical plaintext produces identical ciphertext, so an observer can learn about data from patterns. On Intel TDX and SGX, the researchers report extracting the attestation key of the Provisioning Certification Enclave, which would allow forged attestation quotes. On AMD SEV-SNP, they report extracting OpenSSL signing keys from a virtual machine even with Ciphertext Hiding enabled. On NVIDIA's confidential computing, they note that GPU attestation is not bound to a specific virtual machine or CPU, so attestation reports can be relayed from other machines, though they say they did not directly attack NVIDIA's components.

Vendor responses are the instructive part. Intel and AMD treat interposer attacks as outside their threat model, so the mitigation is physical security of the server. AMD published bulletin AMD-SB-3040 and does not plan firmware updates for it. NVIDIA has no mitigation on its side, and the researchers recommend trusting only physically secured servers. As far as the researchers know, the attack has not been exploited in the wild.

The lesson is not that confidential computing is useless. It is that the threat model matters. A TEE can protect data against a remote attacker, a curious hypervisor, or a software-level insider. It is a weaker defense against someone with physical access to the machine and the budget for a logic analyzer. Whether that matters depends on who your adversary is and who controls the data center.

What it does not protect, in plain terms

The boundary map below summarizes how the technology maps onto AI pipeline components. It is a design framework, not a certification checklist.

Workload component	Possible confidential-computing benefit	Boundary that still needs separate controls
Dataset in protected memory	Reduces some host-level memory exposure	Data collection, consent, storage, output, memorization
Model weights	Limits direct inspection during execution	Supply chain, model theft, malicious code, release policy
Prompt or feature vector	Reduces exposure in the protected path	Client device, logs, cache, output, access control
Inference code	Attestation can identify approved code	Vulnerabilities, dependencies, runtime behavior
Key release	Hardware evidence can inform policy	Identity, revocation, rotation, authorization
Accelerator memory	May be protected in some architectures	Device support, driver, interconnect, scope
Tool result	Can be processed inside a protected workload	Tool authorization, external system, downstream recipient
Audit telemetry	Can be minimized or protected	Retention, privacy, incident access, completeness

Endpoints and outputs

If a user's laptop, browser, or phone is compromised, sensitive data can be captured before encryption or after decryption. A protected cloud workload cannot repair an unsafe endpoint. Likewise, the output of an AI model may contain personal or confidential information, and confidential execution does not make an output safe to display, store, email, or use in a decision. A model that has been manipulated through prompt injection can be induced to emit sensitive material from inside a perfectly attested environment.

Application logic

A TEE can faithfully run buggy or malicious code. Input validation, authorization, secure development, dependency management, and code review remain necessary. An attested image is a statement about which bits ran, not about whether those bits were wise.

Authorized insiders and availability

A user with permission to request a report can still misuse the report. Confidential computing addresses selected infrastructure threats; it does not replace governance or least privilege. And a workload can be confidential and still be unavailable. Hardware support, key-service outages, attestation failures, and update requirements can all complicate disaster recovery.

Confidential computing versus other privacy techniques

Confidential computing is one tool among several, and it often gets confused with the others. The comparison below is qualitative on purpose; costs depend heavily on the workload.

Technique	What it protects	Main assumption	Typical trade-off
Confidential computing (TEE)	Data and code during processing	Trust in the hardware vendor, firmware, and threat model	Near-native speed, but hardware dependence and side-channel risk
Homomorphic encryption	Computation directly on encrypted data	Math only, no trusted hardware	Much more computation per operation for many workloads
Secure multi-party computation	Joint computation among parties who distrust each other	Parties do not all collude	Heavy communication between parties
Differential privacy	Information leaked by statistical outputs	A chosen privacy budget	Reduced accuracy as the budget tightens
Federated learning	Keeps raw data on local devices	Honest or constrained participants	Updates can still leak information without extra controls
Local processing	Keeps data on the user's device	The device is secure	Limited by device compute; see local AI privacy

Several of these combine well. Differential privacy limits what a trained model reveals, a TEE protects the training run, and local processing keeps the most sensitive fields from ever leaving the device. Synthetic data, discussed in this explainer on training on artificial data, is another way to reduce exposure by training on records that do not map to real people, though it brings its own privacy questions.

Sometimes the cheapest answer is not a TEE at all. A smaller dataset, tokenization of identifiers, de-identification, or a narrower service boundary can reduce risk with less machinery. Running a model on the user's own hardware avoids the question entirely, at the cost of speed and quality that the hidden cost of running a local LLM explainer lays out.

Performance, cost, and engineering trade-offs

Confidential-computing features can add memory overhead, integrity checks, restricted debugging, special image formats, hardware dependencies, and operational complexity. The Hopper benchmark above shows that inference overhead can be small for large models, but there is no universal percentage that applies to every AI system.

Debugging is a good example of a hidden cost. A protected workload is deliberately opaque to the host, so the tools engineers normally use to inspect a misbehaving service may be disabled or restricted. Teams have to plan for observability that does not undermine the privacy guarantee they are paying for.

Performance testing should use representative data and measure end-to-end behavior: loading, preprocessing, inference, post-processing, network, key release, attestation, and recovery. A benchmark on synthetic data may not predict a production pipeline. Cost matters too, because the strongest design may be more expensive and harder to update than a conventional one, and the value of the protected data should justify it.

Confidential computing and zero trust

Zero-trust security replaces "inside the network means trusted" with continuous verification of identity, device, workload, and request context. Confidential computing fits that philosophy because it can provide evidence about a workload rather than relying on network location. A verified TEE still does not grant unrestricted access to every data source.

The combination works best when policies are explicit: which user may request which model, which data the model may process, which environment is approved, which output may leave the boundary, and how a change is reviewed. Agentic systems raise the stakes, because a protected AI agent that can call external tools extends the data's reach beyond the boundary the TEE enforces.

Governance and compliance boundaries

A technical control can support a compliance objective without proving compliance. Organizations should map confidential-computing claims to specific obligations: confidentiality, access control, auditability, data residency, breach response, retention, and deletion. The legal result depends on jurisdiction, sector, and implementation.

NIST IR 8320E is an initial public draft, and other guidance can change. Standards and certifications should be checked at the time of a real design decision. Do not claim that confidential computing automatically satisfies a privacy law, removes a processor's responsibilities, or makes cross-border processing lawful.

A practical evaluation framework

Start by writing the threat model. Is the concern a malicious cloud administrator, a compromised host, a co-tenant, an untrusted accelerator operator, a compromised workload, or accidental logging? If the threat is undefined, the protection claim will be vague. The TEE.fail result shows how much the answer changes if physical access to the server is in scope.

Next, map the data lifecycle: collection, storage, key release, preprocessing, accelerator movement, inference, output, logging, backup, deletion, and incident response. Mark where plaintext exists and which identity can access it at each step.

Then verify attestation and update behavior. Test approved and unapproved images, revoked keys, failed attestation, rollback, provider maintenance, vulnerability response, and disaster recovery. Check that the evidence corresponds to the binary and configuration that actually processed the data, not to a nearby build.

Finally, compare the design with the alternatives in the table above. Confidential computing may be part of a solution rather than the whole solution.

Misconceptions worth correcting

"Encrypted memory means nothing can leak." Memory encryption protects the contents of memory against certain observers. Timing, access patterns, traffic volume, error behavior, and, as TEE.fail showed, physical bus observation can still reveal information in some designs.

"Attestation proves the software is safe." Attestation proves identity and measured state. Safety is a separate property that depends on code quality and policy.

"A TEE removes the cloud provider from the trust base." It removes the provider from the trust base for specific data paths under a specific threat model. The provider still supplies the hardware, firmware updates, and physical facility, and the hardware vendor sits in the root of trust.

"Confidential computing is a compliance certificate." It is a control. Whether it satisfies an obligation depends on how it is deployed and what the rule actually requires.

What this means

Confidential computing changes the question from "do we trust the cloud operator?" to "which specific operator actions are we trying to make technically impossible, and what evidence do we get that they are?" That is a real improvement, because it replaces a contractual promise with a checkable condition. The record so far, from SGX side channels to a sub-$1,000 DDR5 interposer, shows the guarantees are narrower than the marketing language sometimes implies.

For AI, the practical takeaway is to treat the TEE as one layer in a lifecycle that also includes data governance, endpoint security, output controls, and honest threat modeling. A design that can state which components are inside the boundary, what the attestation covers, and which attackers are out of scope is far more trustworthy than one that simply says "confidential."

Frequently asked questions

Q: What is confidential computing? A: It is a security approach that protects data during processing using hardware-backed isolation, protected memory, and, in most designs, remote attestation. It covers the "data in use" state that storage and network encryption leave exposed.

Q: What is a trusted execution environment? A: A TEE is an isolated execution area whose confidentiality and integrity are enforced by processor hardware and firmware under a stated threat model. Examples include Intel SGX and TDX, AMD SEV-SNP, and Arm CCA.

Q: What is remote attestation? A: Remote attestation is a signed report from the hardware describing the measured software and configuration inside a protected environment. A verifier checks it against a policy before a key service releases secrets to the workload.

Q: Can confidential computing hide my prompts from a cloud provider? A: A suitable confidential-inference design can reduce provider access to prompts while they are processed. The guarantee depends on the hardware, whether the accelerator is covered, the software stack, and what the service logs. It does not help if the endpoint or output path is compromised.

Q: Do confidential workloads run slower? A: Sometimes, by an amount that depends on the workload. One 2024 benchmark of NVIDIA Hopper GPUs found overhead below 7% for most typical large-model queries, with most of the cost coming from CPU-to-GPU transfers. Test with your own pipeline before relying on any figure.

Q: Does confidential computing stop an attacker who has physical access to the server? A: Not reliably. The 2025 TEE.fail research used a low-cost DDR5 interposer to observe memory traffic and extract keys from Intel and AMD systems. Intel and AMD treat such attacks as outside their threat model, so physical security of the data center remains part of the defense.

Q: Is confidential computing the same as homomorphic encryption or differential privacy? A: No. Confidential computing relies on protected hardware, homomorphic encryption computes directly on ciphertext using mathematics alone, and differential privacy limits what statistical outputs reveal. They address different problems and can be combined.

Sources

• NIST, IR 8320E (initial public draft): Hardware-Enabled Security, Confidential Computing of Data in Cloud Workloads, published May 29, 2026.
• Confidential Computing Consortium, confidentialcomputing.io.
• Intel, Trust Domain Extensions overview.
• Apple Security Research, Private Cloud Compute: A new frontier for AI privacy in the cloud, June 10, 2024.
• Zhu et al., Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study, arXiv:2409.03992, 2024.
• Costan and Devadas, Intel SGX Explained, IACR ePrint 2016/086.
• Chuang et al., TEE.fail, IEEE Symposium on Security and Privacy 2026.
• Wikipedia, Confidential computing and Trusted execution environment, used for introduction dates and attack chronology; follow the citations there to primary papers.

This article is educational and does not certify any confidential-computing deployment or constitute a security assessment, legal opinion, or implementation recommendation.

---

Read next:

• How Large Language Models Work: Transformers, Attention, and Why They Hallucinate
• Edge AI: How AI Runs on Your Phone
• AI Ethics: The Key Debates Shaping How AI Gets Built