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.
Why compatibility and trusted-base minimization are always in tension
The practical trade-off is between keeping the environment small enough to inspect and verify, and keeping enough compatibility to run the workload unchanged. A larger guest stack often preserves convenience, but it also expands the code, configuration, and privilege surface that must be trusted. In confidential computing, that expansion can weaken the very assurance the technology is meant to provide.
When the workload can run with a thinner guest layer, the smaller trusted base is usually the better security choice. That does not mean compatibility is unimportant, only that compatibility should be treated as a cost that must earn its way through a real operational need.
For teams trying to compare options, this is the same basic judgment that appears in hardening work: the less code and fewer dependencies that sit inside the trust boundary, the easier it is to reason about integrity, patching, and compromise impact. A compact design is easier to audit because there are fewer places where hidden behavior can live.
What preserving compatibility usually buys, and what it gives up
Compatibility typically buys faster migration, fewer application changes, and lower short-term friction for platform owners and developers. That can matter when the workload is legacy, tightly coupled to a guest OS feature, or difficult to recertify under time pressure. In those cases, compatibility is not a mistake; it is a deliberate operational choice.
The cost is that compatibility often brings back layers you were trying to eliminate, such as extra drivers, services, tools, or management components. Each layer increases the amount of software that must be trusted to stay correct, and each extra dependency creates another path for misconfiguration, vulnerability, or operational drift. The more the design looks like a traditional full-stack guest, the less compelling the confidentiality argument becomes.
A useful way to think about the decision is whether the compatibility layer is only a deployment convenience or whether it is functionally required for the business outcome. If it is only convenience, the stronger default is to remove it. If it is required to preserve the workload itself, then the team should document why the larger trusted base is acceptable and what compensating controls exist.
How to choose the smaller trusted base without breaking the workload
The decision should start with the minimum viable guest surface needed for the application to function correctly. That means identifying which components are truly required, which are inherited from older platform assumptions, and which exist only because they were easy to carry forward.
In practice, the best test is not “can we keep it working?” but “can we keep it working with less trusted code and still meet the operational requirement?” If the answer is yes, the smaller design should win. If the answer is no, the larger compatibility set needs a clear justification, not just a preference for convenience.
Practitioners should also treat verification cost as part of the design decision. A compatibility-heavy environment may be technically functional, but if the team cannot confidently inspect, monitor, and attest to what is inside the protected boundary, the design is too broad for the security goal it is supposed to support.
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 NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Trusted-base minimization depends on reducing in-boundary components to a known baseline. |
| CM-6 — Configuration Settings | Compatibility choices affect how tightly the guest stack can be hardened and controlled. | |
| SI-2 — Flaw Remediation | A larger trusted base increases the patching and verification burden for inherited software. | |
| Recommendation — Define a minimal approved baseline and remove unnecessary guest components from the trusted surface. Harden the compatible stack with enforced settings and prohibit ad hoc additions inside the boundary. Track and remediate flaws in every component that remains inside the trusted boundary. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Compatibility versus minimal trust is fundamentally a configuration-bounding decision. |
| Recommendation — Control configuration scope so only necessary components remain in the trusted environment. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration management | Minimizing the trusted base is a protective configuration practice that reduces exposure. |
| Recommendation — Set and maintain secure configuration baselines that exclude unnecessary guest-layer functionality. | ||
Practitioner Guidance
What to prioritise: Prioritise shrinking the trusted base first, then add compatibility back only when it is necessary to preserve a workload that cannot be practically reworked. The deciding question is whether the added guest stack changes the assurance story in a meaningful way, not whether it is the easiest path to deployment.
What to verify: Verify which guest components are actually inside the trust boundary, which ones are optional, and whether any compatibility layer introduces code or services that the team cannot realistically audit or patch with confidence. If the answer is “yes, but we are not planning to inspect it,” the design is too permissive.
Common mistake: Treating compatibility as neutral. It is not neutral when it adds code, complexity, and failure modes inside the protected surface. The safer pattern is to make compatibility an explicit exception with a documented business reason, not the default architecture.
Practitioner takeaway: The right balance is usually asymmetric: preserve compatibility only when it materially protects the workload outcome, but default to the smallest trusted base that still delivers that outcome with a verifiable security boundary.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?