Beyond Encryption · Part 1 of 7
Protecting sensitive data while it is being processed.
TL;DR
- Data has three states: at rest, in transit and in use.
- Traditional encryption mainly protects data at rest and in transit.
- Confidential computing extends protection to data while it is being processed.
- It uses a hardware-backed Trusted Execution Environment, or TEE.
- Remote attestation provides evidence that the expected hardware and security settings are active.
- A TEE can reduce trust in the host, hypervisor and cloud operator.
- It does not fix application vulnerabilities, insecure endpoints or poor identity controls.
- Confidential computing should be driven by a clear threat model, not by a product label.
Table of contents
- Why encryption still leaves a gap
- The three states of data
- What is confidential computing?
- What is a Trusted Execution Environment?
- How confidential computing changes the trust boundary
- How remote attestation works
- What confidential computing protects
- What confidential computing does not protect
- When should you use confidential computing?
- Questions to ask before adopting it
- Frequently asked questions
- Key takeaways
Why encryption still leaves a gap
Consider a well-protected cloud application.
Its database is encrypted. Connections use TLS. Backups are protected with separate encryption keys. Identity controls limit who can access the application. Administrative roles are separated and logged.
This is a strong security foundation. It still leaves one important question unanswered.
What happens when the application reads a customer record, analyses a transaction or sends a prompt to an AI model?
The data must become available to the processor. A database engine cannot compare two values if it cannot interpret them. An AI model cannot analyse data that remains unreadable. An application cannot use a cryptographic key without loading it into an execution context.
In a traditional environment, privileged infrastructure layers may have technical access to this active state. Those layers can include the host operating system, hypervisor, platform management software and administrative tooling.
The risk is not limited to a cloud employee deliberately reading customer memory. A compromised host, vulnerable hypervisor, incorrect privilege assignment or malicious insider may create the same result. The security question is therefore architectural: which components must be trusted not to inspect or alter data while it is being processed?
Confidential computing is designed to reduce that trust.
Figure 1. Encryption at rest, encryption in transit and confidential computing protect different data states. Original infographic created for this Interian series.
The three states of data
Data at rest
Data at rest is not actively moving or being processed. Examples include databases, virtual disks, object storage, snapshots, backups and local files.
Storage encryption helps protect this data if someone steals a disk, accesses a snapshot without permission or obtains a raw copy of a database. Modern cloud platforms usually provide several layers of at-rest encryption, including platform-managed keys and customer-managed keys.
Its effectiveness still depends on good key management. If an attacker can obtain both the encrypted data and its decryption key, the encryption boundary has failed. At-rest encryption also does not determine what an authorised process may do after it receives the plaintext.
Data in transit
Data in transit moves between systems. Examples include traffic between a browser and an API, an application and a database, or two cloud environments.
TLS, mutual TLS and IPsec can protect data against interception and modification during transport. These controls protect the connection, but they do not control what each endpoint does after receiving the data. A secure tunnel to a compromised endpoint still ends at a compromised endpoint.
Data in use
Data in use is being processed by a CPU, GPU or another accelerator. It may exist in memory, CPU state, application buffers, caches or temporary files.
Traditional systems normally trust the infrastructure layers that manage this processing environment. Confidential computing attempts to place selected infrastructure components outside the trust boundary.
The three protection models are complementary. Confidential computing does not replace storage encryption or secure network protocols. A complete design protects data before it enters the processing environment, while it is being processed and after it leaves.
What is confidential computing?
The Confidential Computing Consortium defines confidential computing as protecting data in use by performing computation inside a hardware-based, attested Trusted Execution Environment.
This definition has three important elements.
- Hardware-backed protectionThe isolation is enforced by processor technology, rather than only by the operating system or hypervisor.
- A Trusted Execution EnvironmentSensitive code and data are processed inside an isolated execution boundary.
- AttestationThe environment can provide cryptographic evidence about its identity, configuration and measured state.
The Confidential Computing Consortium treats attestation as a core part of confidential computing. Isolation without evidence still forces a data owner to trust the platform operator’s statement that the correct controls are active.
Confidential computing is also different from fully homomorphic encryption. A TEE provides a protected place where authorised code can process usable data. It does not normally perform arbitrary application logic directly on ciphertext.
What is a Trusted Execution Environment?
A Trusted Execution Environment is a protected area of processor and memory resources.
Authorised code can work with data inside the TEE. Code outside the protected environment should not be able to read or alter that data directly. The data remains usable inside the boundary, but memory appears encrypted when accessed from outside it.
Microsoft describes a TEE as a segregated area of memory and CPU that protects code and data from the rest of the system. A security processor embedded within the CPU manages that protection. Microsoft Learn: Trusted Execution Environment.
There are two broad implementation models.
A confidential virtual machine can protect an entire guest operating system and its applications. Technologies such as AMD SEV-SNP and Intel TDX follow this model. Existing applications can often move into a confidential virtual machine with fewer changes, which makes this model attractive for lift-and-shift and platform migration scenarios.
An application enclave protects a smaller part of an application. Intel SGX is a common example. This can create a smaller trust boundary, but the application usually needs to be designed or adapted for the enclave programming model.
Neither option is automatically better. The right choice depends on the threat model, acceptable development effort and amount of code that must remain trusted.
How confidential computing changes the trust boundary
Every secure system has a Trusted Computing Base, commonly called the TCB.
The TCB contains every hardware, firmware and software component whose failure could undermine the security of the system. A smaller TCB is generally easier to understand, test and protect.
In a traditional virtual machine, the confidentiality boundary usually depends on:
- The processor and platform firmware
- The host operating system
- The hypervisor
- Cloud management components
- The guest operating system
- The application
A confidential virtual machine aims to remove the host, hypervisor and cloud management layers from the confidentiality and integrity boundary for guest memory and CPU state.
The processor, security firmware, guest operating system and application remain trusted. An enclave can reduce the boundary further by placing only a limited part of the application inside it.
Microsoft’s Trusted Computing Base guidance explains that a compromised TCB component can compromise the whole security promise. The exact contents of the TCB depend on the TEE model and platform configuration.
Confidential computing does not remove trust. It relocates trust, reduces the number of trusted components and makes selected properties verifiable.
That distinction matters when discussing data sovereignty. Residency tells you where data is stored. Confidential computing can help control which technical actors can see plaintext during processing. These are related controls, but they answer different questions.
How remote attestation works
A TEE is useful only if another party can verify that it is genuine and correctly configured.
Remote attestation provides that evidence.
A simplified process looks like this:
- A confidential workload starts.
- The TEE produces hardware-backed evidence.
- An attestation service validates the signature and endorsement chain.
- The service compares the resulting claims with an approved policy.
- A relying party, such as a key service, receives the verified result.
- A key or dataset is released only if the policy succeeds.
Figure 2. A simplified attestation and conditional key release process. Original infographic created for this Interian series.
Attestation evidence can include measurements of the initial workload, firmware security versions, platform settings and information about the processor.
AMD SEV-SNP measures the initial memory contents and related page metadata during launch. Its security processor signs an attestation report that a remote verifier can validate. AMD: SEV-SNP Strengthening VM Isolation with Integrity Protection and More.
Intel TDX provides hardware-isolated virtual machines known as Trust Domains. Remote attestation can provide evidence that TDX protections are active and that the expected initial software state was loaded. Intel: What Is Intel Trust Domain Extensions.
Microsoft Azure Attestation receives evidence, converts it into claims, evaluates those claims against configurable policy and returns a signed result for relying parties. Microsoft Azure Attestation.
The key provider can then enforce a simple but powerful rule: no valid evidence means no key. No key means the protected data remains encrypted.
This should be implemented as fail-closed behaviour. If attestation times out, produces an unknown status or contains claims that are outside policy, the workload should not receive the sensitive material.
Attestation does not prove that an application is free from vulnerabilities. It proves that a particular measured environment meets a defined policy. If an approved application image contains a security flaw, the attestation result can still be valid.
A real Microsoft sample
Figure 3. Microsoft’s Visual Attestation Demo runs the same container image on a confidential Azure Container Instance and a standard instance. The confidential instance obtains an attestation result. The standard instance fails because the required SEV-SNP device is absent. Source: Azure Samples Confidential Computing, Visual Attestation Demo v2. The repository is published under the MIT Licence. This is an official Microsoft sample screenshot. It is not an Interian lab result, benchmark or validation.
The comparison is useful because the failure case is as important as the successful result. The same application image cannot produce genuine SEV-SNP evidence when the underlying hardware interface is missing. A relying party can therefore make access conditional on evidence that a standard container cannot provide.
What confidential computing protects
The exact protection depends on the TEE technology, firmware level, workload design and platform configuration. A well-designed confidential computing solution may protect against the following threats.
| Threat | Primary control | Important condition |
|---|---|---|
| Stolen storage or snapshots | Encryption at rest | Keys must be managed separately |
| Network interception | TLS or mutual TLS | Both endpoints must be authenticated |
| Host administrator reading workload memory | Confidential computing | TEE settings must be correct |
| Compromised hypervisor | Confidential computing | The hypervisor must sit outside the relevant TCB |
| Another tenant accessing active memory | Hardware-backed isolation | Normal tenant isolation remains necessary |
| Release of secrets to the wrong environment | Attestation and release policy | Claims must be checked against strict reference values |
| Modified workload image | Measurements and attestation | Approved measurements must be maintained |
| Replay of old evidence | Nonce and freshness validation | The verifier must reject stale evidence |
The goal is not to make the infrastructure harmless. The goal is to prevent selected infrastructure layers from gaining access to sensitive code and data, even when those layers have high privileges.
What confidential computing does not protect
Confidential computing is not a complete security architecture.
It does not automatically prevent:
- Vulnerabilities in trusted application code
- Malicious code inside an approved image
- Weak authentication or excessive permissions
- Data leakage by an authorised user
- Compromise of the user’s endpoint
- Unsafe output sent outside the TEE
- Denial of service by the host or platform
- Every possible side-channel attack
- Poor key rotation, recovery or revocation processes
- Outdated firmware accepted by an overly broad policy
Hardware also requires security maintenance. Firmware and microcode versions may need to be reflected in attestation policies. A policy that accepts every version forever provides weaker assurance than one that responds to security advisories and defined minimum TCB levels.
AMD, for example, documents microarchitectural side-channel techniques that it considers outside parts of the published SEV-SNP threat model and recommends software controls such as constant-time algorithms and avoiding secret-dependent data access where appropriate. AMD security guidance for TDXRay.
Identity also remains necessary. Attestation answers questions about the execution environment. Identity answers which user or workload is making a request. A robust key release design usually needs both. An approved TEE should not receive every key, and an authorised identity should not receive a key from an unverified environment.
Endpoint security remains equally important. If an authorised user downloads protected data to a compromised laptop, the server-side TEE cannot keep that local copy confidential.
When should you use confidential computing?
Confidential computing is most relevant when privileged infrastructure access forms part of the threat model.
Typical scenarios include:
- Processing regulated data in a public cloud
- Protecting sensitive AI prompts, models or training data
- Running cryptographic or signing services
- Analysing data from organisations that do not fully trust each other
- Reducing cloud operator access to plaintext data
- Protecting sensitive intellectual property during processing
- Releasing keys only to approved workload versions
- Supporting high-sensitivity environments with restricted administrative paths
The technology may be less useful when the main risk sits inside the application, when data is immediately exported to unmanaged endpoints or when the organisation cannot maintain attestation policies and reference measurements.
There is also an operational cost. Teams must understand which measurements change during an update, how firmware advisories affect acceptable TCB levels, how release policies are rotated and how failed attestations are investigated. Availability and disaster recovery designs must account for a verifier or key service being unavailable.
Start with the threat model, not the product catalogue.
Questions to ask before adopting it
Before selecting a confidential VM, container or enclave, answer these questions:
- Which data needs protection during processing?
- Which privileged actors must sit outside the trust boundary?
- Which components remain inside the TCB?
- Which hardware, firmware and workload measurements are acceptable?
- Who generates, verifies and consumes the attestation evidence?
- How is freshness established and replay prevented?
- Which key, secret or dataset is released after successful verification?
- What happens when verification fails or the verifier is unavailable?
- How are approved measurements updated during a software release?
- Which evidence is retained for audit without exposing sensitive information?
These questions turn confidential computing from a checkbox into an architecture.
Frequently asked questions
Is confidential computing the same as encryption?
No. Encryption is one of the technologies used by confidential computing, but confidential computing also requires hardware-backed isolation and attestation.
Is data still decrypted inside a TEE?
Yes. Authorised code needs usable data to perform calculations. The TEE creates a protected location for that processing. Memory and CPU state are protected from components outside the security boundary according to the guarantees of the selected TEE.
Does a confidential virtual machine protect against application attacks?
Not automatically. If an attacker exploits the application or guest operating system, the attacker may operate inside the trusted boundary. Secure development, patching and runtime controls remain essential.
Does confidential computing replace Zero Trust?
No. It complements a zero-trust architecture. Identity controls determine who or what is requesting access. Attestation provides evidence about where the workload runs and which security properties are active.
Is confidential computing only available in Microsoft Azure?
No. Confidential computing is an industry model supported by several hardware vendors, cloud providers and private infrastructure platforms. Azure provides confidential VMs, confidential container options and Microsoft Azure Attestation, but the underlying principles are not Azure specific.
Is attestation a one-time check?
That depends on the design. Some attestation happens during boot or launch. Applications can also request evidence later and bind it to a nonce or protocol exchange. Teams must decide whether launch-time evidence is sufficient or whether their threat model requires repeated or runtime integrity checks.
Key takeaways
- Encryption at rest and in transit does not fully protect data during processing.
- Confidential computing extends protection to data in use.
- A TEE creates a hardware-enforced boundary around selected code and data.
- Attestation provides evidence before sensitive data or keys are released.
- The technology can reduce trust in the host, hypervisor and cloud operator.
- It does not replace application security, endpoint security, identity or key management.
- Fail-closed key release is stronger than treating attestation as an informational dashboard.
- A precise threat model is more important than a confidential computing product label.
