DEF CON 34 — Part 10 of 13

What CPU, memory, firmware and BMC research means for cyber resilience

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For most security teams, a compromised server has a familiar lifecycle.

Detect the intrusion.

Contain the system.

Investigate the attacker.

Rotate credentials.

Reimage the host.

Restore applications and data.

Return the system to production.

There is an assumption buried inside that sequence:

Rebuilding the operating system restores trust.

DEF CON 34 offered a useful reminder of why that assumption is increasingly dangerous.

Some of the most consequential security boundaries in modern computing exist below the operating system — inside memory controllers, CPU security processors, System Management Mode, microcode, firmware and Baseboard Management Controllers.

These components rarely appear prominently in SOC dashboards.

EDR may not see them.

SIEM telemetry may barely describe them.

Application scanners do not inspect them.

Cloud security tools often abstract them away entirely.

Yet they sit underneath almost everything those security controls depend upon.

That produces an uncomfortable inversion of the traditional security stack:

The layers we monitor most closely may depend on layers we understand least.

And once an attacker crosses into those deeper layers, incident response has a fundamentally different problem.

The question is no longer simply:

Is the malware gone?

It becomes:

Can we still trust the machine?

Security has become top-heavy

Enterprise cybersecurity has spent the last decade building extraordinary visibility into the upper layers of computing.

We monitor:

applications
containers
operating systems
endpoints
identities
networks
cloud control planes
APIs
SaaS environments.

A modern EDR platform may observe process creation, memory behavior, registry modification, network connections, credential access and persistence mechanisms.

But underneath that monitored environment exists another computing system.

In simplified form:

Application
↓
Operating System
↓
Hypervisor
↓
System Firmware
↓
SMM / Security Processor
↓
Microcode
↓
Memory Controller
↓
Hardware

Alongside it sits another highly privileged environment:

Baseboard Management Controller

The BMC can often manage the server independently of the operating system.

It may power systems on and off.

Mount remote media.

Access consoles.

Update firmware.

Monitor hardware.

And communicate over a management network even when the operating system is unavailable.

From an operational perspective, this is extremely useful.

From an attacker perspective, it is extraordinary.

Skitter and the illusion of hardware boundaries

One of the more revealing hardware-security discussions surrounding DEF CON 34 involved Christopher Domas’ research into older AMD processor families, commonly referred to as Skitter.

The research concerned AMD Family 15h and 16h processors from roughly the 2011–2015 generation.

At its center was an obscure memory-controller configuration called BankSwizzleMode.

Manipulating that mechanism could change how physical addresses were mapped to DRAM.

That sounds esoteric.

Its security implications were not.

The research demonstrated that manipulating this low-level memory behavior could expose memory regions that software above the hardware layer assumed were inaccessible.

Those regions included extraordinarily sensitive environments such as:

• the AMD Platform Security Processor,
• System Management Mode,
• and microcode patch memory.

The attack required privileged access to the host first. It was therefore not a magical remote compromise of the processor.

But that misses the important architectural lesson.

The attacker could potentially turn:

kernel compromise

into:

memory-controller manipulation

into:

access to supposedly isolated hardware trust domains.

Recent reporting on the research describes how manipulating the memory interleaving configuration could expose PSP, SMM and microcode-related regions on affected legacy AMD processors. (⁠Tom’s Hardware)

That is compositional security at perhaps its most literal.

The operating system trusts the processor.

The processor trusts memory isolation.

Security mechanisms trust privileged execution environments.

But if the relationship between physical addressing and those protected regions can be manipulated, the security assumptions above them begin to collapse.

The vulnerability is not merely a vulnerable instruction.

It is a broken assumption about where trust boundaries actually exist.

Below Ring 0

Security professionals traditionally describe privilege using CPU rings.

Applications operate in less privileged rings.

The kernel operates at Ring 0.

Attackers obtaining kernel execution therefore appear to have reached the bottom.

They have not.

Modern computers contain several execution environments that sit conceptually underneath or beside the operating system.

