Breaking the Trust: Enforcing Firmware Integrity

Breaking the Trust: Updating Firmware Integrity

In our first blog, we introduced the concept of firmware integrity and why it matters. In our second blog, we examined threats and compromises to firmware integrity. In this blog, we focus on firmware attestation as a crucial part of firmware integrity, thus educating organizations what they need to do in order to update their firmware integrity program.

From Firmware Inventory to Firmware Attestation

While some enterprises still pay little attention to firmware security, those that do typically focus on firmware lifecycle management. Security and infrastructure teams maintain inventories across servers, storage appliances, network devices, GPUs, and accelerators to understand which firmware versions are deployed, whether vulnerable releases remain in production, and whether updates have been successfully installed.

Traditionally, obtaining this information is straightforward. Operating systems, Baseboard Management Controllers (BMCs), Redfish APIs, SMBIOS tables, and vendor management tools simply query the device and collect version information. These values are uploaded into centralized inventory platforms where they are compared against vulnerability databases and approved firmware baselines.

This operational visibility is essential for vulnerability management, but it doesn’t answer two more important question:

Has this firmware already been modified or compromised and how can I learn about that?

As firmware increasingly becomes an attack target, organizations need more than version tracking. They need cryptographic evidence that the firmware currently executing on the platform is genuine and untampered. This is where hardware-backed attestation using Security Protocol and Data Model (SPDM) fundamentally changes the trust model.

The Traditional Approach: Vulnerability Management

Most organizations today manage firmware similarly to software assets. Management platforms collect firmware version information through vendor-specific interfaces, SMBIOS data, BMCs queried via Redfish APIs, operating system drivers, or BMCs. These values are correlated with vulnerability intelligence to identify systems that require updates.

These practices are highly effective for:

• Identifying outdated firmware
• Detecting firmware vulnerable to publicly disclosed CVEs
• Planning firmware updates
• Demonstrating compliance
• Maintaining enterprise firmware inventories

A More Mature Approach: Firmware Analysis

Some vendors extend traditional firmware management by extracting firmware images from endpoints and performing offline integrity analysis. This typically includes extracting firmware binaries, computing cryptographic hashes, scanning for known malware, and comparing the results against trusted firmware baselines. More mature solutions further strengthen this process by applying static and dynamic analysis to detect hidden or previously unknown malicious functionality within firmware components before establishing their integrity.

Broken Trust Problem

The model we described above is very significant in a healthy and modern firmware integrity program, but it’s not enough. It assumes that the device is honestly reporting its own state. This assumption, however, becomes significantly weaker once the firmware itself becomes part of the attack surface.

Firmware executes below the operating system and often below endpoint security products. Modern attackers increasingly target components such as UEFI firmware and BMC firmware because compromising them enables persistence that survives operating system reinstalls and frequently bypasses traditional security tooling.

If one of these components is compromised, it may still report that everything is functioning normally. It can report a wrong firmware version and even a benign binary. A management server has no independent way to determine whether the firmware has been modified and unauthorized code has been injected. Therefore, the measurements presented by the host could have been altered.

Firmware inventory and analysis are important, but in this context firmware attestation is key. It is the process of cryptographically proving that the firmware currently executing on a device matches a trusted, expected state. Unlike firmware inventory which identifies versions for lifecycle and vulnerability management and unlike firmware analysis that fetch artifacts, and statically and dynamically analyzes them to detect unauthorized modifications or malware, firmware attestation establishes runtime trust by allowing an external verifier to validate firmware integrity using measurements generated by a hardware Root of Trust.

Hardware-Backed Attestation with SPDM

Modern firmware attestation shifts trust away from software executing on the platform and toward dedicated hardware Roots of Trust.

The Security Protocol and Data Model (SPDM) is an industry standard developed by the DMTF to provide secure authentication, key exchange, and attestation between hardware devices.

An External Root of Trust (ERoT) continuously serves as the trust anchor for a device or a platform component that supports SPDM-based attestation. During boot or upon an operator’s request, it measures firmware components before they execute, records cryptographic measurements, and later proves those measurements to an external verifier.

Rather than relying on self-reported firmware information, an external verifier establishes an authenticated SPDM session with the device. SPDM provides standardized mechanisms for device authentication, secure messaging, key exchange, and measurement collection. Once the device's identity has been established through hardware-backed certificates, the verifier requests signed firmware measurements generated by the ERoT. Unlike traditional integrity verification approaches, the ERoT has direct hardware access to the flash memory containing the firmware and generates cryptographic measurements independently of the platform firmware. Because the firmware being measured is never responsible for reporting its own state, it is effectively removed from the attestation trust path and cannot manipulate or falsify the measurements presented to the verifier.

These measurements are then compared against vendor-provided Concise Reference Integrity Manifests (CoRIMs). A CoRIM contains the approved cryptographic measurements representing trusted firmware states for a given platform. If the reported measurements match the reference values contained in the CoRIM, the verifier gains cryptographic assurance that the firmware executing on the platform matches an approved configuration.

Instead of relying on self-reported firmware information, cryptographic measurements collected throughout the firmware execution chain are compared against trusted manufacturer reference values to establish firmware integrity. This fundamentally changes the security model.

Enterprise Best Practices

Firmware inventory and firmware attestation solve complementary problems and should be deployed together.

A mature firmware security program should include:

• Maintaining comprehensive firmware inventories for lifecycle and vulnerability management.
• Promptly updating firmware when security advisories are released.
• Protecting firmware signing keys and updating infrastructure.
• Performing offline firmware analysis where appropriate to detect suspicious binaries and unauthorized modifications.
• Deploying hardware-backed attestation using ERoTs and SPDM for systems requiring a high level of assurance.
• Validating firmware measurements against vendor-provided CoRIMs rather than relying solely on version information.
• Continuously verifying platform integrity throughout the system lifecycle instead of only during deployment.

Inventory identifies systems that may be vulnerable. Hardware-backed attestation provides cryptographic evidence that the firmware has not already been compromised. Together, they provide a significantly stronger foundation for enterprise firmware security.

Conclusion

In this post we walked through the transition from firmware inventory to firmware attestation as part of a modern updated firmware integrity program.

The conclusion is the same across the series. A trustworthy infrastructure must include firmware attestation, before it can believe the reported measurements.