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, defined: a cryptographic control that binds a firmware image to a manufacturer-controlled private key, held in an HSM, so that a device’s boot process or update mechanism can verify the image’s authenticity and integrity before executing or installing it, and reject anything that fails that check.

Key Takeaways

• The CRA (Regulation (EU) 2024/2847) requires cryptographically verifiable firmware integrity; vulnerability reporting obligations begin 11 September 2026, and full compliance is mandatory by 11 December 2027.
• A production-grade signing framework separates an offline root key from an online signing key, and provisions a separate per-device manufacturing identity, three distinct roles that are easy to conflate into one key.
• Secure boot and update verification are related but separate trust chains, a device can verify its boot image against a hardware-anchored root while verifying update packages against a different, rotatable online key.
• Constrained devices can struggle with larger post-quantum signatures; NSA’s CNSA 2.0 currently designates the stateful, smaller-signature schemes LMS and XMSS as the near-term choice for firmware.
• A signing key compromise is a recovery scenario, not just a prevention problem; see “Recovery from Key Compromise” below for what has to happen before, during, and after one.

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.

Root of Trust Architecture: Offline Roots, Online Keys, and Manufacturing Identities

Most firmware signing failures trace back to treating “the signing key” as a single thing. A defensible architecture separates it into at least three distinct roles, each with a different exposure profile.

Offline Root Key vs. Online Signing Key

The offline root key sits at the top of the hierarchy and is used as rarely as possible, typically only to issue or renew the intermediate certificate for the online signing key. It is generated and kept inside an HSM that stays disconnected from any network, often physically secured with M-of-N access controls, and brought online only for scheduled, witnessed ceremonies. The online signing key is what the build pipeline actually calls on every release; it is HSM-backed as well, but reachable over an authenticated API so signing can be automated. Because it is used constantly, it carries higher exposure, which is exactly why it should never be the same key as the offline root: if the online key is ever rotated or revoked, the root of trust embedded in devices doesn’t have to change, only the intermediate certificate does.

Manufacturing Identities

Separate again from both signing keys is the device’s own manufacturing identity, a unique, per-device key pair and certificate provisioned during manufacturing, following the pattern standardized in IEEE 802.1AR (Secure Device Identity, commonly called DevID). This identity is what lets a device authenticate itself to a provisioning or update server, and lets that server confirm it’s talking to a genuine device rather than a cloned or counterfeit one. It is not the key that verifies firmware signatures; it is the key that establishes which physical device is asking for an update in the first place. Provisioning this identity securely, typically injected during manufacturing test in a facility that may be operated by a contract manufacturer rather than the OEM itself, is one of the most operationally sensitive steps in the entire framework, since a leak at that stage can compromise every device from that production run.

Secure Boot and Update Trust Chains

It helps to treat boot-time verification and update verification as two related but distinct trust chains, because they don’t have to use the same key and, in a well-designed system, usually don’t.

The secure boot chain starts at an immutable hardware root, a public key or its hash burned into one-time-programmable memory or a secure element at manufacturing time. On every power-up, the boot ROM verifies the first-stage bootloader against that embedded key before executing it; that bootloader in turn verifies the next stage, and so on, each link confirming the next before handing off execution. Because the root of this chain is immutable, it typically stays tied to the offline root key’s lineage rather than the online signing key that rotates more often.

The update trust chain is what verifies a new firmware image before it’s written to flash, and it’s the one that touches the online signing key on every release. An update package signed with the current online key is verified against the certificate chain back to the root before the device accepts it; rollback protection, typically a monotonic counter or version number stored in tamper-resistant memory, blocks the device from accepting a validly signed but older, vulnerable version. Because this chain is exercised far more often than the boot chain, it’s also the one most likely to need crypto-agility, an algorithm or key rotation on the update chain shouldn’t require re-flashing the immutable boot ROM itself.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Recovery from Key Compromise

Every firmware signing framework needs a plan for the scenario it’s designed to prevent: a signing key that gets compromised anyway, whether through a breached build server, an insider, or a flaw in the HSM’s operating procedures. Prevention and recovery are different disciplines, and skipping the second because the first is strong is how a compromise turns into a fleet-wide incident.

