AMD Silently Strips Memory Encryption from Consumer Ryzen CPUs

The Change: AGESA 1.2.7.0 Strips TSME From Consumer Ryzen, Leaves PRO Ryzen Alone

Ars Technica security editor Dan Goodin reported on June 15, 2026 at 1:55 PM ET (HN id 48559827 on June 17) that AMD's AGESA 1.2.7.0 firmware update removed Transparent Secure Memory Encryption from consumer Ryzen CPUs.^[1] AGESA, the AMD Generic Encapsulated Software Architecture, is the firmware framework AMD ships to motherboard vendors. The 1.2.7.0 update is the one that flipped the flag. The change is invisible to anyone who only looks at the BIOS UI. The BIOS option to "enable TSME" is still there. The flag that the firmware actually checks, DfIsTsmeEnabled, is the one that was set to FALSE for consumer parts and left TRUE for PRO and EPYC parts.^[1]

TSME is the firmware-managed variant of AMD's Secure Memory Encryption (SME) family. The OS-managed SME variant uses a single key and lets the OS selectively encrypt individual memory pages. TSME encrypts all of RAM with no OS involvement. When active, it defends against physical attacks, including cold-boot exploits, DRAM interface snooping, and memory-module removal. It activates silently when enabled in the BIOS, which is what made it the practically useful variant. The consumer-Ryzen support was years-old. The 1.2.7.0 update removed it from the consumer line with no announcement, no documentation change, and no Windows-side detection path.^[1]

Microsoft's Windows does not expose an equivalent of fwupd's HSI for the TSME flag. The only first-party way to detect the regression is on Linux, using the fwupd Host Security ID tool. Windows users who relied on TSME for the past several years are getting a silent downgraded product. The Ars Technica piece is direct: "Windows users had no simple way to catch" the change.^[1]

The Investigation: A Hobbyist, Three Motherboard Vendors, and Two AMD Engineers

The change was uncovered by Ben Kilpatrick, who describes himself as a "privacy-conscious Linux hobbyist." In April 2026, Kilpatrick was installing a fresh operating system on a machine running a Ryzen 7 9700X (Zen 5). He ran Host Security ID (HSI), the fwupd auditing feature that evaluates firmware and hardware security configurations, to confirm his protections were active. One line stopped him. The HSI output showed "encrypted RAM: not supported" near the bottom of the audit, where it had previously shown "encrypted." Kilpatrick had kept the option switched on in his BIOS the entire time.^[1]

Kilpatrick spent the next four months chasing an answer. He filed a bug report on AMD's public engineering GitHub repository. Two senior AMD engineers engaged directly. Tom Lendacky, an AMD Fellow Software Engineer, replied that he didn't 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." That suggestion sent Kilpatrick to MSI, the maker of his motherboard, where engineers eventually agreed to run controlled tests. Mario Limonciello, an AMD Senior Principal Software Engineer and the maintainer of the fwupd version of HSI, also suggested the BIOS-toggle reset. "If it still doesn't work; then yes please report it to your board vendor to debug."^[1]

MSI's product marketing team eventually told Kilpatrick that "AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors." MSI's engineering team cross-tested the claim by running a consumer Ryzen 9800X3D and a PRO Ryzen 9945 on the same Asus X870E motherboard, with the same BIOS. The result: tsme_status = 1 on the PRO processor, tsme_status = 0 on the consumer processor. The MSI engineering team also provided ABL memory-dump comparisons showing DfIsTsmeEnabled returning FALSE for the 9800X3D regardless of whether TSME was set to AUTO or ENABLED in the BIOS, and TRUE for the 9945 when TSME was ENABLED.^[1]

Kilpatrick went back to the AMD GitHub thread and asked Lendacky 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." Lendacky referred him to MSI. Limonciello replied directly: "My apologies; but I don't have any more information to share on this topic." With that, the discussion was over. The thread is the public record.^[1]

The AMD Statement: One Sentence, No Explanation

AMD's only public statement on the change is a single sentence. The company "declined to answer questions sent by email other than to say TSME 'is a security feature only applied to PRO CPUs as part of AMD PRO Technologies.'" The statement is the first known time the chipmaker has explicitly made this restriction public. There is no marketing page that says TSME was supported on consumer Ryzen. There is also no marketing page that says it is no longer supported on consumer Ryzen. The change is silent, the documentation is silent, and the company line is silent.^[1]

Joe FitzPatrick, an expert in silicon-level security, told Ars Technica the AMD posture is the worst of both possible worlds. "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," FitzPatrick said. "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.'"^[1]

