Establishing a Firmware Signing Framework for CRA Compliance

To understand why firmware signing matters, it helps to start with firmware itself. With the rapid growth of connected devices and embedded systems, firmware has emerged as one of the most critical yet often overlooked attack surfaces in modern cybersecurity. Operating beneath the operating system and application layer, firmware quietly controls the hardware that powers everything from industrial systems and medical devices to consumer IoT products and automotive platforms.

Most users rarely think about it, developers often stop revisiting it after deployment, and security teams have traditionally focused more on software and network-level threats. However, when firmware is compromised, the impact can be severe while allowing attackers to gain persistent access, bypass security controls, or manipulate devices at their most fundamental level.

Recognizing these growing risks, the European Union introduced the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, which entered into force on 10 December 2024. The regulation establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market, with a strong emphasis on secure development practices, vulnerability management, and protection against unauthorized software modifications. Among its key requirements is the need for cryptographically verifiable firmware integrity, ensuring that only trusted and authenticated firmware can be deployed and executed on devices.

The CRA does not, however, cover every device that contains firmware. Under Article 2(1), it applies only to products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Consequently, firmware in genuinely standalone, non-connected (“offline”) products with no intended or reasonably foreseeable data connection may fall outside its scope. While full CRA compliance becomes mandatory by 11 December 2027, vulnerability reporting obligations will begin much earlier, from 11 September 2026.

To meet these requirements, organizations must move beyond traditional software security approaches and establish strong firmware protection mechanisms across the product lifecycle. One of the most important controls in this process is firmware signing that is a cryptographic mechanism helps verify the authenticity and integrity of firmware before it is installed or executed. A secure firmware signing framework not only protects devices from unauthorized or malicious code but also strengthens supply chain security, supports secure update mechanisms, and helps organizations demonstrate regulatory compliance.

In this blog, we explore how organizations can design and implement a secure, scalable, and CRA-aligned firmware signing framework, including the foundational technologies, operational considerations, and best practices required to protect modern embedded systems.

Firmware Signing and Its Need

Firmware is the low-level software embedded within a hardware device that controls how the device operates and communicates with its hardware components. Unlike regular software applications, firmware works close to the hardware layer and is responsible for essential functions such as device initialization, boot processes, hardware communication, memory control, and system operations. It exists in almost every modern connected device, including IoT devices, industrial control systems, automotive ECUs, routers, smartphones, healthcare equipment, and consumer electronics. Because firmware operates at such a fundamental level, any compromise within it can give attackers deep and persistent control over the device.

Firmware signing is a security mechanism used to ensure that only trusted and authentic firmware can be installed or executed on a device. In this process, the firmware binary is digitally signed using a cryptographic private key controlled by the manufacturer or trusted authority. The corresponding public key is securely embedded within the device, often as part of the secure boot process. Whenever firmware is installed, updated, or loaded during startup, the device verifies the digital signature before execution. If the signature validation fails or the firmware has been tampered with, the device immediately rejects the firmware, preventing unauthorized or malicious firmware from being executed.

Firmware signing plays a critical role in protecting devices from firmware tampering, supply chain attacks, malicious updates, and unauthorized modifications. It establishes trust between the manufacturer and the device, ensuring firmware integrity throughout the product lifecycle. As cyber threats targeting embedded systems continue to increase, firmware signing has become a foundational security requirement for modern connected devices and an important compliance measure under regulations such as the EU Cyber Resilience Act (CRA).

What NIST Recommends for Firmware Signing

The CRA sets the regulatory obligation, but it deliberately remains technology-neutral and does not prescribe the exact cryptographic mechanisms organizations must use. To translate a requirement such as “protect against unauthorized modification” into concrete engineering controls, most organizations turn to the National Institute of Standards and Technology (NIST), whose publications have become the de facto global reference for firmware integrity. Several NIST documents map directly onto the firmware signing problem.

NIST SP 800-147 and SP 800-147B (BIOS Protection Guidelines): SP 800-147 (2011) targets client platforms such as desktops and laptops, while SP 800-147B (2014) extends the same principles to server-class systems, a scope distinction a procurement audience needs. These establish the foundational principle that firmware updates must be authenticated with digital signatures before being applied. They introduce the Root of Trust for Update (RTU), an immutable verification component anchored in hardware that holds the signature-verification logic and the trusted public key. An update image is installed only if its signature verifies against a key in the RTU, and the guidelines also call for protection against rollback to earlier, vulnerable versions.

NIST SP 800-193 (Platform Firmware Resiliency Guidelines): This broadens the scope from BIOS alone to all platform firmware and critical data, and organizes controls around three principles: Protection (authenticate firmware updates with digital signatures and safeguard critical data), Detection (identify unauthorized or corrupted firmware before it executes), and Recovery (restore firmware to a known-good state after corruption). This protection–detection–recovery model is a useful blueprint for the CRA, which expects integrity not only at install time but across the product’s entire supported lifetime.

