All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
AMD removes RAM encryption from Ryzen consumer CPUs, reactivates it after community backlash
Original article on Ars Technica: https://arstechnica.com/security/2026/06/users-cry-foul-after-amd-stripped-memory-crypto-from-its-consumer-cpus/
AMD's response to Tom's Hardware's inquiry: https://www.tomshardware.com/pc-components/cpus/amd-will-reinstate-memory-encryption-on-ryzen-9000-cpus-through-a-bios-update-in-july-tsme-is-coming-back-after-valuable-community-feedback
GitHub open issue with the full timeline: https://github.com/AMDESE/AMDSEV/issues/292
Personally, I'm not sure if they removed it to push people who need this feature to upgrade to a PRO-line CPU or if a three-letter US government agency reached out to them. At least it's being reinstated now.

Comments
Consumer users have no use for it. This only make sense when running VMs, and you want to protect your guest memory from the Hypervisor. Makes more sense if gaming companies reached to them, because it will potentially make various anti-cheat engines useless. Also, there is a performance degradation when you use it. And they want to look nice and shiny in benchmarks. Remember the performance drop with Spectre and Meltdown, ZenBleed? Even worse with AMD SEV-SNP. Consumers want good geekbench scores, not security.
I would disagree with that to some extent. Most consumers use Windows so they have BitLocker enabled by default even though they don't realize it. If someone steals their laptop or PC, it's easier nowadays to perform a cold boot attack to retrieve their data (at least if the RAM isn't soldered). Besides that, if the silicon already supports it, why disable it? There's no good reason really.
As for performance, it doesn't have a horrendous impact, it's only AES-128 which AES-NI helps with a lot. See Cloudflare and Oracle's experiences: https://blog.cloudflare.com/securing-memory-at-epyc-scale/ https://blogs.oracle.com/cloud-infrastructure/perf-impact-of-confidential-computing-on-oci-vms
Those are desktop class CPUs.
Cloudflare is not a good benchmark since their workload is different - they transit data,
not doing CPU heavy tasks on it. Well, at least not to an extent of a gaming-focus CPU.
That's debatable, but we'd need to see benchmarks of RAM encryption for gaming specifically to know the actual numbers.
FWIW, check Onidel's yabs with and without:
https://kb.onidel.com/hc/kb/articles/1771943583-sev_snp-verified-boot-and-memory-encryption
This is similar to the numbers I saw. Quite noticeable when you need to switch contexts
between kernel and userspace, which directly affects disk I/Os.
Ah yeah fair enough. I have a 9800X3D with a MSI B850 Gaming Plus mobo (and a RTX 5070 Ti), I updated my BIOS recently so maybe TSME has been deactivated but if it hasn't I should run some benchmarks.
Hm, in this article I attribute the slower IO is mostly due to data being copied back and forth in shared SWIOTLBs when talking to external devices. This all happens in kernel space.
In general, a single YABS should not generally be treated as a benchmark. That section was included more to give an idea of what to expect. However I really appreciate the mention
Phoronix did better evaluation of SEV-SNP performance on EPYC Turin 9005 CPU:
https://www.phoronix.com/review/amd-epyc-9005-sev-snp
There are also some measurements of SEV-SNP effects on latency and overall data throughput in this article.
Worth noting this thread is about TSME, not SEV-SNP. Those are essentially two different things with TSME focusing on encrypting entire system memory, while SEV-SNP was specifically made for virtualized environments with different encryption keys used per VM.