AMD's removal of TSME from consumer CPUs appears to be an intentional, hidden decision.
Ten years ago, AMD introduced a safeguard on its premium processors to shield them from cold boot attacks and other physical exploits that extract sensitive data from attached memory modules. Known as Transparent Secure Memory Encryption (TSME), this feature encrypts all data stored in RAM, rendering it useless to attackers with physical access.
Over time, AMD extended TSME to more affordable processors, including the consumer versions of its Ryzen chips, which are less costly than the Pro variants. Over the years, users of these budget-friendly CPUs have grown accustomed to the extra security. Recently, without any announcement or notification, this lower-tier Ryzen line abruptly dropped the protection, doing so in a manner that was undetectable on Windows systems and required significant technical effort on Linux.
Here one moment, gone the next
AMD has not explained why TSME functioned on these CPUs, nor has it even confirmed the change. The company declined to answer emailed questions, stating only that TSME “is a security feature only applied to PRO CPUs as part of AMD PRO Technologies.” This statement marks the first time the chipmaker has explicitly made this restriction public.
In April, Ben Kilpatrick, a self-described “privacy-conscious Linux hobbyist,” was installing a new operating system on his machine equipped with a Ryzen 7 9700X from the Zen 5 architecture. To verify that all security protections were active, he ran Host Security ID (HSI), an auditing tool that assesses firmware and hardware security configurations.
To his surprise, HSI indicated that TSME was no longer available, as shown by the “encrypted RAM: not supported” line near the bottom of the screenshot below. A few lines further down, the HSI output showed that TSME had previously been listed as “encrypted.” This puzzled Kilpatrick, as he had consistently enabled TSME in his BIOS settings.
This discovery prompted Kilpatrick to launch a months-long investigation to uncover what had occurred. After contacting both the support and engineering teams at MSI, the manufacturer of his motherboard, he eventually persuaded company engineers to conduct tests.
They discovered that consumer versions of Ryzen running on MSI and Gigabyte motherboards had TSME enabled when an older firmware version, available exclusively through the AMD Generic Encapsulated Software Architecture (AGESA), described here, was used during boot. When the firmware in a newer AGESA, specifically version 1.2.7.0, was employed instead, TSME showed as “not supported.” Pro versions of the Ryzen CPU supported TSME across both motherboard brands and AGESA versions.
“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. He continued:
The reason that distinction matters is that if it is deliberate policy, AMD made a conscious decision to remove a working feature from consumer hardware and restrict it to enterprise customers. If it is an accidental regression, it is a firmware bug that AMD should fix. Either way the silicon is capable, either way the change happened in AGESA, and either way AMD has declined to explain it. But the two scenarios imply very different things about exactly what happened.
The reason that distinction matters is that if it is deliberate policy, AMD made a conscious decision to remove a working feature from consumer hardware and restrict it to enterprise customers. If it is an accidental regression, it is a firmware bug that AMD should fix. Either way the silicon is capable, either way the change happened in AGESA, and either way AMD has declined to explain it. But the two scenarios imply very different things about exactly what happened.
As part of his investigation, Kilpatrick filed a bug report on AMD’s public engineering GitHub repository. Two AMD engineers engaged directly.
Tom Lendacky, an AMD fellow software engineer, replied that he did not know what caused the change. He suggested disabling and then re-enabling the option in the BIOS. “If that doesn’t work, my guess would be that it is a BIOS issue and you would want to contact MSI.” (This suggestion led Kilpatrick to persuade MSI engineers to run the tests mentioned earlier.)
Mario Limonciello, AMD senior principal software engineer and maintainer of the fwupd version of HSI, then joined in. He also recommended disabling and re-enabling the BIOS settings. “If it still doesn’t work; then yes please report it to your board vendor to debug,” he said.
I have nothing more to share, AMD engineer says
Six weeks later, Kilpatrick resumed the discussion. After receiving the results of MSI’s investigations, he reported them to the AMD engineers.
“MSI’s product marketing team has informed me that AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors,” he wrote. “They [MSI support personnel] also conducted controlled testing on an Asus X870E motherboard with a Ryzen 9800X3D (consumer) and a Ryzen 9945 (PRO), finding tsme_status = 1 on the PRO processor and tsme_status = 0 on the consumer processor with the same board and BIOS.”
A setting of 1 indicated TSME was enabled. A status of 0 meant it was off.
Next, Kilpatrick directed the engineers’ attention to results from memory captures from the AMD Boot Loader. Typically abbreviated as ABL, it is a component within AGESA that initializes the hardware before the OS loads. MSI’s engineering team found that a string indicating the status of TSME early in the boot process was never enabled.
The memory capture showed that DfIsTsmeEnabled, an internal AGESA flag that controls whether TSME is activated during firmware initialization, was not turned on. The ABL memory dump comparisons returned different values depending on whether the Pro or consumer CPU version was used. The flag showed FALSE for consumer processors and TRUE for PRO or EPYC processors when TSME was enabled in the BIOS.
“Their BIOS engineer also provided ABL dump comparisons showing DfIsTsmeEnabled returning FALSE for the 9800X3D regardless of whether TSME is set to AUTO or ENABLED in BIOS,” Kilpatrick reported, “while the 9945 returns TRUE when TSME is ENABLED.”
Kilpatrick went on in the thread to remind Lendacky that in 2020, the engineer had confirmed TSME was supported on a Ryzen 3700X (a consumer CPU). After more back-and-forth discussion, Kilpatrick asked bluntly: “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.”
Limoncello promptly replied: “My apologies; but I don’t have any more information to share on this topic.” With that, the discussion and Kilpatrick’s inquiry were over.
The Lendacky comment in 2020 Kilpatrick referred to came in this thread discussing encryption features available in AMD CPUs. Lendacky said that the Ryzen 3700x, a consumer CPU, “should support TSME.” In a 2025 comment in the same thread, the engineer followed up on his comment concerning the 3700x.
“I recommend using TSME (Transparent SME), but it is a BIOS option that needs to be exposed by your BIOS provider,” Lendacky said in response to the question about the consumer chip.
There is no indication that AMD ever advertised or marketed TSME as being available in consumer CPUs. AMD has long stated that a related memory protection, Secure Memory Encryption (SME), is available only in the Pro and Epyc CPU tiers. SME is OS-managed. It uses a single key and allows the OS to selectively encrypt individual memory pages. TSME is firmware-managed. It encrypts all RAM with no OS involvement. When active, it provides protection against physical attacks, including cold boot exploits, DRAM interface snooping, and memory module removal. It activates silently when enabled in the BIOS, making it the more practically useful of the two protections.
AMD engineers’ comments, such as those mentioned above, and the years of TSME working just fine in the lower-cost tier processors, have understandably conditioned Kilpatrick and other users to reasonably regard it as an expected part of the chip package. AMD quietly removing it and providing no acknowledgment or explanation strikes these users as something of a betrayal.
“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,” Joe Fitzgerald, an expert in silicon-level security, said in an interview, referring to AMD’s potential motivations for withdrawing TSME. “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.’”