The Confidential-Computing Threat Model — Confidential AI & Trusted Execution

Security is mostly a question of where trust begins and where it ends. Confidential computing is often described as a way to protect data in use, but that phrase is too neat unless we ask the harder question: protected from whom, by what mechanism, and under what assumptions? A useful threat model turns the promise into an engineering tool. It says what the hardware and software must defend, what they cannot defend, and what decisions follow.

The missing third state of data

Most security programs already understand two states of data. Data at rest is stored on a disk, in a database, or in an object store. Data in transit is moving across a network. Encryption is mature in both places: stored data can be encrypted before it is written, and network traffic can be protected by protocols such as Transport Layer Security, often called TLS.

The harder state is data in use. A processor must see usable values to compute on them. A database must compare a name, a model must score a prompt, and an analytics job must add a number. At that moment, data is normally present in memory in a form the running program can use. That creates a large trust assumption: the operating system, hypervisor, cloud administrator, firmware, and debugging tools may all sit close enough to observe or influence the computation.

Confidential computing narrows that trust assumption. It uses hardware-backed isolation so selected code and data can run in a protected area even when the surrounding system is not fully trusted.

Encryption is mature at rest and in transit; data in use is the exposed third state confidential computing protects.

Begin with the asset, not the technology

A threat model starts with the thing that must remain safe. That asset may be a cryptographic key, a training data set, a patient record, a fraud signal, a search query, or a machine learning model weight. It may be confidentiality, meaning the attacker must not learn it. It may be integrity, meaning the attacker must not change it. It may be both.

Only after naming the asset can you name the attacker. Confidential computing is mainly designed for cases where the attacker may control or observe parts of the platform around the workload. That can include a malicious administrator, a compromised host operating system, a hostile co-tenant trying to exploit shared hardware, or malware with high privilege on the machine.

This is different from ordinary application security. If the threat is a user guessing another user’s password, confidential computing is not the first control. If the threat is a cloud operator, a server administrator, or platform malware reading memory, it may be relevant.

What exact data, key, model, or computation is the asset?
Who is not allowed to see or change it?
Which parts of the system are allowed to be trusted?
What evidence will prove the workload is the expected one?
What happens if the protected workload is unavailable?

The protected boundary

The core building block is a trusted execution environment, or TEE. A TEE is a hardware-backed boundary that protects selected code and data from software outside that boundary. Depending on the design, the protected unit may be a small enclave inside a process or an entire confidential virtual machine, where a virtual machine, or VM, is an isolated computer emulated on shared hardware.

The central processing unit, or CPU, enforces the boundary. It can encrypt memory used by the protected workload, restrict access by privileged software, and create measurements of what code was loaded. The surrounding operating system and hypervisor may still schedule the workload, provide storage, and deliver network packets, but they should not be able to read protected memory or silently replace protected code without detection.

This boundary is powerful but narrow. It does not make unsafe code safe. It does not make a wrong result right. It does not stop the workload from sending its own secrets to the wrong place. It changes who must be trusted for memory confidentiality and code identity.

A hardware-enforced TEE shields protected code and data while the host and hypervisor stay outside it.

Attestation turns isolation into proof

Isolation alone is not enough. A remote party needs to know whether it is talking to the intended protected workload or to an impostor. Attestation is the process of producing and checking evidence about the hardware, firmware, configuration, and loaded code before releasing secrets or trusting results.

A typical flow begins when the TEE measures the workload. A measurement is a cryptographic digest, which is a short value derived from the code and configuration in a way that changes if they change. The hardware signs a statement containing that measurement. A verifier checks the statement against a policy. Only then does a key service, data owner, or peer system release sensitive data.

Attestation is where the threat model becomes operational. It connects a policy such as only this signed workload, on approved hardware, with debugging disabled to an action such as release the database key.

📌

Evidence first. In a strong design, the secret is not present until attestation has succeeded.

Attestation measures the workload, signs the evidence, verifies it against policy, then releases the secret.

What the model does not promise

A good threat model is as clear about exclusions as it is about protections. Confidential computing does not remove every trusted party or every attack path. The TEE may protect memory from the host, but the host can often still stop the workload, delay it, starve it of resources, or feed it malformed input.

Side channels are a major example. A side channel is a way to infer secrets from indirect signals, such as timing, cache behavior, power use, or input and output patterns. Some confidential-computing systems reduce specific side channels, but few eliminate all of them. The practical question is whether the remaining leakage matters for the asset and attacker you named.