FIPS 186-5 and FIPS 140-3: FIPS 186-5, the Digital Signature Standard, specifies the approved signature algorithms (such as ECDSA, RSA, and EdDSA) used to generate firmware signatures, while FIPS 140-3 defines the security requirements for the cryptographic modules, typically Hardware Security Modules (HSMs), that protect signing keys. Note that the legacy Digital Signature Algorithm (DSA) is no longer approved for generating new signatures under FIPS 186-5 and is retained only for verifying existing ones. FIPS 186-5 also states that the algorithms in the standard are not expected to resist attacks from a large-scale quantum computer, which can be seen as reason why the hash-based and lattice-based schemes below matter for long-lived firmware.

NIST SP 800-57 and SP 800-89: SP 800-57 governs how signing keys are generated, stored, rotated, and retired across their lifecycle, while SP 800-89 provides recommendations for obtaining assurance that digital signatures are valid and trustworthy.

NIST SP 800-208 (Stateful Hash-Based Signature Schemes): SP 800-208 approves two stateful hash-based signature schemes for firmware and software signing, LMS and XMSS (along with their multi-tree variants HSS and XMSSMT), whose security rests solely on cryptographic hash functions. Because the schemes are stateful, every one-time key may be used only once, so the signer must never reuse or roll back its signing state. If that state is lost or rewound, for example through a power failure, VM cloning, or a restore from backup, a reused key can be exploited to forge signatures and compromise the key’s security.

For this reason SP 800-208 does not merely recommend hardware protection; it requires that key and signature generation be performed inside a FIPS 140-2 or 140-3 Level 3 (or higher) hardware module that never exports private keying material. Organizations should therefore confirm crash-consistent state management and validated HSM support before adopting LMS or XMSS.

FIPS 204 & FIPS 205 (Stateless Post-Quantum Signature Schemes): Organizations planning new firmware signing should also weigh the two stateless post-quantum standards NIST finalized in August 2024: FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). Being stateless, they avoid the one-time-key state management that LMS and XMSS require, which simplifies distributed and high-volume signing. ML-DSA, a lattice-based scheme, is a strong general-purpose default for its balance of speed and signature size, while SLH-DSA, derived from SPHINCS+, is the more conservative option for teams that want security resting solely on hash functions.

For firmware specifically, note that NSA’s CNSA 2.0 still designates the stateful SP 800-208 schemes (LMS and XMSS) as its near-term choice, so let your compliance context guide the decision. Whichever scheme you adopt, keep signing keys in FIPS 140-3 validated cryptographic modules, since FIPS 140-2 validations sunset on 21 September 2026.

Taken together, these publications give manufacturers a defensible, standards-based answer to the CRA’s integrity requirement: sign firmware with approved algorithms, protect the keys in certified hardware, verify signatures in a hardware-anchored root of trust, prevent rollback to vulnerable versions, and plan ahead for a post-quantum transition. Beyond NIST, the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) points in the same direction for firmware: it designates the SP 800-208 schemes LMS and XMSS for software and firmware signing in national security systems. It calls for an immediate transition, support and preference for CNSA 2.0 algorithms by 2025, and exclusive use by 2030.

Implementing a Firmware Signing Framework

Building a firmware signing framework that satisfies the CRA is less about deploying a single tool and more about establishing a trustworthy, repeatable, and auditable signing pipeline. A typical implementation moves through the following stages.

• Establish a hardware root of trust. Provision device hardware with an immutable public key (or its hash) in one-time-programmable memory or a secure element, so the device can verify signatures during secure boot and before accepting updates.
• Generate and protect signing keys in an HSM. Create the private signing keys inside a FIPS 140-2 or 140-3 Level 3 HSM so that key material is never exposed in plaintext or stored on build servers and developer machines.
• Define the signing process and approval workflow. Integrate signing into the build and release pipeline and enforce role-based access control with multi-party (M-of-N) approval so that no single engineer can sign and ship firmware unilaterally.
• Sign and timestamp the firmware. Apply the digital signature to the firmware image (embedded or as a detached signature) and add a trusted timestamp so the signature remains verifiable even after the signing certificate expires.
• Verify on the device. During secure boot and before every update, the bootloader validates the signature against the embedded public key and rejects any unsigned or tampered image, while rollback protection prevents downgrades to vulnerable firmware versions.
• Maintain auditability and lifecycle management. Log every signing event, rotate and revoke keys according to policy, and retain the records needed to demonstrate CRA conformity over the product’s lifetime.

A well-designed framework should also be crypto-agile. As algorithms evolve, particularly with the move toward post-quantum cryptography, the signing infrastructure should be able to adopt new algorithms without re-architecting the entire pipeline. Getting this right is not just sound engineering, understanding what is at stake financially reinforces why timely implementation is so urgent.

Penalties for Non-Compliance

The CRA backs its requirements with significant financial and operational consequences, modeled closely on the GDPR’s approach of taking the higher of a fixed sum or a percentage of global turnover. Under Article 64, penalties are tiered according to the severity of the breach.

