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

What Changes When You Move a Workload Into a Confidential VM?

confidential computing changes the host trust boundary, but not automatically the application’s own trust model. A lift-and-shift migration can still carry forward insecure boot assumptions, weak OS hardening, noisy side channels, oversized privileges, and brittle secret-handling patterns. The security gain comes from rethinking what must be trusted, not from moving the same stack into a protected wrapper.

That is why the migration question is governance-heavy as much as it is technical. If the team only checks whether the VM is encrypted in use, they may miss the more important issue: whether the guest image, runtime, and operational controls were ever designed to behave as if the infrastructure operator is no longer fully trusted.

For a practical starting point, Confidential Computing Guide is the right internal reference because it frames TEEs, confidential VMs, attestation, and key release as one trust-and-control system rather than a branding exercise.

Teams also underestimate how much the surrounding data protection model matters. If sensitive material still lands in memory, logs, temp files, or application-level caches in plaintext form, the migration may improve isolation from the cloud operator while leaving exposure paths intact. The right comparison is not "classic VM versus confidential VM", it is "what assumptions about memory, image integrity, and secret exposure are still being relied on after migration".

Encryption Guide fits here because confidential computing is usually part of a broader in-use protection strategy, not a substitute for disciplined encryption, custody, and key release choices.

Why Lift-and-Shift Weakens the Security Objective

The main mistake is treating the migration as infrastructure substitution instead of trust-model redesign. A workload that was acceptable in a traditional VM may depend on kernel modules, boot-time trust, admin access, or internal network assumptions that are no longer appropriate once the goal is to reduce trust in the platform operator.

The result is a false sense of security. The environment may technically support confidential execution, but the application can still be exposed through image provenance gaps, unnecessary host dependencies, overbroad credentials, or operational shortcuts that assume the VM boundary is sufficient by itself.

Privacy-Enhancing Technologies Guide is relevant because confidential computing sits in the same class of protection choices as other privacy-preserving controls, where the control’s value depends on how completely the system is re-architected around it.

The governance failure is usually not malicious. It is organizational drift, where platform teams advertise a stronger substrate while application owners keep the same deployment model, the same secrets flow, and the same operational trust assumptions. In that state, the confidential VM becomes a more protected shell around an unchanged risk profile.

What Good Migration Governance Looks Like

A better migration program starts by classifying which assumptions must change before the workload is considered truly migrated. That means deciding whether the application can tolerate immutable images, whether attestation gates key release, whether the runtime can be hardened, and whether the operational team can support a more constrained trust boundary.

At minimum, teams should verify that the workload owner can explain three things: what the platform is now trusted to do, what it is no longer trusted to do, and what evidence proves the workload is actually using the confidential path. If those answers are vague, the project is probably a packaging exercise rather than a security improvement.

Decision rule: If the workload only becomes "confidential" after you move it, but its dependencies, access paths, and secret handling remain unchanged, treat the migration as incomplete. If the trust model changes, the operational controls must change with it.

What to verify: Confirm image provenance, boot-chain assumptions, runtime hardening, attestation enforcement, and secret-release policy before calling the migration successful. Also check whether the application still relies on broad admin access or manual exception paths that undermine the protection model.

What practitioners underestimate: Confidential computing reduces exposure to the infrastructure operator, but it does not automatically compensate for weak application design, weak privilege boundaries, or poor operational discipline.

Risk and Threat Considerations

The risk is not only that the migration disappoints, it is that teams may believe they have materially reduced trust assumptions when they have simply renamed the hosting model. That creates a dangerous gap between perceived and actual protection, especially where sensitive data, regulated workloads, or high-value credentials are involved.

Failure mechanism: A lift-and-shift migration preserves old firmware, kernel, runtime, or secret-management assumptions inside the confidential VM, so the workload keeps depending on controls that the new platform was meant to reduce or replace.

Impact: The environment may inherit the overhead of confidential computing without achieving its intended security benefit, and in some cases it can create a harder-to-audit false assurance problem because the deployment now looks more protected than it really is.

Practitioner Guidance

What to prioritise: Treat trust-boundary redesign as the migration deliverable, not just workload relocation. The first question is whether the workload can actually operate under attestation-aware key release and tighter runtime assumptions.

What to verify: Validate that the migration path removes, rather than preserves, the old trust dependencies. If the application still needs broad host-level trust, manual secret injection, or uncontrolled guest images, the confidential VM is not delivering the intended governance outcome.

Common mistake: Teams often sign off on the platform feature while leaving the application and operations model untouched. That is the easiest way to get a successful cutover and an unsuccessful security change.

Practitioner takeaway: A confidential VM is only a security improvement when the migration changes the trust model, not merely the hosting environment.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams use IAST and RASP in NHI governance?
• What is the main governance mistake organisations make when regulations move dates?
• What are the main governance mistakes teams make when expanding IAM to machine and AI access?