Advisories and TCB recovery

TEEs have vulnerabilities too

CPU vendors and GPU vendors publish security advisories affecting their TEEs, and fix them with microcode, firmware or software updates. After a fix, the platform's TCB version (the security version numbers in the attestation report) increases. Verifiers can then reject evidence from platforms that have not applied the fix. This process is generally called TCB recovery.

1. Triage: read the vendor advisory (AMD, Intel, Arm, NVIDIA) and your cloud provider's bulletin. Does it affect your TEE type and your threat model?
2. Assess exposure: which workloads and keys rely on the affected platforms? What data could have been exposed, and to whom?
3. Remediate: in the cloud, the provider usually rolls out fixed firmware; you may need to restart or migrate instances. For your own images, rebuild with patched components.
4. Raise the minimum TCB in your verifier or release policy once fixed platforms are available, so unpatched platforms can no longer get keys.
5. Rotate: if the vulnerability could have exposed keys, rotate them and re-encrypt data as needed.
6. Record: document decisions, timelines and evidence.

# Example verifier rule (pseudocode, AMD SEV-SNP)
REJECT IF report.reported_tcb < MIN_TCB[product]
# MIN_TCB is updated by the officer after an advisory and provider rollout

Advisory sources: AMD product security, Intel security center, NVIDIA product security.