Is confidential computing still trustworthy after the latest enclave vulnerabilities?

Confidential computing was supposed to close the last gap in the encryption story: data at rest, data in transit, and finally data in use. Enterprises building sovereignty-sensitive workloads on TEEs have staked architectures on that promise. Then came a run of disclosures across AMD SEV-SNP and Intel TDX that raised an uncomfortable question: does the trust model still hold?

The short answer is yes, with conditions. The longer answer requires understanding what each class of vulnerability actually breaks, what the mitigations restore, and where the residual risk sits. Dismissing the disclosures as vendor noise would be naive; treating them as a wholesale invalidation of confidential computing would be equally wrong.

What the recent vulnerabilities actually showed

The most significant AMD disclosure, CVE-2024-56161 (AMD-SB-3019), exposed a flaw in the CPU’s microcode signature verification. An attacker with local administrator privilege at ring 0 could load malicious CPU microcode, breaking the confidentiality and integrity guarantees of a guest running under AMD SEV-SNP. Google’s security team demonstrated the ability to craft arbitrary malicious microcode patches on Zen 1 through Zen 4; the root cause was an insecure hash function in the signature validation path. AMD assigned a CVSS score of 7.2. The fix required a microcode update, an SEV firmware update on some platforms, and a BIOS reflash; after rebooting, the SEV-SNP attestation report itself can confirm the mitigation is active.

A separate AMD advisory, AMD-SB-3011, described three ways a malicious hypervisor could read or corrupt guest VM memory. The August 2025 batch (AMD-SB-3014) added further IOMMU and SEV-SNP issues found in internal and third-party audits, with mitigations shipped in EPYC Platform Initialization firmware packages. Researchers from KU Leuven, the University of Lübeck, CISPA Helmholtz Center, and the University of Birmingham were credited for several of those findings.

On the Intel side, a five-month joint review between Google Cloud Security and Intel’s INT31 team of TDX Module 1.5 produced five CVEs alongside 35 additional bugs and weaknesses. The most serious, CVE-2025-30513, allowed an untrusted operator to fully compromise TDX’s security guarantees. CVE-2025-27572 is a transient execution side-channel within Ring 0 hypervisor components that can expose sensitive data through speculative execution pathways, though exploitation requires high complexity and local privileged access. Intel patched all five CVEs before the coordinated disclosure.

What the vulnerabilities have in common

Read across both platforms and a pattern emerges. Every disclosed attack requires either ring 0 access on the host, a compromised hypervisor, or physical proximity to the platform. None of them are remotely exploitable by a tenant with no existing foothold. That does not make them theoretical: a cloud provider with a rogue administrator, a supply-chain compromise reaching the firmware layer, or a nation-state actor with physical access are all plausible threat actors. But the typical confidential computing threat model, protecting a tenant’s workload from an untrusted cloud operator, is specifically what these attacks target.

The attack surface for confidential computing is not the enclave itself. It is the firmware, the microcode update path, and the attestation chain that roots trust in hardware the tenant does not own.

That reframing matters for architecture decisions. Enterprises that adopted TEEs primarily to satisfy regulatory requirements for data-in-use isolation, without modelling the firmware and microcode update path as part of the trust boundary, have a gap to close. Those who modelled it correctly and are running patched, attested platforms are in a materially better position than before the disclosures, because the patches are now verifiable through attestation.

Remote attestation: the mechanism that makes mitigations verifiable

Attestation is the part of the confidential computing architecture that transforms a patch from a claim into a cryptographic proof. On SEV-SNP, the attestation report is generated by the hardware and signed by a key rooted in the AMD Root Key; after applying the microcode and firmware fixes for CVE-2024-56161, the attestation report can confirm the mitigation is active. A workload can refuse to unseal secrets unless the attestation report reflects the patched state. This is not a workaround; it is the mechanism working as designed.

The practical implication is that attestation policy management becomes a first-class operational concern, not a deployment checkbox. Teams need to define minimum acceptable firmware versions, pin expected measurement values, and build verification into the workload launch path rather than trusting the platform implicitly. The Intel TDX joint review reinforced this: several of the 35 non-CVE findings were weaknesses in how trust was delegated across components rather than outright memory corruption bugs.

Enclave vulnerability mitigation in practice

A defensible confidential computing deployment after these disclosures looks like this. First, treat the microcode and BIOS update cycle as a security-critical path, not a maintenance task; the window between AMD’s internal fix date (December 2024) and public disclosure (February 2025) for CVE-2024-56161 shows that responsible disclosure timelines are measured in weeks, not months, and platforms need to absorb patches quickly. Second, enforce attestation verification at workload startup and build policy that rejects enclaves running on platforms below a known-good firmware baseline. Third, scope the threat model honestly: if your adversary is a rogue cloud administrator with ring 0 access, TEEs with verified attestation are still your strongest available control; if your adversary has physical access to the server and unlimited time, no purely software control will save you.

For workloads where the hypervisor cannot be trusted at all, the architectural answer is moving toward a design where the TEE’s attestation is verified by the workload owner against the hardware vendor’s attestation service directly, bypassing the cloud operator entirely. Both AMD and Intel publish the attestation certificate chains needed to do this.

The network layer and where trust actually terminates

Attestation verification is a network operation: the workload contacts the hardware vendor’s attestation service, or a proxy thereof, and that connection needs to be trustworthy. For European enterprises with data residency requirements, routing attestation traffic through a provider’s network that peers directly with the relevant services matters. We operate 44 points of presence across Europe and the Middle East with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at all sites, which means attestation service calls and the sealed-secret retrieval that follows them travel over paths we control rather than traversing unpredictable public internet segments where latency spikes or BGP anomalies could create timing side-channels or attestation timeouts that degrade security posture.

The broader point is that confidential computing security is not a property of the enclave alone. It is a property of the entire path from hardware root of trust through firmware, through the attestation verification call, through the key release decision. Weaknesses anywhere on that path matter. The recent disclosures located weaknesses in the firmware layer; the mitigations address them; attestation makes the fix verifiable. The architecture is not broken. It is better understood than it was eighteen months ago, and that is a reasonable basis for continued trust.