AMD's Memory Encryption Blind Spot

AMD will re-enable Transparent Secure Memory Encryption on Ryzen 9000 desktop parts through an AGESA firmware and BIOS update shipping in July. TSME was disabled on early Zen 5 consumer platform firmware. The update restores DRAM-wide AES encryption, configured by the platform at boot, transparent to the operating system and every process above it. No driver. No OS opt-in. The memory controller encrypts on the write path and decrypts on the read path.

Strip the framing first. Memory encryption is a mitigation, not an attack vector. Reinstating it does not hand attackers a new primitive. What it changes is the cost and the visibility of one specific class of attack - physical and bus-level memory disclosure. That shift is the story, and most endpoint defenders run no telemetry that covers either side of it.

Secure Memory Encryption uses AES-128 in a XEX-style mode. The tweak is derived from the physical address. The key is generated inside the AMD Secure Processor - the on-die ARM core, formerly branded PSP - and is never exposed to x86 software. SME is the opt-in variant where software marks encrypted pages with the C-bit, an upper physical-address bit in the page table entry. TSME is the blunt version: every page encrypted, no software awareness required, set in firmware. AMD Memory Guard is the consumer brand name for TSME. That is the feature returning in July.

Consumer Ryzen gets TSME and nothing above it. The SEV family - Secure Encrypted Virtualization, SEV-ES for encrypted register state, SEV-SNP for Secure Nested Paging - is an EPYC server feature built to protect guest VMs from a hostile hypervisor. SEV-SNP is the only tier with hardware integrity, backed by the Reverse Map Table. Desktop parts do not ship it. The distinction defines exactly which attacks the July update can and cannot answer.

What TSME stops is precise. DRAM contents at rest in the physical modules are ciphertext. Pull power, freeze the DIMMs, reseat them in a reader - the cold boot attack, DRAM remanence, Halderman et al., 2008 - and the recovery yields ciphertext, not keys, not plaintext. A DMA agent on the PCIe or Thunderbolt bus that reads physical memory through a malicious device - the PCILeech, Thunderclap, and Inception class - sees ciphertext on a TSME system. The bus and the modules carry encrypted data. That is the entire protection envelope.

What TSME does not stop is larger than what it does. The CPU operates on plaintext. The memory controller decrypts before data reaches a core, so any code executing on that core - kernel, signed driver, administrator-context process - reads cleartext. TSME is invisible to software by design, which makes it irrelevant to every software-based memory attack. Dumping LSASS still yields plaintext credentials. Scraping a browser process for session tokens still works. A kernel read primitive against another process heap still returns cleartext. Memory encryption and credential theft from a running process are orthogonal. A machine with TSME enabled is exactly as exposed to T1003.001, OS Credential Dumping: LSASS Memory, as one without it.

This is where the common mapping is wrong and worth correcting. There is no ATT&CK technique numbered for memory disclosure, and T1059 is Command and Scripting Interpreter - nothing to do with DRAM contents. The techniques that actually touch this surface are T1003 and its sub-techniques for software credential access, and T1200, Hardware Additions, for the physical and interposer path. Physical DRAM attacks sit mostly outside ATT&CK Enterprise scope, which is itself the defensive problem. The framework does not describe the threat the control addresses.

The harder point is that TSME does not fully close even the physical vector. SME and TSME provide confidentiality only. No integrity. No freshness. The encryption is deterministic per physical address - identical plaintext at the same address produces identical ciphertext. An attacker who can observe or manipulate the memory bus can replay, relocate, or alias ciphertext without ever recovering the key. That is the structural gap between consumer SME and the SEV-SNP feature set, where the Reverse Map Table exists specifically to defeat aliasing and replay. On a Ryzen 9000 desktop there is no SNP-grade integrity structure to fall back on.

Recent research made the gap concrete. BadRAM, disclosed December 2024, manipulated DIMM SPD metadata so the controller addressed phantom memory, aliasing physical addresses and breaking SEV-SNP isolation. Battering RAM and WireTap, 2025, used low-cost DDR interposers - passive hardware on the memory bus - to defeat memory encryption across AMD SEV-SNP and Intel SGX and TDX, including extraction of attestation key material. The interposer does not break AES. It exploits the deterministic, unauthenticated encryption mode. TSME on a desktop part inherits the same mode and the same weakness, without even SNP integrity as a backstop.

The practical exposure for a desktop endpoint is therefore narrow but real. Physical access. Evil maid. A seized or stolen device. A hardware implant placed during a supply chain hop or a service window - T1200. For those cases TSME raises the bar from trivial - pull RAM, read plaintext - to lab-grade - interpose the bus, exploit the mode. Higher cost. Not impossible. For everything reachable by software, TSME changes nothing.