The Kilpatrick thread on the AMD GitHub repository includes a 2020 reply from Lendacky himself, in a separate discussion about encryption features available in AMD CPUs. The 2020 reply said the Ryzen 3700X, a consumer CPU, "should support TSME." In a 2025 follow-up in the same thread, Lendacky recommended TSME for the consumer chip. The 2020 / 2025 public record is direct evidence that AMD has, in the past, considered TSME a consumer-CPU feature. The June 2026 PRO-only statement is the reversal.^[1]

The Detection Gap: fwupd Is the Audit, Linux Is the Only Detection Path

fwupd is the open-source firmware update project maintained by Richard Hughes at Red Hat, with Mario Limonciello of AMD as a senior contributor and the maintainer of the HSI sub-feature. Host Security ID is the fwupd audit feature that evaluates firmware and hardware security configurations and prints a structured "security" report. The HSI rules are the on-by-default checks that surface as "encrypted RAM: supported" or "encrypted RAM: not supported" in the HSI output. The encrypted-RAM check is the one that surfaced the AMD regression.^[1][4]

Windows users have no equivalent first-party audit. Microsoft does not ship a TSME-flag check in Windows, the Surface devices that ship with AMD Ryzen processors do not surface a TSME status in any first-party tool, and the AGESA 1.2.7.0 update did not include a release note. The change is invisible on Windows unless a third-party tool surfaces the same flag. The Ars Technica piece is direct: "AMD pulled the feature for consumer CPUs without notice or an easy means for users to know."^[1]

The fwupd detection path itself is a Linux-only path that requires the user to know to run the audit. The command is fwupdmgr security on a Linux system with fwupd installed. The output is a long report. The "encrypted RAM" line is the one that needs checking. A user who never runs the audit will not notice the change. A user who upgrades their BIOS firmware and runs the audit will see the change. The rest of the consumer Ryzen installed base is in the dark.^[1][4]

The Mid-Day Compound: Tom's Hardware, the Consumer-vs-PRO Tier-Split, and the Corporate-Discrimination Parallel to Volkswagen-GrapheneOS

Tom's Hardware picked up the AGESA 1.2.7.0 TSME regression on June 18, 2026 at 08:08 UTC, with a piece titled "AMD silently removes memory encryption from consumer Ryzen CPUs" that 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.^[6] The Hacker News thread (id 48582320) on the Tom's Hardware piece by the 13:35 UTC scan on June 18, 2026, the cycle's strongest single-piece signal and the highest-compound mid-day-cycle engagement on the consumer-CPU-privacy beat.^[7]

The 35x growth on a fresh entry point in 5h 50m is the structural signal. The same AGESA 1.2.7.0 firmware story, told from a different URL on a publication the technical-press audience treats as the canonical PC-hardware outlet, compounded from a single-digit-engagement thread to a 252-point thread in under six hours. The piece that catalyzed the compound was not new reporting. It was a re-pickup of the Ars Technica story, told in the same structural frame, on the outlet the consumer-CPU audience defaults to. The mid-day compound confirms the AMD TSME regression has crossed into top-tier territory on the consumer-hardware-privacy beat, the same way the Volkswagen-GrapheneOS thread has crossed into top-tier territory on the consumer-mobile-OS-privacy beat.

The comment thread on the Tom's Hardware piece converged on the same structural read the morning-cycle coverage surfaced. The dominant frame: the consumer-vs-PRO tier-split is not a silicon-level constraint, it is a corporate-tiering decision. The AGESA 1.2.7.0 firmware update removed the consumer-side TSME feature while leaving the PRO-side TSME feature intact. The flag is a firmware policy choice, not a hardware limit. The same silicon that shipped with TSME working on a Ryzen 3700X in 2020, on a Ryzen 9700X in 2025, and on a Ryzen 7 9800X3D in 2026 still ships in the SKU. The difference is which SKUs the firmware will enable the feature for. One commenter on the Tom's Hardware thread put the question directly: "Why did the NSA wait 9 years to say no & why does that explain the coincidence of the feature being supported in the PRO variants of the same CPU, which just happen to cost more?"^[7] The "PRO costs more" detail is the corporate-discrimination angle. The privacy feature is the same silicon. The price tier is the only thing that changed. The consumer SKU is the budget option, the privacy features are the ones that got removed, the PRO SKU is the one that kept them.

