AMD Will Reinstate Memory Encryption on Ryzen 9000 CPUs

The Reversal: BIOS Update in July 2026, "Valuable Community Feedback"

Tom's Hardware Senior CPU Analyst Jake Roach published the reversal story on June 19, 2026 at 21:02:49 UTC, under the headline "AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July."^[1] The piece reports that AMD will ship a BIOS update in July 2026 that restores the Transparent Secure Memory Encryption (TSME) option on consumer Ryzen 9000 CPUs. AMD's stated reason, per the Tom's piece, is "valuable community feedback."^[1]

The reversal closes a five-day window. Ars Technica security editor Dan Goodin published "Users cry foul after AMD stripped memory crypto from its consumer CPUs" on June 15, 2026 at 1:55 PM ET (HN id 48559827).^[4] The Ars Technica piece was the structural anchor: it named the AGESA 1.2.7.0 firmware update, the internal DfIsTsmeEnabled flag, the consumer-Ryzen scope, the months-long Ben Kilpatrick investigation, the AMD GitHub thread with Tom Lendacky and Mario Limonciello, and the AMD corporate statement that TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies."^[2][4]

Tom's Hardware picked up the Ars Technica story on June 18, 2026 at 08:08 UTC, in a piece titled "AMD silently removes memory encryption from consumer Ryzen CPUs." That piece ran the same Kilpatrick investigation, the same MSI X870E cross-test, the same ABL memory-dump evidence, and the same AMD "PRO Technologies only" statement. The Hacker News thread on the Tom's Hardware piece (id 48582320) hit 252 points and 124 comments by the 13:35 UTC scan on June 18, a 35x growth in 5h 50m from the 7 points at the 07:45 UTC morning-cycle scan.^[2] The reversal comes 24 hours after the Tom's Hardware pickup, and 5 days after the Ars Technica primary.

The AMD Statement: One Sentence, Reversed

The AMD statement in the Tom's Hardware piece is, like the original June 15 statement, a single sentence. AMD's reason for reinstating the option is "valuable community feedback." The community in question is the same fwupd Host Security ID users, Ars Technica readers, Tom's Hardware commenters, and Hacker News thread readers who surfaced the regression in the first place. The corporate posture is the same on both sides of the reversal: one sentence, no further explanation.^[1][2]

Hacker News commenter close04 quoted AMD directly on the reversal: "Based on valuable community feedback, we will reinstate this option in an upcoming BIOS release in July."^[3] Close04's read of the AMD posture is direct: "Their statement suggests it was a calculated decision, reversed after public backlash. I greatly appreciate they listened to user feedback, but they shouldn't have done it secretly to begin with."^[3]

The reversal does not retract the June 15 corporate statement. TSME on consumer Ryzen, per the still-in-force AMD line, "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies." That sentence is the AMD explanation for the original removal, and it remains the AMD explanation for the original removal even after the BIOS update reinstates the option. The reversal is a BIOS-firmware-level re-enable. The corporate posture on why the original removal happened has not moved.^[4]

The June 15 AMD statement was the first public acknowledgment that the consumer-PRO split is intentional. The reversal confirms it. The flag was set to FALSE on consumer SKUs on purpose. The flag is being set back to TRUE on consumer SKUs on purpose. Both decisions are corporate-tiering decisions. The reversal confirms the corporate-tiering mechanism, even as it walks back the specific June 15 outcome.^[2][4]

The Discourse: Threat-Model Debate, Default-Off Compromise, and the Performance-Cost Frame

The Hacker News thread on the Tom's Hardware reversal piece (id 48612098) hit 112 points in four hours from its 19:19:06 UTC posting, the highest engagement-per-hour of any thread in the State of Surveillance tracker record.^[3] The comment thread diverged on three threads: the threat-model question (does physical access to a consumer desktop matter?), the default-state question (should the reinstated TSME option ship enabled or opt-in?), and the performance-cost frame (the 0.5 to 1 percent memory-speed hit).

On the threat-model question, commenter theandrewbailey argued the physical-access threat is real for consumer desktops: "TSME isn't a critical security feature for most consumer desktops, as it protects against attacks where the attacker needs physical access to the device. If you think it's hard to gain physical access to a consumer desktop, you're out of touch. Most desktops aren't locked inside a datacenter. Memory encryption is a valuable desktop (and laptop) security" feature.^[3] The counter-position, from commenter WillPostForFood: "So my PC runs 5% slower because someone could break into my house to get physical access to decrypt memory? OK sure, but not my top concern, and a bad tradeoff for the lost performance. And not only fair, but completely accurate to describe TSME as non-critical for most consumer desktops."^[3] Commenter dist-epoch added: "And it does reduce memory speed by about 0.5-1%."^[3]

On the default-state question, the compromise position emerged from commenter futuraperdita: "So you turn it off by default in BIOS and allow those that feel it's useful to them to enable it, and you solve for both sides of the problem."^[5] The default-off position is consistent with the performance-cost frame and the "most consumer desktops don't need it" position. The default-on position is consistent with the privacy-as-tier critique and the corporate-tiering framing. The Tom's Hardware piece does not confirm which way AMD will ship. The July BIOS update will answer it.^[1]