Score the physical attacks honestly. Any attack requiring bus interposition or DIMM manipulation carries CVSS Attack Vector Physical, AV:P. That caps the base score in the medium range regardless of confidentiality impact, because the access precondition is severe. A practitioner reading the vector string sees AV:P and correctly deprioritises it against an AV:N remote bug. The encryption-disabled window on early Ryzen 9000 firmware was a genuine exposure, but only against an attacker already holding the hardware.

Now the telemetry, because this is where defenders are actually blind. A cold boot attack produces no host telemetry - the machine is powered off. A bus interposer produces no host telemetry - it is passive hardware below the operating system. A DMA scrape through a malicious PCIe device produces nothing if Kernel DMA Protection and the IOMMU are not enforcing, and the scraped host is often not booted into a logging state. There is no Sysmon event for physical memory disclosure. No Windows Security event. No EDR alert category. The entire physical attack class is invisible to the endpoint stack SOC teams actually run.

What does fire is the software path TSME never touched. LSASS access surfaces in Sysmon Event ID 10, ProcessAccess, with GrantedAccess masks like 0x1010, 0x1410, or 0x1438 against lsass.exe. Handle requests appear in Windows Security 4656 and 4663. EDR flags the credential-theft behaviour directly. These are the events analysts see, and they have nothing to do with whether memory encryption is on or off. The risk is conflation. A control that defends against an invisible physical threat gets credited with software detections that were already firing for an unrelated reason.

The detection work TSME actually justifies sits below the OS. Firmware attestation that confirms TSME is enabled in the running configuration, not just set in setup. DRTM and measured boot logs. IOMMU and Kernel DMA Protection state, enforced and logged. SPD and memory configuration integrity checks at boot - the surface BadRAM abused. None of that lives in the SIEM today. It lives in TPM event logs, firmware, and platform attestation, and most endpoint programs do not collect any of it. The detection gap is not a missing rule. It is a missing data source.

The patch boundary is the July AGESA and the OEM BIOS releases carrying it. Before it, early Zen 5 desktop firmware shipped with TSME off, leaving DRAM in plaintext at the physical layer. After it, TSME restores confidentiality against passive physical disclosure - cold boot, naive DMA, stolen modules. What does not change post-patch is the rest. The CPU still reads plaintext, so software credential theft is unaffected. The encryption mode is still unauthenticated, so interposer and aliasing attacks in the BadRAM and Battering RAM class still apply, with no integrity tier on desktop to slow them. And the physical attack surface stays outside the telemetry endpoint defenders collect. The feature is worth enabling. It is not memory safety, and it closes no software attack path that mattered before July.

Two more mechanics matter for anyone modelling this. The DMA path and the encryption mode are separate problems with separate controls. TSME defends the data on the wire and in the modules. The IOMMU defends which device is allowed to issue the read at all. A malicious PCIe or Thunderbolt device performs arbitrary physical reads only where DMA remapping is absent or misconfigured. Kernel DMA Protection on Windows and equivalent IOMMU enforcement on Linux constrain a hot-plugged device to remapped, pre-authorised regions. TSME and the IOMMU are complementary. One returns ciphertext to an attacker who gets a read; the other denies the read. A device-disclosure program that enables one and ignores the other has covered half the path.

The encryption mode is the part most threat models get wrong. Determinism is the weakness, not the key length. Because the same plaintext at the same physical address produces the same ciphertext under SME and TSME, an interposer does not need to recover AES state to be useful. It can record ciphertext-to-plaintext correspondences over time, detect repeated structures, and move or replay known-good ciphertext into a target location. That is the primitive BadRAM and the DDR interposer work abused, and it is why SEV-SNP added integrity rather than just a longer key. None of that integrity machinery is present on a Ryzen 9000 desktop after July.

For detection engineering the takeaway is concrete. The events worth correlating for memory credential theft key on GrantedAccess and target image, not on encryption state - Sysmon Event ID 10 against lsass.exe with the read-and-clone masks, joined to the requesting process lineage and its signing status. That rule fires identically before and after the BIOS update. Separately, and this is the new work, the July rollout justifies a configuration-attestation baseline: collect the firmware-reported TSME state and IOMMU enforcement from each Ryzen 9000 host, alert on drift to disabled, and treat an unexpected flip as a physical-tamper indicator rather than a routine config change. That signal does not exist in most fleets, and it is the only one this update actually creates.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.