Firmware Signing: A Practical Guide

Firmware signing is the practice of attaching a cryptographic signature to firmware so that a device can verify, at boot and at update, that the firmware came from a trusted source and has not been altered. It is the foundation of secure boot and the root of trust for IoT, embedded, and automotive systems.

Firmware signing lets a device cryptographically check that the low-level code it runs is authentic and unmodified before executing it. The device holds a trusted public key, often fused into hardware, and verifies the firmware’s signature against it. If the signature does not match, the device refuses to run the firmware. This is what stops attackers from installing malicious firmware, and it is the base of every secure boot chain.

Key Takeaways

• Firmware signing attaches a digital signature to firmware so a device can verify its authenticity and integrity before running it, forming the root of trust for secure boot.
• The trust anchor is a public key fused into one-time-programmable (OTP) hardware and read by immutable ROM at every power-on, so the chain of trust cannot be replaced in the field.
• Signing keys must live in a Hardware Security Module (HSM). A stolen firmware signing key lets an attacker sign malicious firmware that devices will trust, which is among the most damaging supply-chain compromises possible.
• Firmware often outlives its cryptography: devices deployed today may run into the 2040s. Long lifetimes make post-quantum readiness a procurement requirement, not a future concern.
• CNSA 2.0 names firmware signing the highest-priority use case for post-quantum transition. The deployable quantum-safe options today are the stateful hash-based schemes LMS and XMSS (NIST SP 800-208), with SLH-DSA (FIPS 205) as a stateless alternative.

Why Firmware Signing Is Different from Ordinary Code Signing

Firmware signing is code signing, but with constraints that make it uniquely demanding. Firmware runs at the lowest level of a device, before the operating system, so a compromise here is beneath the reach of most security tooling. And unlike an application you can patch weekly, firmware is often burned into hardware or updated rarely, sometimes never, over a device lifetime measured in decades.

Three properties define the challenge. Firmware is the first code to run, so it is the root of trust for everything above it. It runs on constrained hardware, so signature verification must be small and fast. And it is long-lived, so the cryptographic choices made at manufacture must remain sound for the entire service life of the device. A car, an industrial controller, or a medical device signed in 2026 may still need to verify firmware in 2041.

How Firmware Signing and Secure Boot Work

Firmware signing on its own is only half the story. Its value is realized through secure boot, the runtime process where each stage of the boot chain verifies the next before handing over control.

• Hardware root of trust: A public key is fused into one-time-programmable (OTP) memory at silicon manufacture. Immutable ROM reads this key at every power-on, and it cannot be replaced in the field. This is the anchor of the entire chain.
• Sign each firmware image: The manufacturer hashes each firmware image (ROM, bootloaders, application) and signs it with the corresponding private key, which is held securely in an HSM, never on the device.
• Verify stage by stage: At boot, ROM verifies the first-stage bootloader’s signature against the fused public key. That bootloader verifies the next stage, which verifies the next, forming an unbroken chain of trust from hardware up to the application.
• Reject on failure: If any signature does not match, verified boot halts and the device refuses to run the unverified image. Tampered or unauthorized firmware never executes.

Because the root key lives in immutable hardware and each stage gates the next, an attacker cannot insert malicious firmware anywhere in the chain without possessing the private signing key. That is why protecting the signing key is the entire game.

Why the Signing Key Is the Crown Jewel

If an attacker steals a firmware signing key, they can sign malicious firmware that every device trusting that key will accept as genuine. Because the verification key is often fixed in hardware and cannot be changed in the field, a compromised firmware signing key can be unrecoverable: there may be no way to revoke it on devices already in the field. This is a worst-case supply-chain scenario, and it is why firmware signing keys must be protected more carefully than almost any other key an organization holds.

The practical requirement is absolute: firmware signing private keys must be generated and stored in a Hardware Security Module (HSM), never exported to a build server or developer machine, with signing operations authenticated, access-controlled, and logged. The firmware crosses many hands (silicon vendor, OEM, Tier-1 supplier, contract manufacturer), and each handoff is a place the chain could be subverted, so centralized, audited key control is essential.

Firmware Signing Best Practices

• Keep signing keys in an HSM: Generate and store firmware signing keys in a FIPS 140-2 Level 2 or higher HSM. Never let the private key touch a build server, CI runner, or developer laptop.
• Anchor trust in hardware: Fuse the root public key into OTP and verify it from immutable ROM, so the trust anchor cannot be tampered with in the field.
• Sign every stage of the boot chain: Sign ROM extensions, bootloaders, and application firmware, and verify each stage against the one above it, so there is no unsigned gap.
• Use strong, current algorithms: Use SHA-384 or stronger hashing and appropriately sized keys. Plan for post-quantum signatures given long device lifetimes.
• Control and audit who can sign: Require authentication and authorization for every signing operation, and log who signed what and when, across every supplier in the chain.
• Design for crypto-agility: Where the hardware allows, enable signature-algorithm updates so devices are not locked to an algorithm that may weaken over their lifetime.

Firmware Signing and the Post-Quantum Transition

Firmware signing is the most urgent code-signing use case in the move to post-quantum cryptography, and the reason is structural. In many devices the firmware-verification algorithm is fixed at deployment, baked into immutable hardware or boot code. If that algorithm is RSA or ECDSA, a future quantum computer running Shor’s algorithm could forge signatures, and there may be no way to update the algorithm on devices already shipped.

This is why the NSA’s CNSA 2.0 guidance identifies firmware signing as the highest-priority signature use case for the quantum transition, and why it points to hash-based signatures that are standardized and deployable today rather than waiting for newer schemes. The options:

