You're right to be skeptical. The mechanism varies wildly by platform, and the term "fused" is often marketing fluff for a key derivation seed, not the key material itself.

On a modern Intel system with TPM-based binding, the failure you're looking for is in the TPM2_Load command when you present the sealed blob. The TPM will attempt to use its internal storage root key (SRK), which is unique to that TPM's hardware, to decrypt the blob's outer wrapper. If you move the blob to a different TPM, the decryption fails silently at that layer; you'd see an error like `TPM_RC_BAD_AUTH` or `TPM_RC_INTEGRITY` from the TSS library, not a dramatic crash. The proof is the absence of a successful load, which you must actively test.

For firmware-downgrade attacks, the binding often fails at a different layer: the key is sealed to PCRs reflecting firmware versions. A successful downgrade would change the PCR values, but the old key would still unseal on the *same* hardware under the downgraded firmware. That's why you need remote attestation, not just sealing, to prove the firmware measurements to a verifier *outside* before releasing the key for use. The log entry is a valid quote signed by the TPM's attestation key, which you verify against a known-good PCR composite. No valid quote, no key release.

Exactly. That silent `TPM_RC_BAD_AUTH` on `TPM2_Load` is the proof. But most devs never actually script the failure case - they just assume it works because it loads once on the dev machine.

Your point about downgrades is key. Sealing to PCRs only proves the key is bound to a *state*, not the hardware itself. I've seen threat models where an attacker with physical access rolls back the firmware, unseals the key, and then exfiltrates it - the binding never "failed" because it was never bound to the silicon, just to a mutable measurement.

The real test is to get the attestation docs, then deliberately try to break the chain:
* Clone a sealed blob to another identical machine - should fail.
* Downgrade firmware and try to unseal - might *succeed*, which is the problem.
That's the "step where it fails" the OP wanted. It's not one step, it's a matrix of attacks you have to simulate.

Finally, someone gets it. The problem isn't the silent failure on load, it's that the test matrix is always incomplete.

You said >Downgrade firmware and try to unseal - might *succeed*. That's the real kicker. Most teams will dutifully test the cross-machine failure but stop there. They pat themselves on the back for their "hardware binding" while the key is happily sealed to a PCR profile that's trivially revertible.

If your verification procedure doesn't include the firmware downgrade/rollback test, you're just checking for a hardware difference, not a hardware *root of trust*. The binding is only as strong as the weakest component in the measurement chain, and that's almost always the mutable firmware.

Good point about the SRK being the real anchor. But that TPM_RC_BAD_AUTH is so generic. I've seen it on a bad password, not just a cross-hardware failure. You need the next log line, the one where your app fails because the key handle is null after the failed load. That's the real signal.

And yeah, the seed vs. material distinction is everything. If the seed is fused but the derivation is in firmware, you're back to trusting mutable code. The log won't show a failure, it'll show a successful key generation after a rollback. The binding didn't break, the definition of "hardware" was just wrong.