TEEs, Enclaves and Attestation — Confidential AI & Trusted Execution

Most security controls protect data before it is used or after it is stored, but the hardest moment is the middle: when software is running and data must be visible to the processor. Trusted execution environments, enclaves and attestation are attempts to make that moment safer. They do not remove the need for good software, identity, monitoring or governance, but they change the trust model in an important way: you can ask not only “where is this running?” but “what exactly is running, on what hardware, in what protected state, and can it prove it?”

Start with the vulnerable moment: data in use

Data is usually described in three states. Data at rest is sitting in storage, such as a database, disk or object store. Data in transit is moving across a network. Data in use is being processed by software in memory and registers inside a computer. Encryption for data at rest and data in transit is mature and widely deployed. Data in use is harder, because useful computation normally requires the processor to see the data in a form it can operate on.

A trusted execution environment (TEE) is a protected area for computation. The goal is to let selected code run with selected data while reducing what the rest of the system can inspect or change. The operating system, hypervisor, administrators and neighboring workloads may still exist, but the TEE tries to limit their ability to read the protected memory or tamper with the protected execution.

This is not the same as making the whole machine trustworthy. It is a narrower promise: a specific workload, or a specific part of a workload, gets stronger isolation while it is running.

📌

The core idea. A TEE is about protecting computation while it is happening, not just protecting files or network traffic.

What an enclave is

An enclave is a common form of TEE. Think of it as a guarded room inside a larger building. The building still has electricity, networking, storage, administrators and other tenants, but the guarded room has extra rules about who can see inside and who can change what happens there.

In practice, an enclave is created by hardware and low-level firmware working together with software. The processor reserves memory for the enclave, encrypts or otherwise protects that memory, and enforces access rules. Code outside the enclave can call into it through defined entry points, but it should not be able to freely read the enclave’s protected memory.

Different technologies draw the boundary in different places. Some protect a small library or function. Some protect a whole virtual machine. Some are designed for mobile devices, some for servers, and some for cloud infrastructure. The shared pattern is isolation backed by hardware rather than isolation based only on operating system permissions.

Trust moves from the administrator to the machine boundary

Traditional server security often assumes that whoever controls the host has broad power. A privileged administrator can inspect memory, attach debuggers, change configuration or replace software. Virtualization improves separation between workloads, but the hypervisor and cloud operator remain highly privileged in the model.

A TEE changes the trust relationship. The workload owner is not merely trusting the administrator or cloud provider to promise good behavior. The workload owner can rely on a hardware-enforced boundary, subject to the quality and limits of that hardware and its implementation. This is why TEEs are important in multi-tenant clouds, partner data collaboration, regulated workloads and confidential artificial intelligence scenarios.

For example, an organization might run a sensitive model inference service where customer prompts, proprietary model weights or regulated records must be protected from unnecessary exposure. A confidential virtual machine can reduce the visibility of the host platform into the guest workload, while identity, key management and application controls still decide who is allowed to use the service.

Traditional security trusts privileged people; a TEE shifts trust to a hardware-enforced boundary.

Attestation is the proof step

Isolation is useful, but a remote party still needs proof. If a service says, “send me the secret; I am running inside a protected enclave,” you should not have to take that statement on faith. Attestation is the process of producing and checking evidence about a protected environment.

The usual pattern has four parts. First, the hardware or platform measures what is being launched, meaning it records cryptographic fingerprints of code, configuration and sometimes firmware. Second, the platform signs a report using a key or certificate chain rooted in the hardware vendor or cloud platform. Third, a verifier checks the report against expected values and policy. Fourth, if the evidence is acceptable, the verifier releases a secret, grants access or allows the session to continue.

Attestation is what turns a TEE from a local protection feature into a trust-building protocol. It lets one system make a decision about another system that it cannot physically inspect.

✅

Proof before trust. Attestation lets a system require evidence of the runtime state before it releases a key, token or sensitive data.

The platform measures the workload, signs a report, a verifier checks policy, then a secret is released.

The hard part is deciding what counts as good evidence

An attestation report is only useful if someone knows how to interpret it. A cryptographic signature can show that evidence came from a genuine platform, but it does not automatically mean the workload is safe. The verifier still needs policy: which hardware versions are acceptable, which firmware levels are allowed, which code measurements match approved builds, and which configuration settings are required.

This is where many designs become operational rather than theoretical. Teams need a release process that records expected measurements, a way to rotate policy when software changes, and a response plan when a vulnerability affects an allowed processor, firmware version or library. Without those practices, attestation can become a ceremony that always says yes.

Identity also matters. In a cloud deployment, attestation may be combined with workload identity, managed identities, certificates, secrets services and access policies. For example, Microsoft Entra ID can help control who or what may request access, while attestation evidence can help prove the runtime state of the workload making the request. These are different questions and both are important.

