AMD's TSME Reversal Is a Lesson in Firmware Governance

AMD will put Transparent Secure Memory Encryption (TSME) back on consumer Ryzen 9000 desktop chips through a BIOS update in July, reversing a change it made quietly in the spring. That's the news. The more interesting story for anyone who ships software on AMD hardware is how the feature vanished in the first place — not through a silicon revision or a documented product decision, but through a single flag flipped deep inside firmware, with no changelog entry and no answer when developers asked why. The reinstatement is welcome. The mechanism that removed it should worry you more than the few weeks it was gone.

What TSME actually buys you

TSME is a fixed-function hardware feature in AMD's memory controller that transparently encrypts everything written to DRAM under a key the CPU generates at boot and never exposes to software. Branded AMD Memory Guard on the Ryzen PRO line, it's the same primitive — the company confirmed to multiple outlets that consumer and PRO parts share a common I/O die, so the silicon is physically present on the chips that lost the BIOS option.

The threat model is narrow and worth stating plainly: TSME defends against an attacker with physical access to your machine. Cold-boot attacks, where someone chills the DIMMs, yanks them, and reads residual contents on another rig; DMA attacks over Thunderbolt or PCIe; and the laptop-left-in-a-cab scenario where RAM still holds keys, tokens, and decrypted secrets. It is not a defense against remote code execution or a malicious process on a running system. For most desktop gamers, that makes it close to irrelevant — which is exactly the argument AMD seemed to be banking on.

But "most desktops" isn't who reads a security audit. If you're a developer running a workstation that holds production SSH keys, signing material, kubeconfig files, decrypted secrets in a long-running process, or customer data under a contractual obligation, transparent DRAM encryption is a cheap, zero-config layer that costs you essentially nothing at runtime. Treating it as a checkbox feature is a category error.

A flag, not a fuse

The forensic trail here is the part developers should study. The change surfaced when Ben Kilpatrick, doing a routine hardware-security audit on a new Ryzen 7 9700X (Zen 5), saw his checker report encrypted RAM: not supported even though TSME was still enabled in the BIOS. The tool in question was the Host Security ID surface exposed through fwupd, whose HSI implementation is maintained by an AMD engineer — which is its own small irony.

Working with MSI, he narrowed the regression to a specific firmware version: systems booting under older AGESA reported TSME supported; the same chips under AGESA 1.2.7.0 reported it unsupported. PRO parts were unaffected across vendors and revisions. The smoking gun was a single boot-time flag, DfIsTsmeEnabled, captured from the AMD Boot Loader before the OS ever loads:

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

• Ryzen 9800X3D (consumer): DfIsTsmeEnabled = FALSE even with BIOS set to AUTO or ENABLED
• Ryzen 9945 / EPYC (PRO/server): TRUE when enabled
• Swap a PRO chip into the same Asus X870E board, same BIOS config: tsme_status flips from 0 to 1

This is the crux. The capability was gated by a runtime policy decision in AGESA keyed on the SKU, not blown into the silicon. AMD's own fellow software engineer Tom Lendacky had told a user back in 2020 that a consumer Ryzen 7 3700X "should support TSME," calling it a BIOS option a board vendor needs to expose. For years it behaved that way. Then it didn't, and when developers opened a bug report on AMD's public GitHub, the most they got was "I don't have any more information to share on this topic."

That opacity — not the feature toggle itself — is what turned a minor segmentation tweak into a credibility problem.

Where this leaves AMD against Intel

Product segmentation is normal; every vendor draws lines between consumer and commercial SKUs. The trouble is which line AMD picked. Intel ships Total Memory Encryption-Multi-Key (TME-MK) on mainstream Core parts, not just vPro. Quietly making baseline memory encryption a paywalled enterprise feature, right as the industry is moving the other direction — toward confidential computing, attestation, and encryption-by-default — put AMD on the wrong side of an obvious comparison. The TechPowerUp and Ars Technica threads made that contrast explicit, and AMD clearly read the room: the reinstatement statement leans on "valuable community feedback," which is corporate for we got the optics wrong.

Note what AMD did not concede. It reaffirmed Memory Guard as a "foundational security feature" of the PRO line with "no plans to remove support" there, and framed the consumer fix as restoring a BIOS option. There's no commitment that it'll be on by default, and no explanation of the original decision. The silicon was always capable; the question of who decides what your hardware is allowed to do — and whether they'll tell you when that changes — remains open.

The developer angle: verify, don't assume

The practical lesson is that firmware can silently revoke a security property you thought you owned, and the only way to know is to check. If you rely on TSME, build verification into your provisioning, not your trust.

• Audit the actual state, not the BIOS label. As this whole episode proved, a BIOS toggle set to ENABLED does not mean the feature is active. On Linux, fwupdmgr security surfaces the same HSI attributes that exposed the regression, and dmesg reports active memory-encryption features at boot. Compare what the firmware claims against what the kernel sees.
• Pin your update timeline. AGESA arrives bundled inside motherboard UEFI updates, so the change rode in under a vendor BIOS release that didn't mention it. If memory encryption is part of your threat model, treat firmware updates like any other dependency bump: test the security posture before and after, and don't auto-apply to machines that hold secrets.
• Know your real exposure. If your AMD workstation already lives behind full-disk encryption with a TPM-sealed key and you physically control the box, TSME is defense-in-depth, not load-bearing. If you carry a laptop or run hardware in a space others can touch, it matters more. Match the control to the threat instead of cargo-culting a checkbox.
• If you need guarantees today, buy PRO. AMD has been explicit that Memory Guard is a committed feature on Ryzen PRO, Threadripper WX, and EPYC. The July fix restores an option on consumer 9000 parts; the contractual commitment lives on the commercial SKUs.

The encryption is coming back, and for the handful of developers who genuinely needed it, that's a real fix. But the durable takeaway is colder: the security features of your CPU are increasingly governed by firmware policy you don't control and can't see change. Audit accordingly.