Violation type	Maximum fine	Turnover cap (whichever is higher)
Breach of essential cybersecurity requirements (Annex I) or core manufacturer obligations (Articles 13 & 14) — covers weak or missing firmware integrity	€15 million	2.5% of total worldwide annual turnover
Breach of other obligations (conformity assessment, technical documentation, importer/distributor duties)	€10 million	2% of global annual turnover
Supplying incorrect, incomplete, or misleading information to notified bodies or market surveillance authorities	€5 million	1% of global annual turnover

Fines are not the only exposure. Market surveillance authorities can order a non-compliant product to be withdrawn or recalled from the EU market entirely, cutting off access to a single market of roughly 450 million consumers. The timeline is already in motion: the obligation to report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs begins on 11 September 2026, while full compliance becomes mandatory on 11 December 2027. For manufacturers, the cost of building a proper firmware signing program is modest compared with the financial, legal, and reputational cost of non-compliance.

Common Challenges in Firmware Signing

Even organizations that understand the value of firmware signing often struggle with the practical realities of doing it well, particularly at scale. Common challenges include the following.

• Protecting signing keys. A leaked or stolen private key lets an attacker sign malicious firmware that every device will trust completely. Keys stored in software, on build servers, or on developer laptops are a frequent point of failure.
• Constrained device resources. Many embedded and IoT devices have limited memory, processing power, and storage, which makes verifying signatures, and supporting larger post-quantum signatures, technically challenging.
• Managing keys across a long lifecycle. Firmware may need to be signed and re-verified for a decade or more, requiring careful key rotation, revocation, and rollback protection without bricking devices already in the field.
• Decentralized and manual signing. Ad-hoc signing scripts and keys scattered across teams create inconsistency, weak audit trails, and compliance gaps that are difficult to close after the fact.
• Secure provisioning across the supply chain. Embedding the correct trust anchors into devices during manufacturing, often across distributed global supply chains, is operationally complex and security sensitive.
• Preparing for post-quantum cryptography. Selecting quantum-resistant algorithms such as LMS or XMSS and managing their stateful one-time-key requirements adds complexity that legacy signing tooling was never designed to handle.

Best Practices for Firmware Signing

To establish a firmware signing framework that is both secure and CRA-aligned, organizations should adopt the following best practices.

• Store all signing keys in FIPS 140-2 or 140-3 Level 3 certified HSMs and ensure private keys are generated inside the module and never exported.
• Anchor verification in a hardware root of trust and enforce secure boot so that only signed, untampered firmware is ever executed.
• Use NIST-approved signature algorithms with appropriate key lengths, and apply trusted timestamping so signatures remain valid beyond certificate expiry.
• Enforce least privilege through role-based access control and require multi-party (M-of-N) approval for signing operations.
• Automate signing within the CI/CD pipeline to eliminate manual key handling and reduce human error.
• Implement rollback protection to block downgrade attacks that reintroduce older, vulnerable firmware.
• Maintain comprehensive, tamper-evident audit logs of every signing event to support CRA conformity and incident response.
• Build for crypto-agility and begin planning the transition to post-quantum algorithms now, given the long service life of most firmware.

How Encryption Consulting Can Help

Designing, deploying, and operating a firmware signing framework that withstands real-world threats and satisfies the CRA requires deep expertise in applied cryptography, PKI, and key management. This is where Encryption Consulting can help.

Our code signing platform, CodeSign Secure, provides a centralized, policy-enforced solution for signing firmware binaries alongside the full range of software artifacts. Private signing keys are generated and stored inside FIPS 140-2 Level 3 certified HSMs and never leave the module; only the artifact hash is transmitted for signing, never the firmware image or the private key itself. CodeSign Secure integrates with leading HSMs, including Thales Luna, Entrust nCipher, Utimaco, and Securosys, as well as cloud HSMs, and it enforces strong governance through role-based access control, M-of-N quorum approvals, secure timestamps, and complete audit trails. Because it plugs directly into existing CI/CD pipelines, signing becomes automated and consistent rather than manual and error-prone.

Crucially for long-lived firmware, CodeSign Secure ships with native post-quantum support, including ML-DSA and the NIST SP 800-208 stateful hash-based scheme LMS, so organizations can begin signing firmware with quantum-resistant algorithms today. Beyond the platform, our PKI, HSM, PQC advisory, and compliance services help organizations assess their current cryptographic posture, design a standards-based signing architecture, and build a defensible path to CRA compliance.

Conclusion

Firmware sits at the foundation of every connected device, and a compromise at that layer can quietly undermine every security control built above it. The EU Cyber Resilience Act has turned firmware integrity from an optional safeguard into a legal obligation, and NIST’s body of guidance provides a clear and defensible roadmap for meeting it.

By signing firmware with approved algorithms, protecting keys in certified hardware, verifying signatures in a hardware root of trust, and planning for the post-quantum future, organizations can protect their devices, secure their supply chains, and demonstrate compliance well ahead of the CRA’s 2027 deadline. The manufacturers that treat firmware signing as a first-class security function today will be the ones best positioned to earn customer trust, and avoid costly penalties, tomorrow.