The corporate-discrimination parallel is the Volkswagen-GrapheneOS lockout. On May 30, 2026, a Volkswagen WeConnect app update started refusing to log in on GrapheneOS phones. The reason: the app uses the Google Play Integrity API, and GrapheneOS fails that check by design. Volkswagen support's response: the OS is "not an official Volkswagen offering." The Hacker News thread (id 48571526) on the GrapheneOS-Forum post by the 09:24 UTC June 18 scan, the #2 story on the HN front page, and the highest-compound engagement on the corporate-discrimination beat in the current cycle.^[8] The parallel to the AMD TSME regression is structural. In both cases, a corporate vendor decided which customers get the privacy-protective feature and which do not. In the Volkswagen-GrapheneOS case, the gate is the Google Play Integrity API, and the locked-out customers are the GrapheneOS users. In the AMD TSME case, the gate is the AGESA 1.2.7.0 firmware flag, and the locked-out customers are the consumer-Ryzen users. The corporate decision on which customers get the feature is the same. The layer at which the decision gets made is different: an app-level API call in the Volkswagen case, a firmware policy flag in the AMD case. The structural story is the same.

The privacy-feature tier-split is the new corporate-governance question. Who gets the protection, who does not, and which corporate-controlled mechanism decides the answer is the operational shape of the new regime. The Apple Hide My Email subdomain move is the iCloud+ subscription-tier version: a paid consumer privacy feature gets quietly narrowed. The Apple Private Cloud Compute developer-page restriction is the first-party-vs-third-party developer version: a privacy feature ships to the first-party Apple Intelligence lane and not to the third-party App Store developer lane. The UK Apple Advanced Data Protection secret-order regime is the state-compulsion version: a state demand triggers a feature narrowing. The AMD TSME removal is the consumer-silicon version: a firmware flag decides which CPU SKUs get the privacy feature. The Volkswagen-GrapheneOS lockout is the consumer-mobile-OS version: a Google-controlled API decides which phones get the app. The corporate-decision is the same across all five. The layer is different. The user who paid for the consumer SKU is the one who loses the feature in each case.

The Pattern: Privacy-Protective Features Are Now Enterprise-Only, Not Consumer Default

The AMD TSME removal is the second major consumer-silicon-or-software privacy-product-erosion story of the week. The first was Apple's iOS 19 / macOS 16 Hide My Email subdomain move, reported by TechCrunch on June 16, 2026. Apple's change moves every iCloud+ Hide My Email alias from a shared @icloud.com domain to a new @private.icloud.com subdomain that any service can fingerprint and block. The iCloud+ subscription tier is the consumer-paid product. The change ships with no notice, no opt-out, and no refund. The pattern is the same one AMD followed with the AGESA 1.2.7.0 update: the consumer SKU is silently downgraded, the enterprise SKU keeps the feature, and the user is the last to find out.^[2]

Apple's Private Cloud Compute developer-page restriction is the third instance. The PCC page now says the server-side foundation models are only available to first-party Apple Intelligence features and a narrow App Store Small Business Program lane. The marketing copy on the 2024 architecture announcement still calls PCC "the most advanced security architecture ever deployed for cloud AI compute at scale." The marketing and the developer page no longer describe the same product. The consumer third-party developer is the one who lost the access. The enterprise Apple Intelligence lane is the one that kept it.^[3]

The UK Apple Advanced Data Protection "secret order" regime is the fourth instance, and the one with the state-compulsion dimension. The UK government invoked its investigatory-powers technical capability notice against Apple, demanding global backdoor access to iCloud Advanced Data Protection. Apple removed ADP for UK users rather than comply, then the order was quietly reissued. The pattern is the same: the consumer SKU loses the privacy feature, the enterprise lane keeps it, and the user is the last to find out.^[5]

The through-line is the same across all four stories. Privacy-protective features are no longer consumer defaults. They are enterprise lanes, subscription tiers, or backdoors the state can pull. The consumer who paid for the consumer SKU is the one who loses the feature. The AMD TSME removal is the first hardware-level instance of the same pattern. The flag is a firmware policy choice, not a hardware limit. AMD can re-enable it. The decision not to is the policy story, and the policy story is the same one the Apple, the UK Apple ADP, and the Apple PCC pieces have been telling all week.^[2][3][5]

What It Means for You

If you run a consumer Ryzen CPU and you use Linux, the most concrete action is the one Kilpatrick used: run fwupdmgr security and check the "encrypted RAM" line. If the line says "supported," the AGESA firmware on your motherboard has not yet been updated to 1.2.7.0, or your motherboard vendor has shipped a custom build that re-enables the flag. If the line says "not supported," the regression has hit your system, and the consumer-side TSME feature is gone. There is no public AMD tool that will re-enable the flag. The fix is either a firmware rollback (if your vendor has archived the older AGESA build) or a move to a PRO / EPYC part.^[1][4]