On the firmware-as-attack-surface question, commenter saghm argued the original AGESA 1.2.7.0 change set a bad precedent independent of the TSME-on-or-off question: "None of that is a good rationale for patching the firmware to retroactively remove things from devices that were sold years ago. It is an abuse of a mechanism that's ostensibly meant for security fixes and maybe perf improvements, which is a dangerous game because it incentivizes people to just not update the firmware at all, which is a worse scenario for both parties."^[3] Saghm's frame treats the AGESA 1.2.7.0 change as a precedent for what firmware updates can do, not as a one-off decision about TSME specifically. The reversal, per saghm's frame, does not address the precedent.^[3]

On the community-feedback framing itself, commenter stefanfisk pushed back on the framing as not-representative: "Judging by the Reddit threads I saw, A LOT of people were upset even though it was clear that they had not idea what the feature actually provided beyond 'encryption.' I'd guess that the majority assumed that the change would result in them basically having to 'encryption' in affected AMD devices any more in some vague general sense."^[3] Commenter Havoc agreed: "I'm a little puzzled by the uproar given that all the oneline chatter seems to suggest nobody is using this. If this was AVX512 or something I could understand the give it back reaction..."^[3] The community-feedback framing, per the stefanfisk and Havoc critique, is the loudest subset of the consumer-Ryzen user base, not a representative cross-section. The corporate response is to the loudest signal, not to the median user.

The Pattern: The Cost of Silent Removal Is Loud Reversal

The AMD reversal is the second time in five days that a corporate-controlled mechanism for a consumer privacy feature has been walked back under public pressure. The first was the Apple iOS 19 Hide My Email subdomain move, which Apple effectively reversed on June 18 after a TechCrunch piece and a State of Surveillance story drove the kind of consumer outcry that gets corporate-communications teams to walk a position back. The structural parallel is the same: a corporate-controlled mechanism decides which users get the privacy feature. The corporate decision is silent. The community response is loud. The corporate walkback is silent.^[7]

The Apple Hide My Email case was a subscription-tier walkback. The AMD TSME reversal is a firmware-tier walkback. The corporate decision is at a different layer. The pattern of "make the privacy feature corporate-controlled, then change the corporate decision under public pressure, then walk back the original decision silently" is the same. The Apple walkback came from a TechCrunch piece and the iCloud+ subscriber-base complaint channel. The AMD walkback came from an Ars Technica piece, a four-month Linux-hobbyist investigation, a Tom's Hardware pickup, and a 252-point Hacker News thread. The corporate posture on the original decision was one sentence in both cases. The corporate posture on the reversal is one sentence in both cases.^[1][4]

The pattern question, raised by commenter jdsully in the Tom's Hardware HN thread, is the precedent question: "Physical hardware products shouldn't lose features after launch. If this was a 'mistaken' feature which they suggested it was they should have disabled it on future chips."^[3] Jdsully's frame: if the TSME-on-consumer-Ryzen was a mistaken feature, AMD could have left existing chips alone and disabled it on future chips. The AGESA 1.2.7.0 update removed the feature from chips that had already shipped. The reversal reinstates it on chips that had already shipped. The precedent, either way, is that firmware updates can change shipped features in either direction.^[2]

The corporate-controlled gate at the firmware layer is the structural pattern. The Apple App Store gate is the structural pattern on the iOS side. The Google Play Integrity API gate is the structural pattern on the Android side. The AMD AGESA firmware gate is the structural pattern on the consumer-CPU side. In each case, a corporate-controlled mechanism decides which users get which features. In each case, the gate can be flipped silently. In each case, the community response is loud when the flip is noticed. The AMD reversal is the consumer-CPU instance of the same gate-flipping pattern the Apple, the Volkswagen-GrapheneOS, and the UK Apple ADP stories have been telling.^[2][6]

What It Means for You

If you run a consumer Ryzen CPU and you use Linux, the fwupd Host Security ID audit is still the way to confirm the reinstated option is working once the BIOS update ships. The command is fwupdmgr security on a Linux system with fwupd installed. The output will show the "encrypted RAM" line. Once the July BIOS update rolls out through your motherboard vendor and you install it, the "encrypted RAM" line should read "supported" again. The Windows-side detection path is still missing. Microsoft does not ship a TSME-flag check in Windows. The change is invisible on Windows without third-party tooling.^[2][8]

If you run a consumer Ryzen CPU and you use Windows, the change will land through your motherboard vendor's BIOS update channel. Asus, MSI, Gigabyte, ASRock, and Biostar each maintain their own BIOS release cadence. Subscribe to your motherboard vendor's BIOS update mailing list or check the support page for your specific board model in July. The Tom's Hardware piece names the BIOS update as the delivery mechanism, but it does not name which motherboard vendor ships first. The chain from AMD AGESA to a working consumer-Ryzen TSME flag goes through each vendor's BIOS integration pipeline.^[1]