Application bugs still matter. If code inside the TEE has an injection flaw, deserializes untrusted data unsafely, logs secrets, or calls an untrusted service with sensitive content, the boundary will not save it. Confidential computing protects a workload from parts of its environment; it does not protect the workload from itself.

Denial of service, where an attacker prevents the workload from running.
Bugs inside the protected application.
Secrets deliberately sent outside the protected boundary.
Metadata leakage, such as who talked to whom and when.
Side channels that reveal information through timing or resource use.
Compromised clients before data enters the protected workload.

⚠️

Do not overclaim. Confidential computing narrows trust; it does not make a system automatically private, correct, or available.

When confidential computing is worth the cost

Confidential computing is most useful when ordinary isolation is not enough for the relationship between parties. One organization may need to process another organization’s data without being able to read it. A regulated workload may need to reduce administrator access to sensitive memory. A model owner may want to serve a model while lowering the chance that platform operators can extract its weights.

It is less compelling when the same team already controls the application, host, identity, and data with a normal level of trust. The technology adds design work: attestation policies, key release flows, image signing, limited debugging, performance testing, and operational runbooks. Those costs are justified only when the threat model needs the extra boundary.

A useful rule is to ask whether you are trying to protect data from the infrastructure that runs the computation. If yes, confidential computing belongs in the design discussion. If no, conventional controls may be simpler and stronger.

Confidential computing pays off only when you must protect data from the infrastructure that runs it.

Decisions leaders and practitioners must make

The first decision is whether the business problem truly requires protecting data from the operator of the infrastructure. This is a governance question as much as a technical one. If the answer is yes, the team must decide which assets enter the protected boundary, which services stay outside it, and which risks remain accepted.

The second decision is how secrets are governed. Keys should not be baked into images or placed in ordinary configuration files. A key release service should check attestation evidence and identity before issuing secrets. In Microsoft environments, that identity may be managed with Microsoft Entra ID, but identity alone is not the same as attestation; the design should bind both who is asking and what measured workload is asking.

The third decision is operational readiness. Teams need a plan for patching, rotating measurements after updates, responding to failed attestation, collecting useful logs without leaking secrets, and debugging production issues when privileged inspection is intentionally limited. Confidential computing is not just a runtime feature. It changes the release process.

Name the assets and the untrusted parties.
Choose the smallest practical protected boundary.
Define attestation policy before handling real secrets.
Design key release around evidence, not convenience.
Test performance, failure modes, and observability early.
Record which threats remain out of scope.

A simple way to write the threat model

A confidential-computing threat model can fit on a few pages if it is written plainly. Start with the asset. State who must not learn or change it. Draw the protected boundary. List what is trusted inside it and what is not trusted outside it. Then describe the evidence required before secrets are released.

Next, list attacks in three groups: prevented, detected, and accepted. Prevented attacks are those the TEE should block, such as a host reading protected memory. Detected attacks are those attestation should reveal, such as a modified workload image. Accepted attacks are real risks the design does not solve, such as denial of service or certain side channels.

Finally, keep the model alive. Every software update changes measurements. Every new dependency may change the trusted code base. Every new integration may create a path for secrets to leave the boundary. The model is not a document you finish; it is a map you revise as the system changes.

✅

Plain test. If the team cannot say who is no longer trusted after adding confidential computing, the design is not ready.

Key takeaways

Confidential computing protects selected data and code while computation is happening, not just while data is stored or moving.
The threat model should start with assets and attackers, not with hardware features.
A trusted execution environment narrows trust in the host, hypervisor, and administrators, but it does not remove all trust.
Attestation is the bridge between a protected workload and a policy decision to release secrets.
Side channels, application bugs, denial of service, and compromised clients can remain in scope even when memory is protected.
Operational processes must handle measurement changes, key release, logging, patching, and failed attestation.

Glossary

Confidential computing: A set of techniques that use hardware-backed isolation to protect data and code while they are being processed.
Trusted execution environment: A protected area enforced by hardware where selected code and data can run with reduced trust in the surrounding system.
Attestation: The process of producing and verifying evidence about the hardware, configuration, and code of a protected workload.
Measurement: A cryptographic value that represents the code and configuration loaded into a protected environment.
Hypervisor: Software that creates and manages virtual machines on shared physical hardware.
Virtual machine: An isolated computing environment that behaves like a separate computer while running on shared hardware.
Side channel: An indirect signal, such as timing or resource use, that can reveal information even when direct access is blocked.
Denial of service: An attack that prevents a system from operating normally rather than stealing or changing its data.