TEE TCB Updates and Patch Management in Production

TEE TCB updates in production are not a matter of pushing a patch and moving on. Understanding that lifecycle, from Intel's TCB Recovery process through the moment attestation re-establishes trust, separates a confidential computing deployment that is actually secure from one that merely looks the part on an architecture diagram.

TCB patching in confidential computing versus ordinary patch management

Ordinary patch management treats a late update as an internal problem. The moment a platform generates an attestation quote, its patch status becomes a publicly checkable fact that a relying party can inspect and act on, which makes patch status part of the trust contract itself rather than an internal housekeeping matter. A gap between what is running and what Intel has published is measured, quantified, and visible to the party deciding whether to trust the machine.

Why does this force operators toward mandatory enforcement rather than a recommended-update model? Intel's own TCB Recovery documentation answers the question directly: an update mechanism alone is not sufficient, because if applying it is voluntary, a remote service may end up communicating with a client that still carries known vulnerabilities. Patching is now about maintaining a provable claim that a relying party is actively checking: SGX and TDX operators are maintaining the integrity of an ongoing cryptographic statement about those machines.

Intel's TCB Recovery process, from vulnerability to attestation collateral

The process that turns a discovered flaw into a checkable attestation claim is called TCB Recovery, or TCB-R, and it runs through three stages that can overlap rather than proceed in strict sequence: vulnerability handling, deployment and disclosure, and the publication of attestation collateral.

Engineering teams then design a mitigation specific to each affected component, since a fix for microcode does not look like a fix for BIOS or platform software. Each component produces its own updated ingredient, whether that is a BIOS revision, a microcode blob, a firmware image, or a software patch, and all of these ingredients pass through integration and validation before anything ships.

Deployment and disclosure follow a sequence built around giving customers a head start. Ingredients go out to customers for preview and deployment before the vulnerability is disclosed publicly, and the public microcode security release lands afterward on Intel's GitHub. For SGX and TDX specifically, the mitigation shows up inside the Best Known Configuration kit on Intel's Resource and Document Center, and the exact RDC numbers an operator needs appear in the corresponding Intel Platform Update collection guidance. Which path an update takes from there depends on what kind of vulnerability is being fixed. Some mitigations require a BIOS update carrying new microcode that can only be loaded by flashing the firmware for it to register in attestation, a pathway Intel labels MCU_BIOS_TCBR, while others can simply be loaded by the operating system at runtime. When the fix involves the TDX Module specifically, operators face a further fork: either obtain an updated Integrated Firmware Image from the OEM or ODM, or place the required TDX Module binary directly into the EFI System Partition so the existing IFWI can load it.

The final stage is the one that makes all of the preceding engineering work externally legible. After public disclosure, Intel publishes signed attestation collateral reflecting the new TCB level, and the date of that publication is what the industry calls the TCB-R event. From that date forward, any verifier querying Intel's provisioning infrastructure can tell the difference between a platform that has applied the update and one that has not. That distinction is the hinge the rest of this piece turns on: everything downstream, every operational headache described in the sections that follow, exists because that distinction becomes checkable on a specific calendar date.

What attestation status codes tell a relying party (and what they withhold)

Once the TCB-R event has occurred, the question for any relying party becomes mechanical: what does this platform's attestation actually report? Intel defines a fixed set of possible responses, and the enforcement logic built on top of them is what gives TCB Recovery its teeth. Only one response, UpToDate, confirms that the latest mitigation has been applied. Every other response signals some kind of gap, and what the relying party does with that signal is entirely up to the relying party.

The full vocabulary Intel defines runs as follows. Revoked means the platform has been cut off entirely.

What those codes leave unsaid is as important as what they report. A relying party enforcing strict UpToDate policies denies service the instant a platform falls behind the current TCB level, a consequence already built into the attestation contract at the time the relying party configured its policy, not a decision made in the moment of the check. Attestation verification itself can carry its own errata and edge cases, so even a clean-looking status code is only as reliable as the verification logic reading it, a complication that resurfaces later as a concrete production checklist item rather than an abstract warning.

Intel is explicit about where enforcement authority actually sits. The TCB-R documentation states that Intel does not typically revoke platforms running unmitigated software and firmware. Instead, Intel publishes the certificates and collateral, and relying parties evaluate the TCB level themselves and decide what to trust. That delegation is the structural fact that makes everything in the rest of this piece an operator's problem rather than Intel's problem: the vendor built the measurement system, but the enforcement policy, including how harsh or how forgiving it is, belongs to whoever is checking.

The SGX enclave teardown requirement

A common assumption trips up operators who are new to SGX: if the microcode patch has been applied to the machine, surely the attestation reflects that. It does not, and the mechanism behind that gap is worth isolating precisely. SGX remote attestation reflects the TCB level that existed at the moment a given enclave was created. Loading microcode through OS Patch Loading while enclaves are already running makes the platform more robust in a general security sense, but it does nothing to the attestation a currently running enclave produces.

Closing that gap requires a specific, disruptive sequence. The operator must tear down every running enclave, empty the Enclave Page Cache entirely, and execute the ENCLS[EUPDATESVN] instruction before any newly created enclave will attest to the new, patched TCB level. That is not a rolling update that can happen quietly in the background while traffic continues to flow, but a coordinated workload interruption, so any SGX service that runs continuously must plan for a maintenance window at each TCB-R event.

