AMD quietly removed TSME, then user backlash forced memory encryption back into Ryzen consumer CPUs
After a silent change, AMD reinstates TSME so physical-memory attacks can no longer read plaintext from consumer chips.

AMD has reinstated TSME memory encryption in consumer Ryzen processors after stripping it and triggering user outcry. For decision-makers, the episode highlights how security feature availability can swing customer trust, support costs, and regulatory scrutiny.
AMD is putting back Transparent Secure Memory Encryption (TSME) in consumer Ryzen CPUs after users noticed it had vanished. According to Ars Technica, AMD had previously removed the protection from lower-end consumer Ryzen processors, and the move was effectively undetectable on Windows while requiring technical work to spot on Linux.
In plain English: TSME encrypts the entire contents stored in memory, so data becomes useless to adversaries running cold boot attacks and similar intrusions that require physical access. After the removal, the same consumer chips that once provided this protection suddenly did not, and AMD did not publicly explain or acknowledge the change when Ars reported last week.
TSME is not a new idea. Ars notes that AMD added it about a decade ago to its high-end CPUs, and over the next few years expanded it to lower-end processors, including the consumer version of Ryzen. The consumer chips affected by the change cost less than the Pro version. That price gap matters, because TSME had been one of the protections users associated with the consumer line, and losing it raised the obvious question: why remove security customers got used to, without warning?
From a risk model perspective, the tradeoff is complicated. Ars includes the view of security experts that consumer chips are far less likely to be targeted by physical attacks than high-end systems. Still, “less likely” is not “never,” and the whole point of memory encryption is to blunt specific attack paths that only become relevant when an attacker has physical access. That is exactly the kind of scenario that does not show up in ordinary benchmarks or day-to-day IT checklists, which is why these features tend to matter most when users, researchers, and defenders audit the system.
The friction here is not only technical. Ars describes the removal as “silent,” “without warning or notice,” and “impossible to detect on Windows machines” with a fair amount of technical work needed on Linux. When a security capability disappears in a way that is hard to detect, people stop treating it like a stable product feature and start treating it like something that can change underneath them. That shift is what tends to trigger backlash, even among users who do not plan to run cold boot attack simulations themselves.
Ars also points to a skeptical interpretation from critics: they saw the change as an underhanded steering mechanism, a way to push buyers toward more costly chips. The logic is straightforward. If TSME is present on Pro and absent on consumer, then customers who care about that kind of physical attack resistance may end up paying the premium without explicitly being told that the security posture changed. Even if AMD’s internal rationale is not about steering, the customer-facing effect is the same: a feature boundary you thought you understood suddenly moves.
This is where governance and incentives come into focus for executives. Large hardware vendors ship at scale, and platform features are tied to validation matrices, supply constraints, and product segmentation strategies. But once a security feature becomes expected by a segment, changing it quietly can collide with trust, customer procurement rules, and enterprise buying processes that rely on published or previously delivered capabilities. Board-level risk here is not just “security” in the abstract. It is reputational damage, support tickets, and the operational drag of defending why something changed after years of consumer expectations.
There is also the regulatory backdrop, even though Ars does not cite a specific regulator in the story. Across consumer and enterprise tech, regulators and standards bodies have been trending toward transparency around security properties. When a feature can be removed without obvious detection, it becomes harder to demonstrate compliance with customer assurances and procurement language. In other words, the compliance burden shifts to whoever bought the hardware and assumed the platform behaved the way it had before.
And for peers, the second-order lesson is brutal: security posture is not a one-time checkbox. Ars describes how AMD added TSME over time, then removed it without explanation. That means the “security roadmap” is not just a future promise. It is also the ongoing responsibility to maintain what was previously delivered, or at least to communicate clearly when it changes.
AMD reinstates TSME in consumer Ryzen CPUs following the user outcry, restoring encryption protections against physical attacks like cold boot. For decision-makers watching the space, this is a reminder that security features are part of product trust, not optional extras. If the security perimeter moves quietly, the market notices loudly. And once customers learn they cannot easily verify a security property, the cost is paid in credibility, not just compute.
This story's Key Insights and Take-aways are locked.
Create a free account to unlock Executive Actions for one credit.
Register to UnlockAlways free for Executives Club members. Join the Club
More in Technology

Fitbit Air’s Health Coach tells users to skip workouts and hydrate in 90+ degree heat
Google’s AI health tracker leans hard on readiness, sleep, and recovery signals to override your plans.

Valve greenlights SteamOS 3.8 on normal PCs, but only AMD GPUs for now
You can install Valve’s Linux on your own living-room rig, but Nvidia owners are still waiting.

Meta launches cheaper smart glasses under its own brand in select countries today
A new, lower-cost Meta-branded glasses line starts rolling out now, with multiple colors and lens options.