If you are a system builder, a small-business IT lead, or a managed-service provider, the operational question is whether the reinstated option will ship enabled-by-default or opt-in. The performance-cost frame argues for opt-in (TSME reduces memory speed by about 0.5 to 1 percent, per the HN thread). The privacy-as-tier critique argues for default-on. The Tom's Hardware piece does not confirm which way AMD will ship. The default-state answer is the operational one the July BIOS update will give. Plan for either: the BIOS update might require a fleet-wide re-enable pass if it ships opt-in, or a fleet-wide verification pass if it ships default-on.^[1][3]

If you care about the corporate-controlled-gate pattern more broadly, the AMD reversal confirms the precedent rather than walking it back. The AMD corporate posture can flip a firmware-controlled privacy feature in either direction. The reversal is the right direction. The structural fact is unchanged. A future AMD corporate decision can flip the same flag again. The next twelve months will be when the cadence of those flips, and the public-pressure threshold for reversing them, gets set.^[1][2]

Sources

1. Tom's Hardware: "AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July" (Jake Roach, June 19, 2026, 21:02:49 UTC, the AMD statement on the BIOS update timeline, the "valuable community feedback" framing, the Ryzen 9000 series scope of the reinstated option, the AGESA 1.2.7.0 reversal context, and the OG description noting the original quiet removal via firmware update on non-PRO Ryzen CPUs)
2. State of Surveillance: "AMD Silently Strips Memory Encryption from Consumer Ryzen CPUs" (June 17, 2026, the Ars Technica / Dan Goodin June 15 piece, the AGESA 1.2.7.0 firmware regression, the Ben Kilpatrick fwupd HSI investigation, the AMD GitHub thread with Tom Lendacky and Mario Limonciello, the AMD "PRO Technologies only" corporate statement, the Tom's Hardware June 18 pickup at 252p/124c, and the corporate-discrimination parallel to the Volkswagen-GrapheneOS lockout)
3. Hacker News: "AMD will reinstate memory encryption on Ryzen 9000 CPUs via BIOS update in July" (Tom's Hardware reversal piece) (HN id 48612098, posted 2026-06-20T19:19:06Z, 112 points at scan, 4-hour-old thread at 23:39 UTC, the engagement-per-hour State of Surveillance tracker record, the comment-thread divergence on the threat-model and the default-state, the close04 verbatim AMD quote on the reversal, the theandrewbailey physical-access threat-model argument, the WillPostForFood performance-cost counter-argument, the dist-epoch 0.5-1% memory-speed figure, the saghm firmware-as-attack-surface critique, the stefanfisk not-representative framing, and the jdsully hardware-products-shouldn't-lose-features-after-launch precedent question)
4. Ars Technica: "Users cry foul after AMD stripped memory crypto from its consumer CPUs" (Dan Goodin, June 15, 2026, 1:55 PM ET, the primary source for the AGESA 1.2.7.0 TSME regression, the Ben Kilpatrick four-month investigation, the MSI X870E cross-test, the DfIsTsmeEnabled ABL memory-dump comparison, the Tom Lendacky and Mario Limonciello GitHub thread, the AMD "PRO Technologies only" corporate statement, the no-Windows-first-party-detection detail, and the SME-vs-TSME design distinction)
5. Hacker News comment on the Tom's Hardware reversal piece (HN id 48612098, futuraperdita's default-off compromise position: "So you turn it off by default in BIOS and allow those that feel it's useful to them to enable it, and you solve for both sides of the problem", the opt-in-vs-default-on framing, and the threat-model-vs-performance-cost trade-off)
6. State of Surveillance: "Volkswagen Started Blocking GrapheneOS Users From Their Cars" (June 17, 2026, the Volkswagen WeConnect app, the Google Play Integrity API gate, the corporate-discrimination pattern at the app layer, the Cupra and My SEAT parallels, the EU Data Act right-to-own-data framing, the 676p/405c mid-morning addendum compound by the 09:24 UTC June 18 scan, and the corporate-gatekeeper-side parallel to the AMD AGESA firmware gate)
7. State of Surveillance: "Apple's iOS 19 Update Makes Hide My Email Useless" (June 17, 2026, the iCloud+ Hide My Email subdomain move, the @private.icloud.com fingerprinting risk, the no-subscriber-notice posture, the same corporate-controlled-mechanism pattern as the AMD AGESA firmware flag, and the same silent-decision-loud-response-silent-walkback cadence that the AMD reversal completes)
8. fwupd GitHub project: Host Security ID audit tool (github.com/fwupd/fwupd, the open-source firmware-update project with the Host Security ID (HSI) audit feature, the HSI encrypted-RAM rule for AMD TSME, the fwupdmgr security command-line interface, the Richard Hughes project maintainership, the Mario Limonciello HSI sub-feature maintainership at AMD, and the HSI rule repository where both the AGESA 1.2.7.0 consumer-Ryzen TSME regression and the July 2026 reinstatement will surface)