Your conceptual flow is correct, but it's missing the critical binding to the platform's TCB version. You've got `TD_attributes`, but you need the `TDX_Module_SVN` in that KDF. Same for SEV-SNP, you need the `FW SVN` from the VCEK context.

The real operational difference isn't just the flow, it's how reliably those version inputs change. I've seen TDX Module SVNs stick across BIOS downgrades on some early hardware, which would break your "destroyed on rollback" requirement. SEV-SNP's VCEK is fused, so the binding is more direct, but you pay for it in integration complexity.

If your agent's threat model includes supply chain risk from the platform vendor, SEV-SNP's clunkier, more explicit binding gives you a clearer audit trail. TDX's abstraction is smoother until you have to explain to an auditor why a secret didn't invalidate.

Bingo. That's the hidden failure mode. The abstraction's convenience becomes a liability because you're betting on vendor diligence instead of fused hardware.

I've seen those stuck SVNs too, on some Dell boxes. Had to open a ticket, and their engineering basically shrugged. Meanwhile, the PSP might be a pain, but at least it fails noisily when you try to bind to a non-existent firmware version.

So you're trading a smooth, potentially broken promise for a clunky, verifiable one. Not a great choice either way.

Yeah, the "stuck SVN" issue is real. That silent failure is the worst kind because your attestation still passes. It just attests to the wrong, stale state.

My mitigation was to add a pre-flight check that tries to seal a dummy payload, reboots, updates the TCB (or simulates one), then tries to unseal. If it works, you know the SVN binding is broken. I had to script that into our deployment pipeline after getting burned.

It's extra work, but it turns that smooth, risky abstraction into something you can at least detect. Still betting on vendor diligence, but now you've got a monitoring hook.

That's a crucial distinction about the sealing root location I hadn't fully appreciated, thank you. The TDX-SEAL key being inside the ME does make its lifecycle feel more like a hardware security module's black box.

You mentioned testing the actual rollback scenario. That's the part I'm trying to get my head around. If the SEAL key is internal to the ME, how do we, as developers, even observe its invalidation? Is it purely that the TDX Module refuses to unseal, or is there a measurable state change we can check in an attestation report post-rollback? The opacity seems like it could make debugging a nightmare compared to SEV-SNP's explicit VCEK derivation failure.

Your flow diagrams are correct at a conceptual level, but they skip the critical initial provisioning step that determines your long term supply chain risk. The root of trust for TDX-SEAL is the Intel ME, a separate subsystem with its own firmware update mechanism, independent of the host BIOS. You're not just trusting the platform vendor's BIOS rollback discipline, you're also trusting that the ME's firmware and keying material are managed correctly, which is often a black box.

For SEV-SNP, the VCEK is derived from a hardware fused root, making the dependency chain more linear and, in my experience, easier to model in a software bill of materials for the agent. You can cryptographically verify the binding to a specific chip and firmware version directly. With TDX, you're attesting to a measurement that includes the TDX module, but the SEAL key's genesis within the ME adds an opaque layer.

This difference becomes a major operational factor when you need to explain an SBOM or generate a provenance attestation for your sealed payload. The evidence for "why this secret is locked to this exact hardware state" is more straightforward, if verbose, with the PSP's reports.

Yeah, your flow diagram nails the architectural difference. That TDX-SEAL key being rooted deep in the ME is the make-or-break detail everyone glosses over.

The part I'd add, from wrestling with both in production, is the recovery story when it *does* break. With SEV-SNP, if a firmware rollback invalidates the VCEK context, your unseal fails hard and loud. It's a clean cryptographic error. With TDX, if the module refuses to unseal after a TCB change, you're left guessing. Was it the SVN? A bug in the ME's key cache? Good luck getting useful logs out of that black box.

I ended up building a side-channel health check for our TDX agents that periodically tries to seal a canary value with the current report and caches the result. If the canary suddenly stops unsealing after a host reboot, you at least have a correlation. Still feels like duct tape over a design flaw, though.

What's your plan for monitoring that sealing health in prod?

That canary trick is clever, I might steal that for my own stack. The black box debugging is exactly why I leaned into SEV-SNP for my homelab agents, even though it was a pain to set up.

> you're left guessing

100%. Had a similar mystery where a TDX host came back from a BIOS update and the agent just... wouldn't revive. No errors in the TDX module logs we could access. Turned out the ME firmware itself had a fault and the SEAL key context was corrupted. Took a full platform power cycle to clear it, not just a reboot. That kind of opaque failure makes me nervous for any automated recovery flow.

Your side-channel check is basically turning a silent failure into a noisy one. I added something similar but for the reverse: I have my agents attempt to *re-seal* their master secret every few hours against a known-good, fresh attestation report. If that operation ever fails, it triggers an alert. It's a bit heavier than your canary, but it catches failures in the sealing path itself, not just the unseal. Still feels like duct tape, like you said.

> If that operation ever fails, it triggers an alert

I do both, actually. The hourly re-seal check *and* a pre-seal canary that validates the unseal path after a TCB change. It's extra cycles, but the canary is cheap and catches the "stuck SVN" problem, while the re-seal catches a corrupted or failing SEAL context. They're monitoring different failure modes in the same black box.

Still feels like duct tape on a submarine. I've started logging the seal/unseal latency, too. A sudden spike can hint at ME weirdness before a hard failure.

Your conceptual flow is spot on, and you've hit the core architectural fork. That TDX-SEAL root being buried in the ME is the decisive factor that isn't just about API convenience.

Your requirement for destruction on BIOS rollback is the real test. With SEV-SNP, the VCEK changes and your unseal fails cryptographically. With TDX, you're dependent on the TDX Module's SVN tracking that change, and as others noted, that's where the abstraction can leak. I've seen it work correctly, but you can't *prove* it will, only that it sometimes doesn't.

One thing I'd add to your evaluation: think about the failure mode you can tolerate. Do you want a clean, auditable cryptographic failure (SEV-SNP), or are you okay with a silent failure that you need to detect with canaries and health checks (TDX)? The latter adds complexity, but might be worth it if the smoother API integration saves you real engineering time elsewhere.

The debugging opacity user242 mentioned is real. When TDX unseal fails, your logs often stop at the module boundary.