Security in Memory January 28, 2026 Tamara Schmitz
Description: Security in Memory January 28, 2026 Tamara Schmitz Director of Product Security Executive Summary Memory has become a critical attack surface. Threat actors increasingly target runtime and firmware layers. Cost of attack is rapidly
Related Topics
Download Presentation
"Security in Memory January 28, 2026 Tamara Schmitz" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. Security in Memory January 28, 2026
Tamara Schmitz
Director of Product Security<br>
slide2. Executive Summary Memory has become a critical attack surface.
Threat actors increasingly target runtime and firmware layers.
Cost of attack is rapidly decreasing.
Standards and compliance lag technology shifts. 2<br>
slide3. Memory vs. Storage Memory (DRAM/HBM/CXL)
Volatile, ultra-fast
Holds data in use
Compromise enables runtime takeover
Hardware Storage (SSD/mNAND/NVMe)
Persistent, non-volatile
Holds data at rest
Compromise enables long-term tampering
Has both hardware and firmware<br>
slide4. Attack Surfaces Memory (DRAM/HBM/CXL)
Exposed debug/test interfaces
Rowhammer and bit-flip attacks
Cold-boot data extraction
Direct Memory Attacks via PCIe
Side-channel and fault injection Storage (SSD/NAND/NVMe)
Controller firmware
Wear-leveling/FTL manipulation
Supply-chain firmware tampering
Data remanence issues
Metadata leak exposure<br>
slide5. Mitigations Memory (DRAM/HBM/CXL)
Hardware Roots of Trust
Memory encryption & integrity
ECC (Error-Correcting Code)
Rowhammer mitigation
IOMMU (Input-Output Memory Management Unit) enforcement
PCIe/CXL security (ACS/ATS/SPDM) Storage (SSD/NAND/NVMe)
Debug interface lockdown
Signed authenticated firmware
Rollback protection (from incomplete or erroneous data modification)
Device identity + attestation
Secure update pipelines
Hardware-backed key storage
Ephemeral in-use keys
Proven secure erase for drives
Authenticated encryption
Development transparency (OCP Safe)
Third party audits<br>
slide6. Lifecycle & Supply Chain Risks Secure Development Lifecycle
Inadequate threat modeling
Weak secure-boot sequences
Insecure update channels
Poor key lifecycle management
Third party development
Attack development over lifetime
RMA / Decommissioning procedures
Support plans<br>
slide7. Supplier Requirements Threat models
SBOM + signed firmware
Security testing firmware
Regular fuzzing & penetration testing
Secure handling for RMA/decom
Coordination on incident response<br>
slide8. Problem: Shrinking Cost of Entry Cheap hardware attack tools
Cloud compute for brute-force & fuzzing
Open-source firmware analysis kits
AI-assisted exploit creation
Growth of hardware gray markets<br>
slide9. Standards & Compliance NIST
800-53 / 800-171 / CMMC
800-193 firmware resiliency
800-88 sanitization
IEC 62443 industrial automation/control systems
FIPS 140-3 crypto modules
ISO 21434 automotive/ ISO 26262 / ISO 27001/2
NIAP/Common Criteria
JEDEC
OCP SAFE
CVE/CVSS
CRA<br>
slide10. Standardization Gaps Mandatory device attestation
Rollback protections
Hardware considerations
Rowhammer testing requirements
Memory side-channel guidance
Variation among markets<br>
slide11. Improvement Enforce attestation before provisioning
Require SBOM + firmware signing
Expand memory/storage encryption adoption and erase procedures
Strengthen procurement controls
Continually expand internal hardware security evaluation
Expand incident response capability and coordination<br>
slide12. Next Steps Integrate security controls into compliance programs and procedures
Update acquisition and supplier contracts
Train teams/partners on memory-layer threat modeling
Expand incident response plans to include firmware and hardware attacks
Plan with agility in mind (threat intelligence)<br>
slide13. Tamara Schmitz
Director of Product Security
tschmitz@micron.com<br>
Tamara Schmitz
Director of Product Security<br>
slide2. Executive Summary Memory has become a critical attack surface.
Threat actors increasingly target runtime and firmware layers.
Cost of attack is rapidly decreasing.
Standards and compliance lag technology shifts. 2<br>
slide3. Memory vs. Storage Memory (DRAM/HBM/CXL)
Volatile, ultra-fast
Holds data in use
Compromise enables runtime takeover
Hardware Storage (SSD/mNAND/NVMe)
Persistent, non-volatile
Holds data at rest
Compromise enables long-term tampering
Has both hardware and firmware<br>
slide4. Attack Surfaces Memory (DRAM/HBM/CXL)
Exposed debug/test interfaces
Rowhammer and bit-flip attacks
Cold-boot data extraction
Direct Memory Attacks via PCIe
Side-channel and fault injection Storage (SSD/NAND/NVMe)
Controller firmware
Wear-leveling/FTL manipulation
Supply-chain firmware tampering
Data remanence issues
Metadata leak exposure<br>
slide5. Mitigations Memory (DRAM/HBM/CXL)
Hardware Roots of Trust
Memory encryption & integrity
ECC (Error-Correcting Code)
Rowhammer mitigation
IOMMU (Input-Output Memory Management Unit) enforcement
PCIe/CXL security (ACS/ATS/SPDM) Storage (SSD/NAND/NVMe)
Debug interface lockdown
Signed authenticated firmware
Rollback protection (from incomplete or erroneous data modification)
Device identity + attestation
Secure update pipelines
Hardware-backed key storage
Ephemeral in-use keys
Proven secure erase for drives
Authenticated encryption
Development transparency (OCP Safe)
Third party audits<br>
slide6. Lifecycle & Supply Chain Risks Secure Development Lifecycle
Inadequate threat modeling
Weak secure-boot sequences
Insecure update channels
Poor key lifecycle management
Third party development
Attack development over lifetime
RMA / Decommissioning procedures
Support plans<br>
slide7. Supplier Requirements Threat models
SBOM + signed firmware
Security testing firmware
Regular fuzzing & penetration testing
Secure handling for RMA/decom
Coordination on incident response<br>
slide8. Problem: Shrinking Cost of Entry Cheap hardware attack tools
Cloud compute for brute-force & fuzzing
Open-source firmware analysis kits
AI-assisted exploit creation
Growth of hardware gray markets<br>
slide9. Standards & Compliance NIST
800-53 / 800-171 / CMMC
800-193 firmware resiliency
800-88 sanitization
IEC 62443 industrial automation/control systems
FIPS 140-3 crypto modules
ISO 21434 automotive/ ISO 26262 / ISO 27001/2
NIAP/Common Criteria
JEDEC
OCP SAFE
CVE/CVSS
CRA<br>
slide10. Standardization Gaps Mandatory device attestation
Rollback protections
Hardware considerations
Rowhammer testing requirements
Memory side-channel guidance
Variation among markets<br>
slide11. Improvement Enforce attestation before provisioning
Require SBOM + firmware signing
Expand memory/storage encryption adoption and erase procedures
Strengthen procurement controls
Continually expand internal hardware security evaluation
Expand incident response capability and coordination<br>
slide12. Next Steps Integrate security controls into compliance programs and procedures
Update acquisition and supplier contracts
Train teams/partners on memory-layer threat modeling
Expand incident response plans to include firmware and hardware attacks
Plan with agility in mind (threat intelligence)<br>
slide13. Tamara Schmitz
Director of Product Security
tschmitz@micron.com<br>