1. Determine scope. Identify which key was affected, offline root, online signing key, or a manufacturing identity, since the blast radius and response differ sharply between them. A compromised online key affects future signing; a compromised offline root affects the trust anchor already embedded in every deployed device.
2. Revoke or blocklist the compromised key. Update the certificate revocation status and, if devices check revocation online, push that status immediately. Devices that only validate against an embedded public key with no revocation channel are the harder case, which is why crypto-agile designs provision a backup key or a secondary trust anchor in advance.
3. Rotate to a pre-provisioned successor key. If a next-generation key was already embedded in devices at manufacturing time (a common practice for exactly this scenario), switch signing operations to it and begin the update rollout. If no successor was provisioned, the recovery path is significantly slower and may require a physical intervention for offline or field-deployed devices.
4. Push an emergency, out-of-band signed update. Use a break-glass procedure, a documented, rarely used process for emergency signing outside the normal M-of-N cadence, to distribute the corrected firmware and, where the device supports it, block further acceptance of anything signed with the compromised key.
5. Meet disclosure obligations. Under the CRA, manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of becoming aware of it, submit a fuller report within 72 hours, and a final report within 14 days of a corrective measure becoming available; a signing key compromise that enables malicious firmware to pass verification falls squarely within that obligation.
6. Conduct a post-incident review. Determine how the key was exposed, whether the offline/online separation held or failed, and whether the incident reveals a gap in HSM access controls, build pipeline security, or manufacturing provisioning that needs to close before the next key generation ceremony.

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.

CRA Evidence: What Auditors and Notified Bodies Expect to See

A firmware signing framework that works technically still needs to produce evidence that a conformity assessment body, market surveillance authority, or internal auditor can actually review. In practice, that means retaining:

• A signing event log tying every released firmware version to the specific key, approver(s), and timestamp used to sign it.
• HSM validation certificates (FIPS 140-2 or 140-3) for the modules protecting signing keys, since “we use an HSM” without the certificate reference isn’t evidence.
• Key lifecycle records: generation date, rotation history, and revocation status for every signing key, including the offline root.
• Documented rollback-protection behavior, evidence that the device actually rejects a validly signed but outdated firmware version, not just a design claim that it should.
• Vulnerability disclosure timeline records, showing the 24-hour, 72-hour, and 14-day CRA reporting milestones were met for any relevant incident.

Centralizing signing under one platform makes this materially easier: the evidence above comes from one consistent audit trail rather than being reconstructed after the fact from build logs, email threads, and whoever remembers how the last key ceremony went.

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.

Basic vs. CRA-Ready Firmware Signing: A Quick Checklist

Control	Basic Signing	CRA-Ready Framework
Key hierarchy	Single signing key for everything	Offline root, rotatable online key, and separate manufacturing identities
Key storage	Build server or developer machine	FIPS 140-2/140-3 Level 3 HSM, private key never exported
Rollback protection	Not enforced	Monotonic counter blocks downgrade to vulnerable versions
Approval	Single engineer can sign and ship	Role-based access control with M-of-N approval
Long-term validation	Signature invalid after cert expiry	Trusted timestamping keeps signatures verifiable long-term
Compromise recovery	No documented plan	Pre-provisioned successor key and break-glass procedure
Audit evidence	Reconstructed after the fact	Centralized, tamper-evident log tied to every release

Frequently Asked Questions

What’s the difference between an offline root key and an online signing key?

The offline root key is used rarely, typically only to issue the certificate for the online signing key, and stays on an air-gapped HSM. The online signing key is what the build pipeline calls on every release and is reachable over an authenticated API. Separating them means the online key can be rotated without ever touching the trust anchor already embedded in deployed devices.

How does rollback protection actually work?

A monotonic counter or version number is stored in tamper-resistant memory on the device. Before installing an update, the device checks the new image’s version against that counter and rejects anything at or below the current value, even if the signature itself is valid, which blocks an attacker from reintroducing an older, vulnerable, but legitimately signed firmware version.

What happens if a firmware signing key is compromised?

The compromised key is revoked, signing shifts to a pre-provisioned successor key where one exists, an emergency signed update is pushed through a documented break-glass process, and, under the CRA, the incident may trigger vulnerability disclosure obligations to ENISA on a 24-hour/72-hour/14-day timeline. See “Recovery from Key Compromise” above for the full sequence.

Can constrained IoT devices support post-quantum firmware signatures today?

It depends on the scheme. LMS and XMSS (NIST SP 800-208) produce smaller signatures than ML-DSA or SLH-DSA, which is why NSA’s CNSA 2.0 currently designates them as the near-term choice for firmware. They do require stateful, crash-consistent key management inside a validated HSM, which constrained devices don’t handle themselves, that state lives on the signing side, not on the device.

What counts as evidence for a CRA conformity assessment?

A signing event log tied to specific firmware versions and approvers, HSM validation certificates, key lifecycle records, documented proof that rollback protection actually rejects downgrades, and vulnerability disclosure timeline records. See “CRA Evidence” above for the full list.

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.