One is System Management Mode — SMM.

SMM was designed for low-level platform management operations. It executes in a highly privileged environment isolated from the normal operating system.

Another is the processor’s security subsystem.

AMD platforms, for example, contain the Platform Security Processor, now generally referred to as the AMD Secure Processor.

Then there is microcode.

And firmware.

And hardware management controllers.

The result is not a simple privilege hierarchy.

It looks more like overlapping sovereign environments:

User Space
↓
Kernel
↓
Hypervisor
↓
Firmware
↙︎                 ↘︎
SMM         Security Processor
↓
Hardware / Microcode

with the BMC operating alongside much of that stack.

This matters because our defensive architecture is usually concentrated near the top.

An EDR agent running inside the operating system may have exceptional visibility into that operating system.

But it does not automatically possess authoritative visibility into every environment beneath it.

The security sensor itself depends upon the integrity of the platform reporting reality to it.

The BMC problem

Baseboard Management Controllers illustrate the problem especially clearly.

BMCs exist because administrators need to control servers when the servers themselves are unavailable.

That means the BMC must remain operational precisely when the operating system is not.

A typical BMC can provide functions such as:

remote console access,

power management,

hardware monitoring,

firmware updates,

virtual media,

boot configuration,

and remote administration.

In other words:

the management controller exists outside the normal security perimeter of the operating system while possessing extraordinary control over it.

That makes BMC security strategically important.

It also makes BMC compromise potentially persistent.

Earlier DEF CON research demonstrated how vulnerabilities in AMI MegaRAC BMC environments could be chained toward highly privileged compromise and persistent firmware implants. (⁠forum.defcon.org)

And this is not merely historical hardware-hacking trivia.

In July 2026, Supermicro disclosed CVE-2026-3821 affecting selected BMC firmware, describing an arbitrary-code-execution issue in SMASH services with a CVSS score of 8.8. The vendor requires affected systems to receive updated BMC firmware. (⁠Supermicro)

Earlier in 2026, Supermicro also disclosed BMC firmware authentication weaknesses, CVE-2025-12006 and CVE-2025-12007, that could allow specially crafted system firmware images under the documented attack conditions. (⁠Supermicro)

The CISO implication is straightforward:

The management plane underneath the operating system is part of the enterprise attack surface.

Yet many organizations do not inventory it with anything approaching the rigor applied to operating systems.

Ask a security organization:

Which Windows versions are running in our data centers?

There is usually an answer.

Ask:

Which BMC firmware versions are running across every physical server?

The answer may be considerably less certain.

The forgotten infrastructure problem

This becomes particularly dangerous in long-lived infrastructure.

Modern hyperscale environments replace hardware relatively quickly.

Many enterprises do not.

Hardware can remain operational for ten years or longer in:

manufacturing,

building management,

telecommunications,

laboratories,

network appliances,

storage systems,

industrial environments,

medical systems,

and specialized infrastructure.

The Skitter research is important partly for precisely this reason.

The affected AMD processor generations are old.

AMD no longer supports those processors.

That might suggest the issue is irrelevant.

But security support lifetime and operational lifetime are not the same thing.

A processor can disappear from a vendor’s supported product portfolio while remaining embedded inside operational infrastructure for years.

That creates a growing category of risk:

Hardware Technical Debt.

Organizations already understand software technical debt.

They need to understand hardware security debt with the same seriousness.

When “unsupported” becomes a security architecture decision

An unsupported operating system is normally visible.

Security scanners identify it.

Asset management platforms flag it.

Auditors ask about it.

An unsupported processor or embedded controller may receive much less attention.

Yet once security research discovers architectural weaknesses in such hardware, remediation options can be dramatically narrower.

Software vulnerabilities often produce this response:

Patch.

Firmware vulnerabilities may produce:

Update firmware.

Hardware vulnerabilities can eventually produce:

Replace the platform.

That is an entirely different risk-management problem.

