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.
What makes a confidential VM boundary too broad?
A confidential VM is only as tight as the code and interfaces it puts inside the trust boundary. If the design automatically trusts firmware, guest kernel code, and host-facing transport layers, the boundary may be carrying more privileged code than the workload actually needs. That weakens the security case even when memory is encrypted, because encryption alone does not prove the right code is trusted.
That is the key design question: which components must actually be inside the trusted computing base for the workload to function, and which could be excluded or reduced without breaking the use case? The answer should be driven by the minimum necessary trust, not by the maximum available isolation.
A useful test is to draw the boundary around the workload’s real security dependencies, then challenge every added layer. If a layer exists mainly for convenience, compatibility, or default platform behavior, it deserves scrutiny. The smaller the trusted set, the easier it is to reason about compromise, attestation, update paths, and the blast radius of a defect.
How to judge whether the included components are justified
Start by listing every component inside the protected boundary, then separate essential workload functions from platform conveniences. Firmware, kernel, hypervisor-adjacent interfaces, device emulation, and host transport paths should only be included when the workload genuinely depends on them for confidentiality, integrity, or boot-time trust.
For Confidential Computing Guide, the practical issue is not whether the VM is confidential in name, but whether the trust anchor and attestation model are narrow enough to support the claim being made. If the workload can tolerate a simpler boundary, prefer the simpler boundary.
The strongest sign of overreach is when the boundary includes layers that the workload operator cannot meaningfully verify or control. In that case, the design is asking you to trust more code than the security objective requires, which increases assurance cost without necessarily improving real protection.
What changes when the trust boundary is trimmed
A narrower boundary usually improves security reasoning more than it improves performance. It reduces the amount of code that can undermine attestation, lowers the chance that an unrelated subsystem becomes part of the trust story, and makes failure analysis more precise when something inside the VM goes wrong.
For Threat Modelling Guide, the important shift is that trust boundaries become an explicit analysis tool rather than a box you inherit from the platform. Once you start naming the boundary, it becomes easier to spot when a “confidential” deployment is still depending on large, conventional trusted computing assumptions.
A tighter boundary also helps with change management. Fewer trusted components means fewer upgrade paths to validate, fewer places where a defect can silently change the trust story, and fewer dependencies that must remain stable to preserve the original assurance level.
For teams building or reviewing agentic systems, Threat Modelling AI Agents is a useful reminder that trust boundaries should track actual authority and data flow, not just platform packaging. The same logic applies here: do not accept a broader enclave simply because it is a convenient default.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | Confidential VM boundaries depend on isolating trusted code and reducing shared attack surface. |
| CM-6 — Configuration Settings | Boundary size is strongly affected by what components and defaults are enabled inside the VM trust model. | |
| SA-8 — Security and Privacy Engineering Principles | The question is fundamentally about minimizing trusted components to improve security design. | |
| Recommendation — Apply SC-39 to limit shared execution paths and shrink the trusted boundary. Enforce CM-6 to disable unnecessary trusted components and platform defaults. Use SA-8 to minimize the trusted computing base in the system design. | ||
| ISO/IEC 27001:2022 | A.8.27 — Secure system architecture and engineering principles | Confidential VM trust boundaries are an architecture design problem requiring least-trust decisions. |
| Recommendation — Apply A.8.27 to design the VM boundary around only the necessary trusted components. | ||
| CSA Cloud Controls Matrix | IVS — Isolation and Virtualization Security | Confidential VMs rely on virtualisation isolation and the scope of trusted layers within that boundary. |
| Recommendation — Use IVS to verify that virtualization trust boundaries are no wider than needed. | ||
Practitioner Guidance
What to verify: Confirm that every component inside the boundary is there because the workload requires it, not because the platform happens to expose it. If a component cannot be defended as necessary to the workload’s security objective, it should be treated as a boundary expansion candidate.
Decision rule: If the security story depends on trusting firmware, guest kernel paths, and host-facing transport layers by default, challenge whether the workload needs a confidential VM at that size or whether a smaller trust domain would give a better assurance-to-complexity ratio.
What practitioners underestimate: Encrypted memory is only one part of the control story. The real question is which code must be trusted to preserve confidentiality and integrity throughout boot, runtime, and attestation, because that is where oversized boundaries quietly erode assurance.
Practitioner takeaway: Treat boundary size as an assurance decision, not a branding decision, and keep only the minimum code inside the trust model that the workload truly needs.
Related resources from NHI Mgmt Group
- How should security teams decide whether a code-validation endpoint is too risky to leave in the main trust boundary?
- How should security teams decide whether JIT access is safe for non-human identities?
- How do zero trust teams decide whether their trust anchor is too cluster-bound?
- How can security teams tell whether their remote access model is still too dependent on perimeter trust?