Accept evidence only from trusted roots and current certificate chains.
Compare measurements against approved builds, not vague environment names.
Bind released secrets to the attested workload, session or identity where possible.
Plan for revocation when hardware, firmware or software is no longer acceptable.
Log attestation decisions so failures and unexpected changes are visible.

What TEEs do not solve

A TEE is not a force field around an application. If the code inside the enclave has a bug, the enclave can faithfully protect the execution of vulnerable code. If the application sends secrets to the wrong destination, the enclave will not necessarily stop it. If an authorized user asks for data they should not see, the TEE does not replace authorization logic.

Side-channel attacks are a special concern. A side channel is an indirect signal, such as timing, memory access patterns, power use or cache behavior, that may reveal information even when direct memory reads are blocked. Modern TEE designs include mitigations, but side channels remind us that “cannot read memory directly” is not the same as “can learn nothing.”

TEEs also depend on supply chains. Processors, firmware, microcode, cloud infrastructure, compilers, libraries and build systems all affect the trust story. When vendors publish security advisories, the policy that once accepted a platform may need to change.

⚠️

Not magic. A TEE narrows who can inspect or tamper with a workload, but it does not make unsafe code, weak policy or poor operations safe.

Where the pattern shows up in real systems

TEEs appear at several sizes. At the small end, a hardware enclave may protect a cryptographic operation, a private key or a sensitive function. At the larger end, a confidential virtual machine may protect most of a guest operating system and its application stack from the host. Between those points are containers, language runtimes and specialized accelerators with varying security properties.

Common use cases include protecting keys during use, processing regulated records in a shared environment, enabling analytics across organizations that do not want to reveal raw data to each other, and reducing exposure in machine learning workloads. In Microsoft environments, confidential computing capabilities in Azure can be combined with key management, network isolation, Microsoft Entra ID and application controls. For artificial intelligence projects built with Microsoft Foundry, the same principles matter when deciding where prompts, embeddings, model weights and retrieval data are processed.

The most practical question is not “do we use TEEs everywhere?” It is “which trust boundary is too broad today, and would a TEE make that boundary meaningfully smaller?”

TEEs range from a small enclave around one function to a confidential VM protecting a whole guest OS.

Decisions for leaders and practitioners

A leader deciding whether to invest in TEEs should start with the threat model. A threat model is a clear statement of what you are protecting, from whom, under which assumptions. TEEs are most compelling when you need to reduce trust in the host, cloud operator, administrator, partner environment or co-tenant workload. They are less useful when the main risk is bad application logic, over-permissive users or poor data classification.

Practitioners should design the attestation path early, not as an afterthought. Decide who verifies evidence, what policy is checked, how secrets are released, what happens when verification fails, and how deployment pipelines update expected measurements. Also test the operational experience: debugging, patching, performance, observability and incident response can all be different when memory and runtime state are deliberately harder to inspect.

The best deployments are boring in the right way. They make a specific trust decision more concrete, automate the evidence check, fail closed when evidence is wrong, and document the remaining assumptions.

Use a TEE when the host or operator is part of the risk you need to reduce.
Require attestation before releasing sensitive keys, tokens or data.
Treat approved measurements as release artifacts that must be governed.
Measure performance and supportability before moving critical workloads.
Document residual risks, especially side channels, code defects and supply chain dependencies.

Key takeaways

A trusted execution environment protects selected computation while data is in use.
An enclave is a protected boundary, often backed by hardware, with controlled access to code and memory.
Attestation provides signed evidence about what is running and where, so a verifier can make a policy decision.
The value of attestation depends on clear policy, approved measurements, revocation and operational discipline.
TEEs reduce some forms of trust in hosts and operators, but they do not fix vulnerable code, weak authorization or side channels.
The right question is which trust boundary you need to shrink, not whether every workload should run in a TEE.

A TEE fits when you must reduce trust in the host or operator, not when the risk is app logic or access.

Glossary

Trusted execution environment (TEE): A protected area for running code and handling data with stronger isolation than the surrounding system normally provides.
Enclave: A specific protected execution boundary inside a larger system, typically enforced by hardware and accessed through controlled entry points.
Attestation: The process of producing and verifying evidence about a system’s hardware, software and configuration state.
Measurement: A cryptographic fingerprint of code, configuration or firmware used to identify what was launched.
Verifier: The party or service that checks attestation evidence against policy before granting trust.
Root of trust: A hardware, firmware or cryptographic foundation that other trust decisions depend on.
Side channel: An indirect signal, such as timing or cache behavior, that may reveal information without directly reading protected data.
Confidential virtual machine: A virtual machine designed to protect the guest workload from parts of the underlying host infrastructure.