Shrinking confidential computing trust boundaries across SGX and CVMs

At a glance

What this is: This is Fortanix’s case for keeping confidential computing trust boundaries small across SGX and confidential VMs, with the key finding that large guest stacks are a design choice rather than an inevitability.

Why it matters: It matters because IAM and platform teams relying on enclaves, attestation, and workload isolation need to know where the trust boundary really sits before they treat a confidential VM as equivalent to an enclave.

Context

Confidential computing protects data and code while they are in use, but the protection boundary is only as strong as the software and firmware placed inside it. When that boundary absorbs an operating system, boot code, and transport layers, the trusted computing base grows quickly and the attacker’s leverage grows with it.

Fortanix’s article argues that the small-trust-boundary model associated with confidential computing can extend beyond SGX to confidential virtual machines, but only if the platform is designed around a minimal runner, attestation-aware startup, and tight control over host-facing interfaces. That is a governance issue for identity and workload trust, not just an architecture preference.

Key questions

Q: How should teams evaluate whether a confidential VM trust boundary is too large?

A: They should enumerate every component inside the protected boundary and ask whether the workload truly needs it. If firmware, kernel code, and host-facing transport layers are included by default, the boundary is probably too wide for the security gain being claimed. The test is not whether the VM is encrypted, but whether the minimum necessary code is the only code trusted with the workload.

Q: Why does attestation matter more when a confidential VM includes firmware and a kernel?

A: Because attestation only proves what was measured, and a large guest stack creates more code paths that can shape the measured outcome or sit outside it. If the real startup path is not covered, the trust claim stops at the encryption layer and does not extend to the software that actually booted the workload.

Q: What is the main governance mistake teams make with confidential computing migrations?

A: They treat lift-and-shift as if it preserves the same trust model. In practice, moving a server into a confidential VM often drags the old firmware, kernel, and runtime assumptions into the trust boundary, which makes the deployment easier but weakens the security objective the platform was meant to deliver.

Q: How should practitioners decide between preserving compatibility and shrinking the trusted base?

A: They should prioritise the smaller trusted base whenever the workload can tolerate it, because compatibility that depends on a full guest stack can erase the value of confidential computing. The right decision is the one that keeps the protected surface small enough to audit and verify without inheriting unnecessary system code.

Technical breakdown

Why a confidential VM can inherit a large trusted computing base

A confidential VM is not automatically small in scope. If teams lift and shift an existing server into the trust boundary, they also bring firmware, kernel code, userland assumptions, and host-facing interfaces into the protected perimeter. That changes the attack surface because the hypervisor, memory-mapped I/O, hypercalls, shared memory, and injected interrupts become inputs the guest must tolerate. In other words, the security model shifts from protecting one application to protecting a full operating-system stack from an untrusted infrastructure provider. See the Confidential Computing Guide.

Practical implication: Treat the guest stack as part of the security boundary review, not as harmless platform plumbing.

How an enclave runner reduces exposed trust surface

The article’s core architectural pattern is a runner that loads the enclave, handles requests, and keeps the application interface narrow. In SGX, that interface is deliberately tiny and designed to withstand Iago-style manipulation, where the host feeds back malicious return values to influence protected code. The same principle can apply to VM-based enclaves if the guest avoids unnecessary host-facing layers and preserves a small, auditable call surface. The smaller the interface, the fewer places the host can influence enclave behaviour without detection.

Practical implication: Design around a minimal runner interface and audit every boundary crossing as if the host may be hostile.

Why removing Linux from the trust boundary changes attestation

Today’s VM-based approach still places Linux inside the trust boundary as an interim measure, but the article’s direction is to remove it either by letting the standard library take over startup and runtime duties or by replacing Linux with a formally verified microkernel. That matters because attestation should cover exactly what executes at startup, not a large inherited environment that the application never needs. If the launch measurement does not include the real boot path and memory layout, the attestation story becomes weaker than the isolation story appears.

Practical implication: Align attestation scope with the actual boot path and eliminate guest components the application does not need.

NHI Mgmt Group analysis

Small trust boundaries are the real security control in confidential computing, not the marketing label on the platform. The article makes clear that a confidential VM can be built either as a thin execution envelope or as a full operating-system stack wrapped in encryption. That distinction matters because identity and workload trust are only as strong as the smallest component that can still influence execution. Practitioners should evaluate confidential computing designs by how much code they actually trust, not by whether the workload sits in an enclave or a VM.