If you run a consumer Ryzen CPU and you use Windows, there is no first-party detection path. The change is invisible without third-party tooling. The action is to push AMD, your motherboard vendor, and Microsoft for a first-party audit tool. The Kilpatrick thread on the AMD GitHub repository is the public record. Lendacky and Limonciello are the named engineers. The fwupd HSI rule is the open-source audit that already exists. The Windows-side equivalent is a gap that Microsoft and AMD have not closed.^[1][4]

If you are a system builder or a small-business IT lead, the broader question is the same one Apple is being asked about iCloud+ subscriptions. Is the consumer SKU still worth the price, if the privacy-protective features are being quietly narrowed? The TSME removal is a hardware-level analog. The consumer CPU is the budget option. The privacy features are the ones that got removed. The PRO and EPYC lanes are the ones that kept them. The privacy-as-subscription-argument has a hardware analog, and the hardware analog is the AGESA 1.2.7.0 update.^[1][2]

If you care about the consumer-vs-enterprise security-feature split more broadly, the next twelve months are when the operational shape of the new regime gets set. The first AMD explanation for the change will set the precedent. The first fwupd HSI rule update that flags consumer-Ryzen systems as "encrypted RAM: not supported" by default will set the user-facing default. The first Phoronix or Tom's Hardware follow-up will set the technical-press precedent. The first EFF or consumer-rights coalition statement on the consumer-vs-enterprise security-feature split will set the civil-society precedent. The pattern is not new. The cadence is.^[1][4]

Sources

1. Ars Technica: "Users cry foul after AMD stripped memory crypto from its consumer CPUs" (Dan Goodin, June 15, 2026, 1:55 PM ET, HN id 48559827, the primary source for the AGESA 1.2.7.0 TSME regression, the April 2026 Ben Kilpatrick trigger event, the four-month investigation, the AMD GitHub thread with Tom Lendacky and Mario Limonciello, the MSI / Gigabyte / Asus X870E cross-tests, the DfIsTsmeEnabled ABL memory-dump comparison, the AMD "PRO Technologies only" statement, the Joe FitzPatrick expert interview, the no-Windows-first-party-detection detail, and the SME-vs-TSME design distinction)
2. State of Surveillance: "Apple's iOS 19 Update Makes Hide My Email Useless" (June 17, 2026, the iCloud+ subscription-tier consumer-privacy-erosion, the @private.icloud.com subdomain move, the no-subscriber-notice posture, the same privacy-as-subscription-erosion pattern as the AMD TSME removal, and the same consumer-downgrade-enterprise-keep through-line)
3. State of Surveillance: "Apple's Private Cloud Compute Is Severely Limited for Apps" (June 15, 2026, the Apple PCC developer-page restriction, the Apple-Intelligence-only first-party access, the marketing-vs-developer-page split, the same consumer-downgrade-enterprise-keep pattern as the AMD TSME removal, and the same no-user-notice posture from two days earlier)
4. 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 the consumer-Ryzen TSME regression is documented)
5. State of Surveillance: "UK Apple ADP Secret Order: Inside the Global Encryption Fight" (the UK Apple Advanced Data Protection coverage, the investigatory-powers technical-capability-notice invocation, the Apple-removed-ADP-for-UK posture, and the same consumer-downgrade-enterprise-keep pattern as the AMD TSME removal, with the state-compulsion dimension that distinguishes it from the AMD and the Apple-iOS-19 stories)
6. Tom's Hardware: "AMD silently removes memory encryption from consumer Ryzen CPUs" (June 18, 2026 at 08:08 UTC, the Ars Technica story pickup, the consumer-vs-PRO framing, the AMD-engineers-go-radio-silent framing, the AGESA firmware-regression timeline, the corporate-discrimination angle via the "PRO costs more" pricing structure, the Hacker News submission (id 48582320), the technical-press re-anchor that put the story back on the front page of the consumer-CPU audience, and the corporate-decision-on-which-customers-get-the-privacy-feature parallel to the Volkswagen-GrapheneOS lockout)
7. Hacker News discussion thread on the Tom's Hardware pickup (community conversation under HN id 48582320, the technical-press re-anchor that put the consumer-vs-PRO story back on the front page of the consumer-CPU audience, the comment-thread convergence on the consumer-vs-PRO tier-split-as-corporate-decision frame, the "PRO costs more" silicon-vs-firmware argument, and the corporate-tiering-decision framing)
8. 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 via the Google attestation endpoint, the Cupra and My SEAT parallels, the EU Data Act right-to-own-data framing, the mid-morning addendum compound by the 09:24 UTC June 18 scan, the #2 story on the Hacker News front page, and the corporate-gatekeeper-side parallel to the AMD consumer-vs-PRO hardware-privacy tier-split)