A server replacement might involve procurement, application migration, compatibility testing, downtime and capital expenditure.

An industrial controller may be considerably harder.

An appliance might contain hardware that the enterprise does not even know is present.

And specialized systems may depend on vendor-certified configurations that cannot simply be replaced.

This is why hardware lifecycle management must become part of cyber-resilience planning rather than merely infrastructure management.

The recovery model is incomplete

Traditional incident-response thinking frequently assumes a trusted recovery layer.

If the application is compromised, rebuild the application.

If the operating system is compromised, reimage the operating system.

If credentials are compromised, rotate credentials.

But each recovery action depends on something underneath it remaining trustworthy.

Consider the hierarchy:

Application compromised
→ reinstall application.
OS compromised
→ reimage OS.
Hypervisor compromised
→ rebuild hypervisor.
Firmware compromised
→ reflash or replace firmware.
BMC compromised
→ independently recover the management controller.
Hardware trust mechanism compromised
→ potentially replace hardware.

This produces a fundamental principle:

Recovery ends only when the lowest compromised trust layer has been restored.

That sounds obvious.

Operationally, it changes incident response significantly.

Reimaging is not necessarily eradication

Imagine an attacker compromises a server.

The SOC detects malicious activity.

The machine is isolated.

Forensics identify malware.

Credentials are rotated.

The server is rebuilt from a known-good image.

EDR is redeployed.

The machine returns to service.

From the SOC’s perspective:

incident closed.

But suppose the attacker had previously obtained sufficient privilege to compromise the BMC or modify firmware.

The rebuilt operating system may now be running above attacker-controlled infrastructure.

The recovery process has restored software.

It has not restored trust.

The sequence becomes:

Compromise
↓
Privilege escalation
↓
Sub-OS compromise
↓
OS reimage
↓
Attacker remains below OS
↓
System declared clean

That is one of the most dangerous incident-response failure modes because the recovery action itself creates confidence.

The organization believes it has returned to a known-good state.

It has not.

EDR has an epistemological boundary

This raises a deeper problem for defensive architecture.

Every security sensor has a point beyond which it cannot independently establish truth.

An EDR sensor sees the world through the operating system.

A hypervisor security tool sees another layer.

Firmware integrity systems inspect another.

Hardware attestation mechanisms establish other properties.

None provides omniscience.

This means security architecture needs to ask not only:

What does this control detect?

but also:

What must already be trustworthy for this control’s evidence to be trustworthy?

That question is rarely included in control catalogs.

It should be.

Because every security control has a trust dependency.

EDR trusts the execution environment.

The operating system trusts firmware.

Secure Boot trusts signing infrastructure and platform keys.

Attestation trusts hardware roots of trust.

Remote management trusts the BMC.

And eventually the chain reaches silicon.

This is the same compositional problem that appears throughout this DEF CON 34 series.

Only here the composition runs vertically through the computing stack.

Attestation therefore becomes more important

Hardware-rooted security mechanisms increasingly matter because they can provide evidence about system state from outside the ordinary operating-system trust boundary.

Secure Boot.

Measured Boot.

TPM-backed measurements.

Firmware integrity monitoring.

Remote attestation.

Cryptographically verified firmware.

These technologies should not be treated as obscure infrastructure features.

They answer an increasingly important security question:

What evidence do we have that the machine started from a trustworthy state?

But attestation itself must not become another checkbox.

A TPM measurement that nobody collects is not a security control.

A Secure Boot configuration nobody monitors provides limited operational assurance.

Firmware measurements that never reach detection engineering do not help incident responders determine whether deeper compromise occurred.

The useful architecture is therefore:

Hardware Root of Trust
↓
Measured Platform State
↓
Attestation
↓
Security Analytics
↓
Policy Decision

For particularly sensitive infrastructure, unexpected platform measurements should potentially prevent workloads from starting at all.

Firmware needs vulnerability management too

Most vulnerability-management programs revolve around:

CVE
↓
Asset
↓
Severity
↓
Patch
↓
SLA

