TL;DR: About a decade ago, AMD added Transparent Secure Memory Encryption to its high-end processors to close a gap in hardware security. TSME encrypts everything in RAM, which blunts cold-boot attacks and other hands-on memory exploits targeting data as it sits on the DIMMs. Over time, the same mechanism quietly appeared on some consumer Ryzen chips as well. Then, after a recent firmware update, it stopped working there, and AMD has offered only a limited explanation for why.
The change came to light in April, when Ben Kilpatrick installed a new OS on a Ryzen 7 9700X system built on AMD's Zen 5 architecture. He describes himself as a "privacy-conscious Linux hobbyist," and part of his routine is to verify that hardware security features are switched on. To do that, he uses Host Security ID, a checker that inspects firmware and hardware configuration.
On earlier firmware, HSI had reported that RAM encryption was enabled on his machine. This time, the readout showed "encrypted RAM: not supported," even though TSME was still enabled in the BIOS.
A few lines lower, HSI showed that the same system had previously reported RAM as "encrypted." The mismatch between the BIOS setting and the current status is what prompted him to look for an explanation.
Kilpatrick contacted MSI, which made his motherboard, and pushed for tests across different boards and firmware versions. MSI engineers eventually confirmed that consumer Ryzen CPUs reported TSME as supported when an older version of AGESA, AMD's Generic Encapsulated Software Architecture, handled the firmware path during boot.
When systems booted with AGESA 1.2.7.0, those same chips reported TSME as "not supported." Pro-branded Ryzen parts did not change behavior. They showed TSME support across both MSI and Gigabyte boards and across AGESA revisions.
That pattern suggested the silicon was still capable of TSME and that the shift in behavior was tied to firmware. "The big outstanding question is whether this is a deliberate policy decision by AMD to restrict TSME to PRO chips, or an unintentional regression that was introduced in AGESA 1.2.7.0," Kilpatrick told Ars Technica. In his view, "either way the silicon is capable, either way the change happened in AGESA, and either way AMD has declined to explain it."
To get a more direct answer, he opened a bug report in AMD's public GitHub repository for its secure virtualization and memory features. Two AMD engineers responded. Tom Lendacky, an AMD fellow software engineer, said he did not know what caused the change and suggested toggling the BIOS setting: turn TSME off, then back on, and if that failed "my guess would be that it is a BIOS issue and you would want to contact MSI."
Mario Limonciello, a senior principal software engineer who maintains the fwupd implementation of HSI, gave similar advice: try again at the BIOS level, and if it still doesn't work, "then yes please report it to your board vendor to debug."
By the time Kilpatrick returned to the thread six weeks later, MSI had done more detailed analysis. He reported that MSI's product marketing team told him "that AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors."
MSI engineers also broadened their tests. On an Asus X870E board, a Ryzen 9800X3D and a Ryzen 9945 were swapped in and out with the same BIOS configuration. With the Pro chip installed, the system reported tsme_status = 1. With the consumer chip, it reported tsme_status = 0.
The team then examined how AGESA made decisions early in the boot sequence. They captured the output of the AMD Boot Loader, a component within AGESA that runs before the OS, and compared internal state.
One flag, DfIsTsmeEnabled, determines whether TSME is actually turned on during firmware initialization. In the dumps MSI provided, DfIsTsmeEnabled returned FALSE for the Ryzen 9800X3D even when the BIOS had TSME set to AUTO or ENABLED. On the Ryzen 9945 and on Epyc parts, the same flag returned TRUE when TSME was enabled.
Kilpatrick pointed the engineers back to earlier commentary from AMD that showed a different stance. In a 2020 discussion about encryption support in AMD CPUs, Lendacky had written that a consumer-grade Ryzen 3700X "should support TSME," and later added, "I recommend using TSME (Transparent SME), but it is a BIOS option that needs to be exposed by your BIOS provider."
That history, combined with the years where TSME behaved as expected on some non-Pro chips, is part of why Kilpatrick and other users viewed it as a standard part of the package.
After presenting the new AGESA and ABL data, Kilpatrick put a precise question to the engineers: "is DfIsTsmeEnabled being set to FALSE on consumer SKUs a silicon-level limitation, or is it a firmware policy decision within AGESA? The distinction matters quite a bit from a user perspective, since one is fixed and the other is potentially changeable."
Limonciello replied, "My apologies; but I don't have any more information to share on this topic." AMD, responding separately by email, said that TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies."
AMD has long drawn a line between TSME and Secure Memory Encryption. SME, which the company has always described as limited to Pro and Epyc tiers, is managed by the operating system and can encrypt selected memory pages using a single key. TSME is managed in firmware and encrypts all RAM without any involvement from the OS. When enabled in BIOS, it operates silently but still protects against cold boot, DRAM bus snooping, and similar physical attacks.
For users who had built threat models around that behavior, the quiet removal of TSME from newer consumer-grade processors, combined with the absence of a detailed technical rationale, has been unsettling.
Joe FitzPatrick, who focuses on silicon-level security, argued that the lack of clarity is the main problem. "They could have not realized they did it leading to their cagey responses, or they could have done it intentionally and tried to get away with it, leading to the same cagey responses," he said. "But I really feel like an explanation should be in order, even if it was 'TSME was never supposed to be supported. We did ship some firmwares that erroneously enabled it, but you shouldn't use them since we can't guarantee it'll work properly.'"