Skipping that sequence produces a particularly deceptive failure mode. Enclaves that are not torn down keep producing quotes at the old TCB level regardless, so attestation status never improves. From inside the operator's own infrastructure, everything looks patched. From the perspective of a strict verifier checking the attestation quote, the platform still reads as OutOfDate, and depending on the relying party's policy, that can mean denied service for a workload the operator believes is already fixed.

TDX module and platform-dependent update paths

TDX inherits the same fundamental tension as SGX, with an added constraint that can make the fix harder to apply quickly. They require a full platform reset before attestation reflects the change.

The TDX Module compounds the dependency chain further, because it is a distinct update artifact from the BIOS and microcode. Each route carries its own OEM dependency and its own timeline, and neither is instantaneous.

IPU 2026.1 shows what that timeline looks like in practice. Intel delivered an updated TDX Module addressing CVE-2025-32467 and CVE-2025-27940 to customers as part of IPU 2026.1 or other sustaining releases between September and December 2025, well ahead of the planned public disclosure on February 10, 2026, after which the formal TCB Recovery process began. An operator cannot apply an IFWI update any faster than the OEM can produce and certify it. Part of the distance between Intel's disclosure date and an operator's own UpToDate attestation sits entirely outside the operator's control.

Google Cloud's experience in mid-2025 shows what happens when that distance collapses into an outright gap rather than a delay. As of June 20, 2025, Confidential VM instances running AMD SEV-SNP or Intel TDX on Google Cloud did not support remote attestation at all when running certain guest OS images. That AMD appears in the same incident as Intel is itself instructive: the operational friction described throughout this piece is not a quirk of Intel's architecture. The same underlying tension between patch velocity and attestation continuity appears on the other major confidential computing platform as well, through a different mechanism.

How AMD SEV-SNP TCB updates differ

AMD SEV-SNP tracks platform patch level through a Security Version Number embedded in the TCB_VERSION structure, and that SVN increments with every firmware release that adds a security mitigation, functioning as a signal to anyone checking that an update matters. The mechanics differ from Intel's enclave-level SVN tracking, but the underlying principle, a number that moves when security posture changes, is the same.

A recent AMD mitigation shows a failure mode distinct from anything on the Intel side: a patch that silently removes a capability rather than merely disrupting continuity. Linux hosts applying this patch stop advertising SEV-ES VM support entirely, which breaks any workload built on the assumption that both protections could run side by side. That is a materially different category of consequence than a maintenance window. Operators do not lose time, they lose a capability the platform used to offer.

A second AMD issue adds a hardware dimension to the picture. CVE-2025-29943, nicknamed StackWarp, is a flaw that lets a privileged adversary, such as a malicious hypervisor or a compromised cloud provider, deterministically interfere with confidential VMs. Mitigation ships as hot-loadable microcode, with release dates spanning July 2025 through April 2026 depending on the product line, and the affected silicon includes EPYC 7003 Milan, EPYC 8004 Siena, EPYC 9004 Genoa and Bergamo, and EPYC 9005 Turin. The breadth of that silicon list underscores how a single flaw can ripple across years of hardware generations still in active production use.

Even mitigations that do apply cleanly are not free of cost. Google released a security fix on February 18, 2025 for Confidential VM instances running AMD SEV-SNP on N2D machine types that could degrade performance in ways that vary by workload, and starting in August 2026, Confidential VM instances on AMD SEV-SNP may see longer boot times and other performance changes tied to a guest kernel migration bundled with security updates. Taken together, these AMD examples point to a single unifying fact: an SVN increment is never a neutral bookkeeping entry. It can change what a platform is legally permitted to host, and an operator who has not actually read the changelog behind that increment may only discover the change once a workload refuses to start.

The TCB-R cadence has accelerated, and the grace period is becoming load-bearing infrastructure

The tempo of TCB-R events gives a concrete sense of how often operators now have to go through the cycle described above. Intel's public disclosure dates list TCB-R-19 on May 13, 2025, TCB-R-20 on August 12, 2025, TCB-R-21 on February 10, 2026, and TCB-R-22 on August 11, 2026, four events packed into just over a year, arriving roughly every three to six months.

That cadence narrows the window during which older collateral remains valid. Any operator who has not advanced past that counter by then is cut off from attestation entirely. Intel built a grace period into the system specifically to absorb this pressure: selecting update=Standard grants a full twelve-month mitigation grace period, as laid out in Intel's November 2024 TCB Recovery documentation, giving infrastructure providers time to update before their platforms are formally marked out of date.

One might argue that a twelve-month cushion is generous given a disclosure cadence measured in months rather than years. That decision belongs to whoever is doing the relying.

That dependency is why the twelve-month grace period has quietly become something closer to permanent infrastructure than a temporary bridge. Large, heterogeneous cloud fleets routinely cannot patch every machine before a TCB-R event lands, so instead of an occasional exception, the grace period has become the default operating condition for keeping those fleets attestable at all. Any fleet leaning on it as a matter of course is one tightened relying-party policy away from finding out how much of its uptime was actually running on borrowed trust, a concern that extends to any AI assistant, including privacy-preserving ones like Confidant AI, whose attestation integrity depends on the same underlying TCB guarantees.