• LMS and XMSS (NIST SP 800-208): Stateful hash-based signatures, standardized in 2019 and approved under CNSA 2.0 for firmware and software signing. They are deployable now and rest on well-understood hash-function security, which suits long-lived firmware.
• SLH-DSA (FIPS 205): A stateless hash-based signature finalized in August 2024. It avoids the state-management burden of LMS and XMSS at the cost of larger signatures, and shares their conservative security foundation.
• ML-DSA (FIPS 204): The lattice-based, general-purpose signature. It is the long-term candidate for broad use, though for the most conservative long-lived roots many organizations prefer hash-based schemes.

The State-Management Catch with LMS and XMSS
LMS and XMSS are stateful: each private key can produce only a fixed number of signatures, and the signer must track which one-time keys have been used, because reusing one breaks security. This makes them impractical for high-frequency signing, but well suited to firmware signing, which is infrequent and controlled. Importantly, the state is managed by the signer (in your signing infrastructure), not by the device, so it adds no complexity to the deployed hardware. A capable signing platform handles this state tracking automatically.

CNSA 2.0’s timeline for software and firmware signing is to prefer the quantum-safe algorithms by 2025 and use them exclusively by 2030, the most aggressive category in the entire suite, precisely because firmware is so hard to change after deployment.

Firmware Signing in IoT, Embedded, and Automotive

Firmware signing matters most exactly where devices are numerous, long-lived, and hard to reach. In the Internet of Things, unsigned firmware updates are a primary attack vector for building botnets and gaining persistence.

In automotive, regulations such as UNECE R155 and standards like ISO/SAE 21434 expect firmware-modification threats to be mitigated, and vehicles built today will be on the road into the 2040s. In industrial and medical devices, a firmware compromise can carry safety consequences, not just data-security ones.

What these domains share is the combination that makes firmware signing non-negotiable: constrained hardware that must verify signatures efficiently, very long service lives that outlast cryptographic assumptions, and a supply chain that crosses multiple organizations before a device reaches the field. Getting firmware signing and its key management right is the foundation everything else in device security is built on.

How Encryption Consulting Helps

Encryption Consulting’s CodeSign Secure is built for exactly this problem. It keeps firmware signing keys in a FIPS 140-2 Level 2 HSM so the private key never leaves hardware, enforces who is authorized to sign, and logs every signing operation for audit across your suppliers and build systems.

It integrates signing into CI/CD pipelines so firmware is signed automatically against hardware-protected keys, and it supports the hash-based and post-quantum signature schemes that firmware signing increasingly requires, including the stateful state management that LMS and XMSS demand. The result is a single, governed signing process for firmware, secure-boot chains, and the rest of your code signing. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is firmware signing?

Firmware signing is the practice of attaching a cryptographic signature to firmware so that a device can verify, before running it, that the firmware came from a trusted source and has not been altered. The device holds a trusted public key, often fused into hardware, and checks the firmware’s signature against it. If the signature does not match, the device refuses to run the firmware, which prevents attackers from installing malicious code at the lowest level of the system.

What is the difference between firmware signing and secure boot?

Firmware signing is the act of producing the signature; secure boot is the runtime process that verifies it. When firmware is built, it is signed with a private key. At power-on, secure boot checks each stage of the boot chain against a trusted public key before running it, starting from an immutable hardware root. Firmware signing provides the signatures, and secure boot enforces them, so the two work together to keep unauthorized firmware from ever executing.

Why must firmware signing keys be stored in an HSM?

Because a stolen firmware signing key is catastrophic and often unrecoverable. An attacker with the key can sign malicious firmware that every device trusting that key will accept, and because the verification key is frequently fixed in hardware, there may be no way to revoke it on devices already deployed. Storing the private key in a Hardware Security Module means it never leaves tamper-resistant hardware, so even a fully compromised build system cannot exfiltrate it.

What algorithms should I use for post-quantum firmware signing?

For quantum-safe firmware signing today, the deployable options are the stateful hash-based schemes LMS and XMSS, standardized in NIST SP 800-208 and approved under CNSA 2.0. SLH-DSA (FIPS 205) is a stateless hash-based alternative finalized in August 2024. Hash-based schemes are often preferred for long-lived firmware roots because their security rests only on well-understood hash functions. ML-DSA (FIPS 204) is the general-purpose lattice-based option for broader use.

Why is firmware signing the top priority for the post-quantum transition?

Because firmware is the hardest thing to change after deployment. In many devices the signature-verification algorithm is fixed in immutable hardware or boot code, so if it uses RSA or ECDSA, a future quantum computer could forge firmware signatures with no way to update the algorithm on devices already in the field. The NSA’s CNSA 2.0 guidance names firmware signing the highest-priority signature use case and sets the most aggressive timeline, exclusive quantum-safe use by 2030.

What are the state-management concerns with LMS and XMSS?

LMS and XMSS are stateful hash-based signatures: each private key can produce only a fixed number of signatures, and the signer must track which one-time keys have been used, because reusing one compromises security. This makes them unsuitable for high-frequency signing but well suited to infrequent, controlled firmware signing. The state is managed by the signing infrastructure, not by the device, so it adds no complexity to the deployed hardware. A capable signing platform tracks this state automatically.

Sign Firmware Against Hardware-Protected Keys

Firmware signing is only as strong as the protection around its keys, and the stakes are higher than any other signing use case. Explore CodeSign Secure to sign firmware and secure-boot images against HSM-protected keys, with post-quantum algorithm support and full audit across your supply chain.