ASUS has begun posting beta BIOS updates for its AM5 800-series motherboards that include AMD AGESA ComboAM5 PI 1.3.0.1b Patch A, restoring the Transparent Secure Memory Encryption option for affected non-PRO Ryzen desktop chips in late June 2026. The move matters less because TSME is a mass-market must-have than because it exposes how quietly platform security capabilities can appear, disappear, and reappear inside motherboard firmware. AMD did not merely tweak a performance setting; it briefly made a security-relevant feature vanish from consumer systems that some users had already built trust models around. ASUS’s patch is the first visible repair job, but the episode leaves a larger question hanging over the Ryzen ecosystem: who owns the security contract when firmware becomes the product?
Transparent Secure Memory Encryption is not the sort of feature that sells gaming PCs at retail. It does not raise frame rates, shorten compile times, or make a Cinebench chart look heroic. It encrypts system memory with a key generated by the processor at boot, intended to reduce the value of data left in RAM if an attacker has physical access to a powered-off or abruptly powered-down machine.
That puts TSME in an awkward category: technically important, practically invisible, and easy for vendors to treat as optional until the wrong group of users notices. For most desktop owners, the risk of a cold-boot attack is remote compared with phishing, credential theft, browser compromise, or a bad driver update. For security researchers, journalists, developers carrying sensitive work, and administrators who think in threat models rather than marketing tiers, “remote” is not the same as “irrelevant.”
The controversy began when users found that newer AMD firmware no longer reported TSME support on some consumer Ryzen systems that had previously exposed the option. The affected path appears to run through AGESA, AMD’s motherboard firmware substrate, rather than through a Windows update or user-facing application. That distinction is important because AGESA changes arrive disguised as ordinary BIOS updates, often bundled with memory compatibility improvements, CPU support, USB fixes, stability work, and the ritual promise of “system performance” tuning.
This is why the backlash landed. A user can choose not to install a vendor utility. A user can delay a graphics driver. But motherboard firmware occupies a special layer of trust: opaque enough that most people cannot audit it, powerful enough to change platform behavior below the operating system, and essential enough that enthusiasts are frequently told to update it before troubleshooting anything else.
That beta label should not be ignored. Motherboard firmware is not like a browser extension, and beta BIOSes are not casual installs for machines that need to be boring. They can improve one subsystem while destabilizing another, especially on AM5, where memory training behavior, EXPO profiles, SoC voltage handling, and CPU support have all been recurring themes since the platform launched.
Still, ASUS’s timing is notable. AMD had said it would reinstate the option in an upcoming July BIOS release after community feedback. ASUS appears to have beaten the calendar by making a Patch A build available before July, at least for some boards. That does not mean every ASUS AM5 owner has the fix today, nor does it mean MSI, Gigabyte, ASRock, or Biostar will land equivalent updates at the same pace.
The rollout is therefore both reassuring and messy. Reassuring, because the reversal is real enough to have reached public motherboard support pages. Messy, because the fix is fragmented by vendor, chipset, board model, BIOS branch, and the user’s appetite for beta firmware. The security setting may be restored by AMD’s AGESA, but the experience is still mediated by motherboard vendors and their uneven release machinery.
AMD’s official framing has emphasized Ryzen PRO. The company describes AMD Memory Guard, its branding around TSME, as a hardware-based memory encryption technology available on supported Ryzen PRO desktop and mobile processors. That is a clean enterprise story: buy the business SKU, get the business security feature, and receive a predictable validation promise.
The trouble is that non-PRO Ryzen systems had exposed TSME before. Even if AMD never shouted from a keynote slide that consumer Ryzen buyers were entitled to it, users saw the option, enabled it, tested for it, and in some cases relied on it. Once a security capability exists in the field, removing it without clear notice is no longer just product segmentation. It becomes a behavioral change to deployed systems.
That is the line AMD crossed, or at least appeared to cross. If TSME was never intended to be supported on non-PRO Ryzen 9000 desktop processors, the company needed to say so before users discovered the disappearance as a regression. If it was intended to remain available, the company needed to explain how it vanished from a recent BIOS path. The absence of immediate clarity created the space in which the least flattering interpretation could thrive.
In the PC enthusiast world, silence is rarely read as discipline. It is read as concealment.
AGESA is not the whole BIOS, but it is the AMD-supplied foundation that board vendors integrate into their firmware. When AMD changes AGESA, motherboard makers package those changes into branded releases, often with their own fixes and interface changes layered on top. That makes accountability distributed by design: AMD supplies the core, ASUS or MSI ships the build, and the user experiences it as a board-specific BIOS version.
This layered model works reasonably well when the change is a new CPU stepping or improved DDR5 compatibility. It becomes harder to defend when a security capability moves in or out of support. Users do not care whether the disappearance came from AMD’s code, vendor integration, a policy flag, or a validation table. From the system owner’s perspective, the motherboard update changed the security posture of the machine.
That is why this episode should worry administrators even if they have no immediate use for TSME. Modern client security increasingly depends on firmware-level features: TPMs, measured boot, Secure Boot databases, virtualization-based security, IOMMU behavior, memory encryption, fTPM implementations, and platform attestation. When those pieces are governed by opaque release notes and vendor forum archaeology, the PC’s security foundation becomes harder to inventory than the software stack running above it.
Windows administrators can query BitLocker state, Defender configuration, and update compliance with mature tooling. Firmware capabilities remain a more uneven world. The TSME flare-up is a reminder that low-level features need the same change-control seriousness as operating-system security settings.
The problem is that the boundary between “consumer” and “professional” machines has collapsed in practice. A Ryzen 9 desktop on an ASUS X870E board may be a gaming rig, a software workstation, a video-editing box, a lab machine, or a security research platform. A non-PRO CPU does not mean non-serious use.
The AM5 platform especially invites this ambiguity. AMD sells high-core-count desktop CPUs to creators and developers who often use the same hardware for work that would once have sat on workstation-class gear. Motherboard vendors market premium consumer boards with server-adjacent language: robust power delivery, PCIe expansion, advanced networking, USB4, firmware flashback, debug tools, and security options scattered across UEFI menus.
So when a feature like TSME disappears, the affected audience is not just hobbyists angry about a checkbox. It includes people who bought into the idea that modern desktop platforms are flexible enough for professional work even when the SKU does not carry a PRO badge. AMD’s reversal suggests the company understood that distinction, even if belatedly.
The episode also exposes a weakness in the industry’s reliance on branding. “PRO” communicates a support tier, not necessarily a silicon boundary. If a non-PRO chip can expose TSME through one firmware branch and lose it through another, users will reasonably ask whether the difference is capability, validation, policy, or paperwork.
That dismissal goes too far. Security features are rarely justified by average-case behavior alone. Seatbelts matter even though most trips do not end in collisions; memory encryption matters because some environments do include physical-access risk, device seizure risk, hostile-border risk, insider risk, or lab scenarios where residual memory contents are a legitimate concern.
TSME is also appealing because it can be transparent. Unlike some protections that require an operating-system policy rollout, application changes, or user training, transparent memory encryption is meant to work below the OS once enabled. That does not make it magic, and it does not replace full-disk encryption or a sane suspend strategy. But it can reduce one class of exposure without requiring every application to become security-aware.
For Windows users, the interaction is especially interesting because Microsoft has spent years pushing more of the client-security story into hardware-backed features. Windows 11’s TPM requirement, virtualization-based security, HVCI, Secured-core PC ideas, and BitLocker defaults all reflect a direction of travel: the OS wants a more trustworthy platform underneath it. If that platform changes silently, Windows can only inherit the uncertainty.
The better view is not that every Ryzen gamer needs TSME. It is that a platform vendor should not quietly remove a security-relevant capability from systems where it was already visible and functional, then rely on enthusiasts to discover and litigate the change.
That is why ASUS explicitly mentioning the restoration of Transparent Secure Memory Encryption matters. It turns a murky controversy into a trackable firmware event. It gives users something to look for on their own board’s support page and gives administrators a phrase to add to internal change records.
But it also highlights how inadequate the normal BIOS communication model is. If a firmware update removes a security option, the release note should say so. If a later update restores it, the note should identify the affected feature, the affected processors where possible, and any limitations. If the feature is not officially validated outside PRO SKUs, that should be written plainly rather than discovered through contradictory support replies.
The PC industry has treated firmware release notes as if they are favors to enthusiasts rather than operational documents for deployed machines. That approach is increasingly untenable. A desktop motherboard can now host hardware roots of trust, firmware TPMs, PCIe 5.0 storage, multiple boot paths, USB4 controllers, Wi-Fi modules, and security settings that interact with Windows policy. The release note is no longer a courtesy; it is part of the security record.
ASUS deserves credit for moving quickly, but the broader ecosystem still looks ad hoc. Users should not have to follow social media posts, GitHub threads, Reddit comments, and regional support pages to understand whether a security feature exists on their machine.
Yet the reversal does not answer the most important process questions. Why did the option disappear in the first place? Was the removal intentional, accidental, or the byproduct of narrowing validation? Why did users need to escalate publicly before the issue received a clear remedy? What internal test should have caught a security-relevant capability changing state between AGESA branches?
Those questions matter because the next feature may not attract the same attention. TSME had a name, a visible BIOS option, and a technically literate user base that could test it. Other firmware-level behaviors are harder to observe. If the mechanism of accountability is “wait until an enthusiast notices,” then the system depends on luck.
AMD has had a strong run in desktop CPUs by giving enthusiasts what Intel spent years withholding: cores, platform longevity, competitive performance, and upgrade paths that made motherboards feel like investments rather than disposable sockets. That goodwill is real. But platform trust is not sustained by performance leadership alone.
Security features require a different contract. They demand predictability, disclosure, and a bias toward not surprising the user. If a capability must be removed, the reason should be stated. If it is unsupported, the boundary should be clear. If it is restored, the fix should be traceable across vendors rather than scattered through beta BIOS drops.
If you rely on the machine for daily work, the conservative path is to read your exact motherboard’s support page, confirm that the relevant BIOS explicitly mentions AGESA ComboAM5 PI 1.3.0.1b Patch A or TSME restoration, and check community feedback for your board before flashing. Do not assume that one ASUS X870E model’s experience applies cleanly to another. AM5 BIOS behavior has varied too much across boards and memory kits for that kind of optimism.
Anyone who does update should treat the process like a real maintenance window. Back up important data, record existing UEFI settings, be ready to reconfigure EXPO or memory timings, and avoid flashing from an unstable overclock. BIOS FlashBack features make recovery less terrifying than it used to be, but they do not turn firmware updates into casual housekeeping.
For administrators, the practical task is inventory. Identify which systems use non-PRO Ryzen 9000 CPUs, which motherboards they sit on, which BIOS versions they run, and whether TSME is expected as a control. Then decide whether the beta fix is worth the operational risk or whether a final vendor build should be the baseline.
The worst response is to treat the patch as a generic “latest BIOS is best BIOS” moment. The entire controversy began because a routine firmware update changed a security feature in a way users did not expect. The lesson is not to stop updating firmware. The lesson is to update it with the same discipline you would apply to a security-sensitive OS change.
AMD’s Firmware Toggle Became a Trust Problem
Transparent Secure Memory Encryption is not the sort of feature that sells gaming PCs at retail. It does not raise frame rates, shorten compile times, or make a Cinebench chart look heroic. It encrypts system memory with a key generated by the processor at boot, intended to reduce the value of data left in RAM if an attacker has physical access to a powered-off or abruptly powered-down machine.That puts TSME in an awkward category: technically important, practically invisible, and easy for vendors to treat as optional until the wrong group of users notices. For most desktop owners, the risk of a cold-boot attack is remote compared with phishing, credential theft, browser compromise, or a bad driver update. For security researchers, journalists, developers carrying sensitive work, and administrators who think in threat models rather than marketing tiers, “remote” is not the same as “irrelevant.”
The controversy began when users found that newer AMD firmware no longer reported TSME support on some consumer Ryzen systems that had previously exposed the option. The affected path appears to run through AGESA, AMD’s motherboard firmware substrate, rather than through a Windows update or user-facing application. That distinction is important because AGESA changes arrive disguised as ordinary BIOS updates, often bundled with memory compatibility improvements, CPU support, USB fixes, stability work, and the ritual promise of “system performance” tuning.
This is why the backlash landed. A user can choose not to install a vendor utility. A user can delay a graphics driver. But motherboard firmware occupies a special layer of trust: opaque enough that most people cannot audit it, powerful enough to change platform behavior below the operating system, and essential enough that enthusiasts are frequently told to update it before troubleshooting anything else.
ASUS Moves First, But the Repair Is Still a Beta
ASUS’s new BIOS release notes for at least some X870 and X870E boards point to AGESA ComboAM5 PI 1.3.0.1b Patch A and state that the update restores Transparent Secure Memory Encryption. The early public example being discussed in the enthusiast press is BIOS 2401 for ASUS’s 800-series AM5 boards, listed as a beta BIOS rather than a final release.That beta label should not be ignored. Motherboard firmware is not like a browser extension, and beta BIOSes are not casual installs for machines that need to be boring. They can improve one subsystem while destabilizing another, especially on AM5, where memory training behavior, EXPO profiles, SoC voltage handling, and CPU support have all been recurring themes since the platform launched.
Still, ASUS’s timing is notable. AMD had said it would reinstate the option in an upcoming July BIOS release after community feedback. ASUS appears to have beaten the calendar by making a Patch A build available before July, at least for some boards. That does not mean every ASUS AM5 owner has the fix today, nor does it mean MSI, Gigabyte, ASRock, or Biostar will land equivalent updates at the same pace.
The rollout is therefore both reassuring and messy. Reassuring, because the reversal is real enough to have reached public motherboard support pages. Messy, because the fix is fragmented by vendor, chipset, board model, BIOS branch, and the user’s appetite for beta firmware. The security setting may be restored by AMD’s AGESA, but the experience is still mediated by motherboard vendors and their uneven release machinery.
The Feature Was Niche Until It Disappeared
One reason this story has traveled so quickly through the enthusiast ecosystem is that TSME sits at the intersection of two old PC anxieties. The first is the suspicion that vendors use firmware to segment products after sale. The second is the fear that consumer hardware contains capabilities that are enabled or disabled for business reasons rather than technical ones.AMD’s official framing has emphasized Ryzen PRO. The company describes AMD Memory Guard, its branding around TSME, as a hardware-based memory encryption technology available on supported Ryzen PRO desktop and mobile processors. That is a clean enterprise story: buy the business SKU, get the business security feature, and receive a predictable validation promise.
The trouble is that non-PRO Ryzen systems had exposed TSME before. Even if AMD never shouted from a keynote slide that consumer Ryzen buyers were entitled to it, users saw the option, enabled it, tested for it, and in some cases relied on it. Once a security capability exists in the field, removing it without clear notice is no longer just product segmentation. It becomes a behavioral change to deployed systems.
That is the line AMD crossed, or at least appeared to cross. If TSME was never intended to be supported on non-PRO Ryzen 9000 desktop processors, the company needed to say so before users discovered the disappearance as a regression. If it was intended to remain available, the company needed to explain how it vanished from a recent BIOS path. The absence of immediate clarity created the space in which the least flattering interpretation could thrive.
In the PC enthusiast world, silence is rarely read as discipline. It is read as concealment.
AGESA Is the Hidden Operating System of the Motherboard
The average Windows user thinks of BIOS updates as a grim utility screen and a progress bar that must not be interrupted. Enthusiasts know better. AGESA updates can alter boot behavior, memory compatibility, CPU boost behavior, voltage defaults, peripheral quirks, and now the visibility of a security feature.AGESA is not the whole BIOS, but it is the AMD-supplied foundation that board vendors integrate into their firmware. When AMD changes AGESA, motherboard makers package those changes into branded releases, often with their own fixes and interface changes layered on top. That makes accountability distributed by design: AMD supplies the core, ASUS or MSI ships the build, and the user experiences it as a board-specific BIOS version.
This layered model works reasonably well when the change is a new CPU stepping or improved DDR5 compatibility. It becomes harder to defend when a security capability moves in or out of support. Users do not care whether the disappearance came from AMD’s code, vendor integration, a policy flag, or a validation table. From the system owner’s perspective, the motherboard update changed the security posture of the machine.
That is why this episode should worry administrators even if they have no immediate use for TSME. Modern client security increasingly depends on firmware-level features: TPMs, measured boot, Secure Boot databases, virtualization-based security, IOMMU behavior, memory encryption, fTPM implementations, and platform attestation. When those pieces are governed by opaque release notes and vendor forum archaeology, the PC’s security foundation becomes harder to inventory than the software stack running above it.
Windows administrators can query BitLocker state, Defender configuration, and update compliance with mature tooling. Firmware capabilities remain a more uneven world. The TSME flare-up is a reminder that low-level features need the same change-control seriousness as operating-system security settings.
Consumer Ryzen Owners Got an Enterprise Lesson
AMD’s apparent initial distinction between PRO and non-PRO chips is understandable from a product-management standpoint. Enterprise buyers pay for manageability, validation, long-tail support promises, and predictable security features. Consumer desktop buyers pay for performance, platform features, and upgrade flexibility, but they do not usually get the same contractual clarity.The problem is that the boundary between “consumer” and “professional” machines has collapsed in practice. A Ryzen 9 desktop on an ASUS X870E board may be a gaming rig, a software workstation, a video-editing box, a lab machine, or a security research platform. A non-PRO CPU does not mean non-serious use.
The AM5 platform especially invites this ambiguity. AMD sells high-core-count desktop CPUs to creators and developers who often use the same hardware for work that would once have sat on workstation-class gear. Motherboard vendors market premium consumer boards with server-adjacent language: robust power delivery, PCIe expansion, advanced networking, USB4, firmware flashback, debug tools, and security options scattered across UEFI menus.
So when a feature like TSME disappears, the affected audience is not just hobbyists angry about a checkbox. It includes people who bought into the idea that modern desktop platforms are flexible enough for professional work even when the SKU does not carry a PRO badge. AMD’s reversal suggests the company understood that distinction, even if belatedly.
The episode also exposes a weakness in the industry’s reliance on branding. “PRO” communicates a support tier, not necessarily a silicon boundary. If a non-PRO chip can expose TSME through one firmware branch and lose it through another, users will reasonably ask whether the difference is capability, validation, policy, or paperwork.
Cold-Boot Attacks Are Rare, But Security Is Built From Rare Cases
It is tempting to dismiss the entire controversy because cold-boot attacks are specialized. They require physical access, timing, technical skill, and a target worth the effort. Most users should spend more energy on full-disk encryption, passkeys, patch hygiene, password managers, and not installing dubious utilities from motherboard vendors’ download pages.That dismissal goes too far. Security features are rarely justified by average-case behavior alone. Seatbelts matter even though most trips do not end in collisions; memory encryption matters because some environments do include physical-access risk, device seizure risk, hostile-border risk, insider risk, or lab scenarios where residual memory contents are a legitimate concern.
TSME is also appealing because it can be transparent. Unlike some protections that require an operating-system policy rollout, application changes, or user training, transparent memory encryption is meant to work below the OS once enabled. That does not make it magic, and it does not replace full-disk encryption or a sane suspend strategy. But it can reduce one class of exposure without requiring every application to become security-aware.
For Windows users, the interaction is especially interesting because Microsoft has spent years pushing more of the client-security story into hardware-backed features. Windows 11’s TPM requirement, virtualization-based security, HVCI, Secured-core PC ideas, and BitLocker defaults all reflect a direction of travel: the OS wants a more trustworthy platform underneath it. If that platform changes silently, Windows can only inherit the uncertainty.
The better view is not that every Ryzen gamer needs TSME. It is that a platform vendor should not quietly remove a security-relevant capability from systems where it was already visible and functional, then rely on enthusiasts to discover and litigate the change.
The BIOS Release Note Has Become a Legal Brief in Miniature
Motherboard release notes have never been great literature. They are terse, repetitive, and often vague to the point of parody: improve system stability, enhance compatibility, update AGESA, support new CPUs. Yet for power users and IT shops, those notes are sometimes the only public record of what changed below the operating system.That is why ASUS explicitly mentioning the restoration of Transparent Secure Memory Encryption matters. It turns a murky controversy into a trackable firmware event. It gives users something to look for on their own board’s support page and gives administrators a phrase to add to internal change records.
But it also highlights how inadequate the normal BIOS communication model is. If a firmware update removes a security option, the release note should say so. If a later update restores it, the note should identify the affected feature, the affected processors where possible, and any limitations. If the feature is not officially validated outside PRO SKUs, that should be written plainly rather than discovered through contradictory support replies.
The PC industry has treated firmware release notes as if they are favors to enthusiasts rather than operational documents for deployed machines. That approach is increasingly untenable. A desktop motherboard can now host hardware roots of trust, firmware TPMs, PCIe 5.0 storage, multiple boot paths, USB4 controllers, Wi-Fi modules, and security settings that interact with Windows policy. The release note is no longer a courtesy; it is part of the security record.
ASUS deserves credit for moving quickly, but the broader ecosystem still looks ad hoc. Users should not have to follow social media posts, GitHub threads, Reddit comments, and regional support pages to understand whether a security feature exists on their machine.
The Patch Does Not Erase the Governance Failure
AMD’s decision to reinstate TSME for certain non-PRO Ryzen 9000 desktop processors is the right practical outcome. It restores expected behavior for users who had already seen the option, and it dampens the suspicion that the company was using firmware to retroactively enforce product segmentation. It also gives board vendors a clear path to ship corrected builds.Yet the reversal does not answer the most important process questions. Why did the option disappear in the first place? Was the removal intentional, accidental, or the byproduct of narrowing validation? Why did users need to escalate publicly before the issue received a clear remedy? What internal test should have caught a security-relevant capability changing state between AGESA branches?
Those questions matter because the next feature may not attract the same attention. TSME had a name, a visible BIOS option, and a technically literate user base that could test it. Other firmware-level behaviors are harder to observe. If the mechanism of accountability is “wait until an enthusiast notices,” then the system depends on luck.
AMD has had a strong run in desktop CPUs by giving enthusiasts what Intel spent years withholding: cores, platform longevity, competitive performance, and upgrade paths that made motherboards feel like investments rather than disposable sockets. That goodwill is real. But platform trust is not sustained by performance leadership alone.
Security features require a different contract. They demand predictability, disclosure, and a bias toward not surprising the user. If a capability must be removed, the reason should be stated. If it is unsupported, the boundary should be clear. If it is restored, the fix should be traceable across vendors rather than scattered through beta BIOS drops.
The Sensible Upgrade Path Is Annoyingly Conservative
For ASUS owners affected by the TSME removal, the arrival of a beta BIOS creates a familiar enthusiast dilemma. Flash now and regain the feature, or wait for a final release and avoid becoming an unpaid firmware tester. The answer depends on whether TSME is part of your actual risk model or merely a feature you dislike losing on principle.If you rely on the machine for daily work, the conservative path is to read your exact motherboard’s support page, confirm that the relevant BIOS explicitly mentions AGESA ComboAM5 PI 1.3.0.1b Patch A or TSME restoration, and check community feedback for your board before flashing. Do not assume that one ASUS X870E model’s experience applies cleanly to another. AM5 BIOS behavior has varied too much across boards and memory kits for that kind of optimism.
Anyone who does update should treat the process like a real maintenance window. Back up important data, record existing UEFI settings, be ready to reconfigure EXPO or memory timings, and avoid flashing from an unstable overclock. BIOS FlashBack features make recovery less terrifying than it used to be, but they do not turn firmware updates into casual housekeeping.
For administrators, the practical task is inventory. Identify which systems use non-PRO Ryzen 9000 CPUs, which motherboards they sit on, which BIOS versions they run, and whether TSME is expected as a control. Then decide whether the beta fix is worth the operational risk or whether a final vendor build should be the baseline.
The worst response is to treat the patch as a generic “latest BIOS is best BIOS” moment. The entire controversy began because a routine firmware update changed a security feature in a way users did not expect. The lesson is not to stop updating firmware. The lesson is to update it with the same discipline you would apply to a security-sensitive OS change.
The ASUS Patch Leaves a Paper Trail Every Ryzen Owner Should Read
The concrete message from this episode is narrower than the outrage around it, but more durable. ASUS has started restoring TSME through new AM5 BIOS builds, AMD has backed away from leaving the option absent on certain non-PRO Ryzen 9000 desktops, and the rest of the motherboard ecosystem now has pressure to follow. The larger lesson is that firmware release notes deserve more attention than most users give them.- ASUS’s early BIOS builds based on AGESA ComboAM5 PI 1.3.0.1b Patch A indicate that TSME restoration is moving from promise to shipping firmware.
- The affected systems appear to be certain non-PRO Ryzen 9000 desktop configurations that lost the visible TSME option or support state after newer AGESA-based BIOS updates.
- Ryzen PRO systems remain AMD’s officially emphasized home for Memory Guard, but the consumer-platform reversal shows that previously exposed capabilities create user expectations.
- A beta BIOS may restore the feature before a final release, but it can also introduce platform quirks that matter more than TSME for users who do not face physical-access threats.
- The safest operational response is to track exact motherboard models, exact BIOS versions, and exact release notes rather than relying on chipset names or social media shorthand.
- The industry needs clearer disclosure when firmware updates add, remove, or restore security-relevant platform features.
References
- Primary source: Wccftech
Published: 2026-06-25T12:26:29.126742
ASUS Quietly Rolls Out New BIOS Patch That Restores TSME On Consumer Ryzen Chips
ASUS restores TSME support on consumer Ryzen CPUs with BIOS update 2401 for AGESA 1.3.0.1b after AMD's earlier removal amid user backlashwccftech.com
- Related coverage: tomshardware.com
AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July — TSME is coming back after 'valuable community feedback' | Tom's Hardware
The feature was quietly removed through a firmware update on some non-PRO Ryzen CPUs.www.tomshardware.com - Related coverage: asus.com
ROG CROSSHAIR X870E HERO - Support
www.asus.com
- Related coverage: pausehardware.com
EXPO ULL Sur Les ASUS ROG Crosshair X870E En AGESA 1.3.0.1b
EXPO ULL arrive sur les ASUS ROG Crosshair X870E avec des BIOS bêta AGESA 1.3.0.1b : timings DRAM ajoutés et support DDR5 20TH dès juin 2026.pausehardware.com - Related coverage: videocardz.com
- Related coverage: techspot.com
AMD quietly disabled RAM encryption on some Ryzen CPUs and users want to know why | TechSpot
Update (June 19): AMD has contacted us and offered an official response to this, confirming that the Memory Guard (TSME) option was intentionally removed from certain non-Pro...www.techspot.com
- Related coverage: tomshw.it
- Related coverage: techtimes.com
AMD Reverses Ryzen Memory Encryption Removal: July BIOS Update to Restore TSME
AMD memory encryption is returning to consumer Ryzen 9000 desktop chips after the company reversed a silent AGESA 1.2.7.0 firmware change that stripped TSME without notice. A July 2026 BIOS updatewww.techtimes.com - Related coverage: dlcdnets.asus.com.cn
- Related coverage: dlcdnets.asus.com