Researchers at KU Leuven, ETH Zurich, Durham University, and Google have shown that a device costing under $200 can bypass memory encryption in Intel TDX, Scalable SGX, and AMD SEV-SNP environments. The attack, called DDRop, exploits a fundamental flaw in scalable memory encryption: protecting large memory volumes sacrifices cryptographic freshness checks.
For cloud service providers under FedRAMP authorization or pursuing DoD Impact Level certifications, this alters the approach to physical security controls and confidential computing guarantees.
What Changed
Modern memory encryption hardware doesn't verify if data in protected memory is fresh. The DDRop device takes advantage of this by sitting between the processor and memory module, corrupting DDR5 commands to drop write operations silently. The protected VM continues computing on outdated data that still decrypts correctly, allowing attackers with physical access to inject malicious page-table entries, force VMs into debug mode, and extract private memory in plaintext.
Researchers achieved deterministic attacks in under two minutes without crashing the target system. They also demonstrated forged attestation reports that make compromised VMs appear trusted to remote users.
Key Findings
No software patch exists for the root vulnerability. Both Intel and AMD have stated the attack is outside their cloud computing threat model, with no mitigation planned. Intel is evaluating "additional architectural hardening options" and detection mechanisms, but proposed solutions like cache line versioning appear vulnerable to the same technique.
The scalability-security trade-off is now visible to customers. Early Intel SGX implementations supported only 128-256 MB of protected memory but maintained cryptographic freshness. Current designs protect larger memory volumes by sacrificing those freshness guarantees. This design choice has become a compliance conversation.
Physical access assumptions need reassessment. Cloud providers have long treated physical security as a foundational control. DDRop shows that physical access plus modest hardware expertise can compromise memory encryption that software-layer monitoring can't detect. The interposer operates at full DDR5 speed, unlike earlier passive attacks that required slowing the memory bus.
Attestation reports can be forged. The ability to generate trusted-looking attestation from compromised VMs undermines remote verification mechanisms. If your compliance posture depends on attestation as evidence of confidential computing integrity, you're relying on a control that DDRop can subvert.
The attack works across major TEE implementations. Intel TDX, Scalable SGX, and AMD SEV-SNP all share the vulnerable design pattern. This isn't a vendor-specific bug; it's an architectural limitation in how current-generation hardware handles encrypted memory at scale.
What This Means for Your Team
If you're operating under FedRAMP Moderate or High authorization, your system security plan likely documents confidential computing capabilities as compensating controls for multi-tenant environments. DDRop exposes a gap between what those controls claim to protect and what they actually protect against physical interposition.
NIST SP 800-53 Rev 5 controls PE-3 (Physical Access Control) and PE-6 (Monitoring Physical Access) take on different weight when a $200 device can compromise memory encryption. Your continuous monitoring plan needs to account for the fact that software-layer monitoring won't detect this class of attack.
For DoD contractors pursuing CMMC Level 2 or Level 3 certification, the implications touch CUI protection requirements in NIST SP 800-171 Rev 2. If you're relying on cloud provider representations about confidential computing to meet SC.3.177 (Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems), you need to verify what physical security controls protect the hardware layer.
The shared responsibility model just shifted. Cloud providers have consistently placed physical security on their side of the Customer Responsibility Matrix. DDRop suggests that physical security controls need more scrutiny during vendor assessments, particularly for workloads processing CUI or operating at Impact Level 4 or above.
Action Items by Priority
Immediate: Review your confidential computing dependencies. Identify which workloads rely on Intel TDX, Scalable SGX, or AMD SEV-SNP for isolation guarantees. Document where those guarantees appear in your security authorization package as compensating controls or as evidence supporting specific NIST 800-53 controls.
Within 30 days: Engage your cloud provider on physical security controls. Request documentation of data center physical access controls, hardware monitoring capabilities, and incident response procedures for physical intrusion. Ask specifically how they detect hardware interposition attacks. If you're operating under a FedRAMP authorized service, verify whether the provider's continuous monitoring plan addresses physical-layer attacks on memory encryption.
Within 60 days: Assess impact on your authorization boundary. Work with your authorizing official or Third-Party Assessment Organization to determine whether DDRop changes your risk posture for any controls marked as "Satisfied" based on confidential computing capabilities. This may require updating your risk assessment, system security plan, or continuous monitoring strategy.
Within 90 days: Evaluate alternative architectures for high-sensitivity workloads. For CUI or classified processing, consider whether workloads should migrate to dedicated hardware, GCC High environments with enhanced physical security, or architectures that don't depend on scalable memory encryption for isolation. The trade-off between multi-tenant efficiency and cryptographic freshness is now a documented risk.
Ongoing: Monitor vendor roadmaps for architectural changes. Intel's statement about evaluating "architectural hardening options" suggests future hardware generations may address the freshness problem. Track vendor security bulletins and update your technology refresh plans accordingly. Don't assume current-generation hardware will receive a patch.
