Your Ryzen CPU used to encrypt your RAM. A firmware update silently turned that off.

AMD has silently disabled a security feature on its consumer Ryzen processors that protected users against physical attacks on their computer’s memory. The feature, Transparent Secure Memory Encryption, encrypts all data stored in RAM using a hardware-generated key that changes on every boot. When active, it renders cold boot attacks, DRAM interface snooping, and physical memory module removal useless because the extracted data is encrypted.

TSME worked on consumer Ryzen chips for years. A firmware update quietly turned it off, and AMD has refused to explain why.

The change was discovered in April by Ben Kilpatrick, a privacy-focused Linux user who was installing a new operating system on a machine running a Ryzen 7 9700X, part of AMD’s Zen 5 architecture. When he ran Host Security ID, an auditing tool that evaluates firmware and hardware security configurations, the output showed that encrypted RAM had changed from “Encrypted” to “Not supported” with no corresponding BIOS update or system change.

Kilpatrick filed a bug report on AMD’s public engineering GitHub repository. 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.

Mario Limonciello, an AMD principal member of technical staff and maintainer of fwupd, the Linux firmware update utility, gave the same advice.

Neither suggestion worked. Kilpatrick escalated the issue to MSI, the manufacturer of his motherboard, and eventually convinced the company’s engineering team to run controlled tests.

The results were definitive. MSI tested both a consumer Ryzen 9800X3D and a Pro Ryzen 9945 on the same Asus X870E motherboard with the same BIOS. The Pro chip returned a TSME status of 1, meaning enabled, while the consumer chip returned 0.

MSI’s BIOS engineers went further, examining memory captures from AMD’s Boot Loader, a component within AMD’s Generic Encapsulated Software Architecture firmware that initialises hardware before the operating system loads. They found that an internal AGESA flag called DfIsTsmeEnabled returned FALSE for the consumer processor regardless of whether TSME was set to AUTO or ENABLED in the BIOS. The same flag returned TRUE for the Pro chip when TSME was enabled.

The silicon in both processors is identical. The restriction is enforced entirely in firmware. The consumer Ryzen chip is physically capable of encrypting memory but is being told not to.

When Kilpatrick reported these findings back to AMD’s engineers on GitHub, he asked directly whether DfIsTsmeEnabled being set to FALSE on consumer chips was a silicon limitation or a firmware policy decision. Limonciello replied: “My apologies; but I don’t have any more information to share on this topic.” The discussion ended there.

AMD declined to answer questions from Ars Technica beyond a single statement: TSME “is a security feature only applied to PRO CPUs as part of AMD PRO Technologies.” This is the first known time the company has explicitly stated this restriction. AMD has long said that the related feature Secure Memory Encryption is limited to Pro and EPYC tiers, but TSME occupied a greyer area.

The history complicates AMD’s position. In a 2020 GitHub discussion about encryption features on AMD processors, Lendacky confirmed that a Ryzen 3700X, a consumer chip, “should support TSME.” In a 2025 follow-up in the same thread, he recommended using TSME on what was clearly a consumer processor.

Chip-level security vulnerabilities have a long history of catching vendors off guard, but this is not a flaw being discovered. It is a working feature being withdrawn.

AMD never formally advertised TSME as available on consumer Ryzen chips. But the feature worked, AMD’s own engineers confirmed it worked, and users built their security posture around it.

The change arrived through a routine AGESA firmware update with no release note, no advisory, and no way for Windows users to detect it. On Linux, detection required running HSI or reading a specific hardware register manually.

The practical impact is straightforward. Anyone using a consumer Ryzen processor who relied on TSME to protect against physical access attacks, including journalists, activists, security researchers, and anyone working with sensitive data on a laptop, has lost that protection without being told.

The BIOS setting still appears. It still toggles. It does nothing.

Firmware-level security changes in processors are notoriously difficult for end users to detect, and chipmakers have historically been slow to communicate them. AMD’s silence on whether this was an intentional policy decision or an accidental regression makes it impossible for affected users to assess their risk.

Joe Fitzgerald, an expert in silicon-level security, told Ars Technica that AMD owes users an explanation regardless of the cause. “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,” he said. Either way, the silicon is capable, the feature was working, and it was removed through firmware without notice.

The question Kilpatrick posed to AMD’s engineers remains unanswered: is this a bug or a business decision? If it is a bug, AMD should fix it.

If it is a deliberate restriction of a working security feature to push users toward more expensive Pro hardware, AMD should say so. The current position, acknowledging the restriction while refusing to explain it, satisfies neither possibility.