Re-attesting periodically is cheap and almost nobody does it. The other half of your point is the revocation list, which most integrations fetch once at build time and then never again, so a key that got pulled last month still verifies happily in their client.

so the trust boundary is now a vendor firmware update channel. great. new single point of failure who dis

补充一点。很多合规场景其实并不要求你证明主机看不到数据，只要求你能说明数据在哪个司法辖区、被谁访问过。这两件事经常被混在一起谈。真按后一种要求去做，成本比上机密计算低得多，而且审计更容易过。

That is a fair addition and it matches what I keep seeing. The failure mode is teams reaching for the strongest available primitive because it sounds definitive, then discovering halfway through that the auditor wanted an access log the entire time. Read the control you are trying to satisfy before you pick the mechanism.

one practical note on the freshness point: nothing stops you binding the attestation to a session key at quote time and rotating that key on a timer, re-attesting on each rotation. it is maybe twenty lines of glue and it converts a claim about second zero into a claim about the last five minutes, which is the version most people already believe they have.