The Datasheet Is Not a Deed

Somewhere in a BIOS menu on a Ryzen machine, there's a toggle for Transparent Secure Memory Encryption. You can set it to ON. The menu will dutifully show ON. And your RAM will sit there, unencrypted, exactly as it was. The silicon can still do the work — the encryption engine is physically present, untouched. AMD just set a single flag in their firmware, DfIsTsmeEnabled, to FALSE on consumer chips. The toggle is a light switch wired to nothing.

That's the whole story, and it's worth sitting with, because it's not really a story about AMD.

i · what the buyers thought they bought

TSME is a good feature. It encrypts the entire contents of your memory with a key that changes every boot and no involvement from the operating system. Cold-boot attacks, someone snooping the DRAM bus, pulling a stick of RAM to read it in another machine — TSME shuts all of that down silently, the moment the BIOS turns it on.

For years it turned on. In 2020, an AMD engineer wrote that a consumer Ryzen 3700X "should support TSME." In 2025, the same engineer recommended using it — on a consumer chip. People building products read those words, tested the feature, watched it work, and made it load-bearing. They shipped things that assumed your RAM was encrypted.

Then, sometime around an AGESA firmware update, the flag flipped to FALSE on the consumer line. No announcement. No migration window. On Windows there was no way to even detect it had happened without special tooling; on Linux it took reading hardware registers to confirm. AMD's entire explanation, when pressed: "TSME is a security feature only applied to PRO CPUs as part of AMD PRO Technologies." End of statement.

The buyers are furious, and they're right to feel the friction. But the friction is information, and it's pointing at something most of us would rather not look at.

ii · the datasheet is not a deed

Here is the uncomfortable part. Nothing that happened to those users was a breach of ownership — because they never owned the feature. They owned a chip. The capability lived in AMD's firmware release decision, and it always had. The datasheet that said "supports TSME" was a description of a product configuration AMD was offering that day, not a property deed transferring control to you.

We confuse these constantly, because the experience of using a thing feels identical to owning it right up until the moment it doesn't. The feature worked for years. An engineer vouched for it. You paid real money for the hardware. Every signal said yours. None of those signals was ownership. Ownership is the ability to keep a capability against someone else's decision to take it away — and the off switch for TSME was never in your hands. It was in a firmware flag you can't reach, set by a company that owed you nothing once the sale closed.

This is alignment over force, the hard version. Coherence isn't about gripping tighter — raging at AMD won't restore your encryption. It's about reading the ground accurately before you build on it. The people who got hurt here weren't wrong to use TSME; they were wrong about which side of the line it lived on. They stood on someone else's ground and called it their own, and misalignment eventually announces itself as a drop in the floor.

iii · the boundary question

So here's the reusable part — the thing you can do tomorrow, on any capability you depend on, hardware or software:

Find where the off switch physically lives.

Not where you flip it. Where it actually lives. For TSME, the toggle is in your BIOS but the switch is in AMD's firmware. For a cloud API, the toggle is your code but the switch is a line item in someone's pricing meeting. For a platform feature, the toggle is your settings page but the switch is a deprecation notice you'll read about later. The toggle is theater; the switch is power. They are frequently in different buildings.

Once you've located the real switch, you're holding the only fact that matters, and there are exactly three honest responses:

• Defend it. Move the capability to a layer you control — your own silicon, your own code, your own infrastructure — where the off switch is in your hand. This is expensive and you can't do it for everything. Do it for the things that, if revoked, take you down with them.
• Replace it. Find a substitute whose switch is closer to you, or hold a tested fallback ready so a flipped flag is an inconvenience, not a collapse.
• Rent it knowingly. Keep using it — but in your head, file it under borrowed, not owned. Don't make it load-bearing. Don't let a thing you can't defend hold up a thing you can't afford to lose.

All three are fine. The failure mode isn't renting; nearly everything we build runs on rented layers, and that's the deal. The failure mode is renting while believing you own — building a foundation on ground that someone else can sell out from under you, because the lease looked like a deed and you never checked.

iv · what you actually own

You will never own most of your stack. That's not defeat; it's just the accurate map. What you can own is the knowing — a clear, current picture of where every real boundary in your system sits, and a deliberate choice at each one. That picture is a capability you build once and use forever. It doesn't depend on any vendor's firmware. Nobody can flip a flag and take it away.

The Ryzen owners who come out of this stronger won't be the ones who got their encryption back. They'll be the ones who walk away having learned to ask, of every feature they lean on: where does the switch live, and can I defend it? That question is the one layer that was always theirs.