But firmware and hardware vulnerabilities complicate this model.

Organizations need to know more than:

Which software packages are installed?

They increasingly need:

CPU family and stepping,

BIOS/UEFI version,

BMC manufacturer,

BMC firmware version,

hardware security processor generation,

TPM version,

microcode revision,

firmware support status,

Secure Boot configuration,

hardware end-of-support date.

This transforms asset inventory.

The asset is no longer simply:

SERVER-4271

It becomes a stack of trust-bearing components.

A meaningful security inventory might conceptually look like:

Physical Server
├── CPU / Microcode
├── BIOS / UEFI
├── Secure Processor
├── TPM
├── BMC
├── NIC Firmware
├── Storage Firmware
├── Hypervisor
└── Operating System

Every layer potentially has:

a vendor,

a version,

a support lifecycle,

a vulnerability history,

an update mechanism,

and a recovery procedure.

That is considerably more complicated than traditional endpoint vulnerability management.

But it reflects the actual system.

Appliances may be the blind spot

The problem becomes even harder with appliances.

Organizations buy:

firewalls,

storage systems,

network appliances,

backup systems,

security appliances,

industrial gateways,

hyperconverged infrastructure,

and specialized equipment.

From the customer’s perspective these may appear to be single products.

Internally they are complex computers.

They contain processors.

Firmware.

BMCs.

Operating systems.

Open-source components.

Management interfaces.

Cryptographic libraries.

And sometimes hardware that has been unsupported by its original component manufacturer long before the appliance itself reaches end of life.

This creates a supply-chain visibility problem.

The enterprise may know:

Appliance model X.

It may not know:

CPU generation Y + BMC firmware Z + embedded library A + controller firmware B.

That is why software bills of materials alone will eventually be insufficient.

Cyber resilience increasingly requires something closer to a platform bill of materials.

Not merely:

What software is inside?

But:

What trust-bearing technology is this product built upon?

OT makes the problem more serious

Long-lived operational technology makes all of this particularly relevant.

IT infrastructure might be replaced every few years.

Industrial systems may operate for decades.

Replacing them can require:

plant downtime,

recertification,

safety validation,

vendor engineering,

capital projects,

or complete modernization programs.

This creates environments where the answer to:

Is the affected hardware still supported?

may be:

No.

While the answer to:

Can we replace it?

is also:

No.

That is where cybersecurity becomes resilience engineering.

Controls may need to shift toward:

network isolation,

strict management-plane segmentation,

allowlisting,

external monitoring,

physical controls,

compensating detection,

restricted administration,

and eventual architectural replacement.

Risk acceptance alone does not make unsupported hardware trustworthy.

It merely acknowledges that the organization has decided to continue operating it.

The management network should be Tier 0

One practical conclusion follows directly from BMC research.

Out-of-band management infrastructure deserves protection comparable to identity infrastructure.

Consider what resides there:

BMC interfaces,

IPMI,

Redfish,

hypervisor management,

storage controllers,

firmware-management platforms,

remote consoles,

power controls.

Compromise of these systems can undermine the infrastructure they manage.

Yet management networks sometimes receive less attention because they are considered “internal.”

That assumption should disappear.

A mature architecture should treat hardware-management infrastructure as Tier 0.

That means:

strong administrative isolation,

dedicated privileged identities,

phishing-resistant MFA where supported,

PAM/JIT administration,

restricted network paths,

comprehensive logging,

firmware lifecycle management,

and no casual access from ordinary administrator workstations.

The BMC is not merely another management interface.

It is an authority domain beneath the server.

Incident response needs a trust-depth decision

The most practical CISO change may be surprisingly simple.

Every significant infrastructure incident should include an explicit decision:

How deep could the attacker have gone?

For example:

Level 1 — Application

Was compromise confined to the application?

Level 2 — Operating System

Did the attacker obtain administrative or kernel privileges?

Level 3 — Hypervisor / Platform

Could virtualization infrastructure have been modified?

