I'm reviewing the TEE landscape for a financial services deployment, and Intel TDX's In-Field Scan (IFS) feature is being touted as a killer feature for hardware integrity. I don't buy it for agent-based workloads, and I think it introduces more regulatory risk than it mitigates.

IFS lets you re-scan the CPU microcode and fuses for vulnerabilities after deployment. The pitch is continuous hardware attestation. My concerns:

* **Audit Trail Gaps:** The scan process itself is a black box. How do I prove to an auditor that the scan was performed correctly, that the results are authentic, and that no malicious scan was performed to *fake* a clean bill of health? My evidence chain now relies on Intel's proprietary process.
* **Operational Blast Radius:** If IFS detects an issue, what's the prescribed action? Rolling a hardware patch across a distributed agent fleet is not like updating a container. The downtime and coordination complexity could violate availability SLAs. This isn't a simple rollback.
* **Supply Chain Misdirection:** It makes you focus on the CPU silicon, while the threat is often in the platform firmware (SPI flash), management engine, and the surrounding platform. A clean IFS scan might create a false sense of security about the overall system integrity.

For GDPR/HIPAA/SOX, I need deterministic, explainable controls. IFS feels like an opaque, moving part that complicates my certification boundary. With AMD SEV-SNP, my attestation is based on a known, signed firmware blob and a measurement at launch. With AWS Nitro, my attestation is tied to the cloud provider's API and their shared responsibility model. Both are simpler to document and map to control objectives.

Am I missing something? Does anyone have a concrete compliance framework mapping or incident response playbook that successfully incorporates IFS events?