Attestation only carries weight when it covers the full startup path and not just the idealised workload. If firmware, kernel code, or transport logic sits inside the boundary, those components also need to be measured, verified, and governed. That is the hidden governance problem in many confidential VM deployments: the trust anchor may be strong, but the measured surface is still too broad. Practitioners should insist that launch measurements and runtime assumptions match the real guest composition.

Workload identity for confidential computing should be tied to execution scope, not infrastructure form factor. The article shows that SGX, Nitro Enclaves, SEV-SNP, and TDX can all host the same application model if the trust boundary is disciplined. That means the operational question is not whether a platform is an enclave or a VM, but whether the workload has a minimal, attestable identity surface. Practitioners should treat enclave identity as a property of the runtime boundary, not the deployment label.

Lift-and-shift is the wrong mental model for confidential computing. Moving an application into a CVM together with the firmware and operating system it expects preserves convenience but expands risk, because the host-facing interfaces of the guest stack become part of the trusted perimeter. That is the failure mode the article tries to correct: platform migration that preserves compatibility while silently defeating the purpose of confidential computing. Practitioners should redesign for the trust boundary they want, not the stack they inherited.

TCB minimisation is becoming a portability strategy, not just a security preference. The article points toward a future where the same Rust application can run across SGX, Nitro Enclaves, SEV-SNP, and TDX while keeping the trusted base close to the application and standard library. That signals where confidential computing is heading: away from platform-specific monoliths and toward thin, attestable runtimes. Practitioners should plan for portability that depends on boundary discipline, not on one vendor-specific execution model.

Read next: Confidential Computing Guide

What this signals

TCB minimisation is becoming the selection criterion for confidential computing platforms. As more workloads move from SGX-style enclaves to confidential VMs, practitioners will need to compare boundary size, not just encryption features. The operational question is whether the runtime can keep firmware, kernel code, and transport logic outside the protected perimeter without breaking the workload.

Portability will increasingly depend on boundary discipline. The article points toward a model where the same application can run across SGX, Nitro Enclaves, SEV-SNP, and TDX with the same source code, but only if the trust boundary stays small and measurable. That means architecture teams should plan for attestation, runtime abstraction, and interface hardening as part of the portability strategy.

Confidential computing and workload identity are converging around attested execution. In practice, the identity of the workload will be defined less by the hosting substrate and more by what code and boot path were actually measured at launch. Teams that can prove a smaller and more stable boundary will have a better foundation for policy decisions around sensitive workloads.

For practitioners

• Map the trust boundary explicitly List every component that sits inside the enclave or CVM boundary, including firmware, kernel, transport, and runtime layers, then decide whether each one is actually required for the workload.
• Separate attestation scope from deployment convenience Verify that launch measurements cover the real boot path, page table setup, and guest interfaces rather than assuming the platform’s encryption alone proves trust.
• Minimise host-facing interfaces Prefer the smallest practical interface between protected code and the untrusted world, and treat hypercalls, shared memory, injected interrupts, and transport paths as security-relevant attack surface.
• Reassess lift-and-shift migrations Do not carry a full server stack into a confidential VM unless the added trust assumptions are acceptable and documented for the workload owner.

Key takeaways

• Confidential computing loses much of its value when teams confuse encryption with a small trust boundary.
• The article’s central claim is that a confidential VM can remain close to SGX in trust size if the guest stack is redesigned instead of lifted and shifted wholesale.
• Practitioners should focus on measured startup paths, minimal host-facing interfaces, and boundary size when evaluating confidential computing platforms.

Related NHI Mgmt Group resources: Confidential Computing Guide · Firmware and Boot Security Guide · Encryption Guide · Google Workspace Security Guide

Key terms

• Trusted Computing: A security model that proves a system is in an expected state before trust is granted. In infrastructure IAM, it extends access decisions beyond identity to include software integrity, attestation, and cryptographic proof of execution context.
• Confidential VM: Confidential VM is a virtual machine designed to keep its memory and sensitive execution state protected from the underlying cloud host. It is used to limit exposure of secrets and regulated data in use. Defenders should verify attestation, secure boot and key release controls, and remember that guest misconfiguration can still leak data.
• Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
• Iago Attack: An Iago attack is a manipulation technique where an untrusted operating system or host returns carefully chosen values to a protected program in order to influence its behaviour. It is a key reason confidential computing designs try to minimise and harden host-facing interfaces.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.