Level 4 — Firmware / BMC

Could firmware, UEFI or management controllers have been accessed?

Level 5 — Hardware Trust

Could hardware security mechanisms, microcode or platform trust anchors have been affected?

The required recovery action should follow the deepest credible compromise level.

This prevents a dangerous organizational shortcut:

rebuild what we normally rebuild.

Instead the question becomes:

rebuild what the attacker could have changed.

A new concept: Trust Depth

Throughout this series, the central argument has been that security teams must understand relationships.

Hardware security introduces another dimension.

Not merely attack-path length.

But Trust Depth.

Trust Depth describes how far downward an attacker has penetrated into the layers upon which higher-level security depends.

A ransomware operator running with user privileges has relatively shallow trust penetration.

Kernel compromise goes deeper.

Hypervisor compromise goes deeper still.

Firmware persistence crosses another boundary.

Compromise of hardware roots of trust potentially reaches the foundation.

Conceptually:

Application
│
OS
│
Hypervisor
│
Firmware
│
Security Processor / SMM
│
Microcode / Hardware
▼
Increasing Trust Depth

The deeper the attacker travels, the more expensive trustworthy recovery becomes.

That relationship should influence incident severity.

A firmware compromise affecting one server may deserve greater strategic attention than commodity malware affecting hundreds of endpoints.

Because severity is not only about the number of systems compromised.

It is also about how deeply their trust has been compromised.

The CISO questions

Hardware security does not mean CISOs need to become microcode researchers.

It means they need to ensure that somebody can answer the questions that hardware research makes unavoidable.

For critical infrastructure:

Do we know which processor generations we operate?

Do we know our BIOS and BMC firmware versions?

Are management controllers included in vulnerability management?

Are BMC networks isolated from ordinary administrative networks?

Can we verify Secure Boot and measured-boot state centrally?

Can the SOC consume platform-integrity telemetry?

Do incident-response procedures include firmware compromise?

Do forensic teams know how to investigate BMCs and firmware?

Do recovery plans distinguish OS rebuild from platform recovery?

Which critical systems contain unsupported hardware?

What is the replacement strategy when a vulnerability cannot be patched?

And perhaps most importantly:

What evidence would convince us that a compromised physical system is trustworthy again?

If there is no answer, the organization does not yet have a complete recovery strategy.

Cyber resilience begins below the operating system

The broader lesson from DEF CON 34 is not that every attacker will suddenly begin rewriting microcode.

Most will not.

Credential theft remains easier.

Phishing remains cheaper.

Cloud misconfiguration remains abundant.

Attackers usually choose the simplest path.

But security architecture cannot be designed solely around the most common attack.

It must understand what happens when an adversary reaches the foundations.

Because the foundations determine whether everything above them can still be trusted.

The traditional recovery model is:

Compromise
↓
Remove malware
↓
Reimage
↓
Restore
↓
Recover
The more complete model is:
Compromise
↓
Determine Trust Depth
↓
Identify lowest potentially affected layer
↓
Restore that layer
↓
Re-establish trust upward
↓
Attest
↓
Recover

That final distinction matters.

Restoration is not the same as recovery.

Restoration brings systems back.

Recovery brings trustworthy systems back.

And as DEF CON’s hardware research keeps reminding us, the difference may exist somewhere our EDR cannot see.

Core thesis

Recovery ends only when the lowest compromised trust layer has been restored.

For years, cybersecurity concentrated on what runs on our computers.

The next resilience challenge is understanding what our computers themselves are trusting.

Because below the endpoint agent, below the kernel and sometimes below the hypervisor lies another attack surface.

And if an attacker owns that layer, rebuilding everything above it may simply rebuild the attacker’s system for them.

Next in the series: Part 11 — When Cyber Attacks Leave the Computer — why cyber risk changes fundamentally when software controls physical reality, and how attacks can traverse IT, industrial protocols and controllers to reach physical processes—forcing CISOs to think beyond compromise toward consequence, resilience and safety.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.