Firmware Signing

What is Firmware Signing?

Firmware signing is a security measure in which the manufacturer attaches a cryptographic digital signature to firmware, so that a device can check before installation or execution that the code comes from a trusted source and has not been altered along the way. The device rejects firmware that is unsigned or wrongly signed. Firmware signing is the application of code signing to the lowest software layer of a device.

In OT systems, firmware signing prevents attackers from installing malicious or tampered firmware on devices such as PLCs, RTUs, IEDs or IIoT devices. Because firmware runs beneath the control program, a manipulated version is almost invisible and stays active after a restart.

🧠 How does firmware signing work?

Firmware signing uses asymmetric cryptography: the manufacturer signs with a secret private key, and the device verifies with the matching public key stored inside it.

1. Hashing - the build environment calculates a cryptographic hash of the firmware image, usually with SHA-256 or SHA-384.
2. Signing - a signing service uses the private key to compute a signature over that hash. Ideally the key lives in a hardware security module (HSM) and never leaves it.
3. Packaging - the image ships with the signature, a version number and often a certificate or key ID.
4. Verification at installation - the device’s bootloader or update process recalculates the hash and checks the signature with the built-in public key.
5. Rejection on mismatch - if the signature does not match, or the version number is lower than allowed, the update is blocked and the old firmware stays active.
6. Logging - attempts to load unverified firmware should be logged and forwarded to a central system.

A common simplification is that the hash is “encrypted” with the private key. That is only true for textbook RSA; with ECDSA and EdDSA, signing is a separate mathematical operation. The principle is the same: only whoever holds the private key can produce a valid signature.

🔧 Which algorithms and key sizes are common?

For firmware that stays in the field for twenty years or more, the choice of algorithm is a long-term decision. In its CNSA 2.0 plan, the US NSA wants software and firmware signing to use quantum-resistant hash-based signatures preferably from 2025 and exclusively by 2030.

🔄 What is the difference between firmware signing and Secure Boot?

Firmware signing and Secure Boot use the same cryptography but check at a different moment.

The layers work together: signing keeps bad firmware out, while Secure Boot checks at every start whether what is in memory is still genuine. Without a hardware root of trust, an attacker with physical access can bypass both. That became clear in January 2023 with the Siemens S7-1500 (CVE-2022-38773): the CPUs lack an immutable root of trust in hardware, so the integrity of the code cannot be verified at load time and someone with physical access can replace the boot image. Siemens released new hardware versions with a new secure boot mechanism for some CPU types and advises physical protection, such as locked cabinets, for the others.

🏭 Where is firmware signing relevant in OT?

Its importance became clear in the attack on Ukrainian power distribution companies on 23 December 2015. The outage hit about 225,000 customers. The attackers also corrupted the firmware of serial-to-Ethernet converters in substations, rendering them inoperable and hampering recovery. Devices that only accept signed firmware make such an attack much harder.

Firmware signing is an essential defence against persistent attacks via the supply chain, physical access or insider sabotage.

🔐 Which standards and laws call for signed firmware?

• IEC 62443-4-2 - requirement EDR 3.10 calls for support for updates; its enhancement RE(1) requires the device to verify the authenticity and integrity of an update. EDR 3.14 covers the integrity of the boot process and CR 3.4 software and information integrity.
• IEC 62443-3-3 - at system level this falls under SR 3.4 Software and information integrity, within FR 3 System integrity.
• IEC 62443-4-1 - the development process standard requires suppliers to deliver updates in a way that lets users verify their authenticity (practice SUM-4), and to protect the private keys used for code signing (SM-8).
• Cyber Resilience Act - Annex I requires manufacturers to protect the integrity of programs and configuration against unauthorised modification and to distribute updates securely. Reporting obligations apply since 11 September 2026, the full requirements from 11 December 2027.
• Machinery Regulation - from 20 January 2027, safety-critical software and data in machine control systems must be protected against corruption.
• NIST SP 800-193 - the Platform Firmware Resiliency guidelines (May 2018) are built on protecting, detecting and recovering firmware.

For organisations under NIS2 and the Dutch Cybersecurity Act (Cyberbeveiligingswet), signed firmware is not a direct legal requirement, but it is a logical part of supply chain security and patch management.

🔁 Where does firmware signing fit in the CSIR classification?

In this knowledge base’s CSIR scheme, firmware signing falls under two labels, with a clear link to the IEC 62443 requirements.

🛠️ How do you approach firmware signing as an end user?

As an asset owner you do not sign firmware yourself, but you do determine whether the protection actually works.

1. Take inventory - record per device in your asset inventory whether it enforces signed firmware and whether it has a hardware root of trust.
2. Set procurement requirements - as part of supplier security, ask about EDR 3.10 RE(1), key management and how a compromised key is revoked.
3. Download only from the official source - also check the published hash, especially for devices that do not enforce a signature.
4. Test beforehand - install new firmware on a test set-up first and record the change through change management.
5. Block downgrades - enable anti-rollback where possible, so an attacker cannot reinstall an older, vulnerable but still signed version.
6. Limit physical access - lock cabinets and set the CPU protection level or key switch to run, in addition to hardening.

⚠️ What are the limitations and points of attention?

• Not all equipment supports it - much older OT equipment checks no signature at all, or only a simple checksum.
• Key management is the Achilles’ heel - whoever steals the private key can produce valid malware. Stuxnet used stolen certificates from Realtek and JMicron to sign its drivers, and PKfail (2024) showed that many devices trusted a publicly known test key.
• A signature says nothing about vulnerabilities - a signed version can still contain flaws; vulnerability management and an SBOM remain necessary.
• Vendor lock-in - some vendors keep the signing process closed, so only their own firmware will ever run.
• Risk of bricked devices - a flaw in the signing or update process can leave an asset unusable after an update; dual-bank flash with a fallback image limits that risk.

❓ Frequently asked questions

Is firmware signing the same as code signing?

Firmware signing is a form of code signing aimed at device firmware. Code signing also covers applications, drivers and scripts on PCs and servers. The cryptography is the same, but with firmware signing the check happens in the device’s own bootloader or update process.

Which public key does a PLC use to verify firmware?

A PLC verifies firmware with a manufacturer’s public key that was stored in the device during production, for example in ROM, one-time programmable fuses or a secure element. The matching private key stays with the manufacturer, usually in a hardware security module. As a result, only the manufacturer can produce firmware the PLC will accept.

Does firmware signing protect against an attack like TRITON?

Not completely. In the TRITON attack of 2017, attackers loaded malicious code into the memory of a running Triconex safety controller without replacing the firmware through a normal update. Firmware signing protects the update channel, but additional measures such as the key switch, network segmentation and monitoring remain necessary.

What happens if a vendor’s signing key leaks?

If a vendor’s signing key leaks, attackers can produce firmware that devices accept as genuine. The vendor then has to roll out a new key and revoke the old one, which for devices with a key fixed in hardware is sometimes only possible by replacing them. Ask vendors beforehand how they protect and rotate their keys.

Is firmware signing mandatory under the Cyber Resilience Act?

The Cyber Resilience Act does not mention firmware signing by name, but from 11 December 2027 it requires manufacturers to protect programs against unauthorised modification and to distribute updates securely. In practice, a digital signature on firmware is the usual way to demonstrate this. The obligation applies to manufacturers, not to the users of OT equipment.

Can I secure existing equipment without firmware signing?

Existing equipment without firmware signing can only be compensated with other measures. Think of checking hashes on downloads, physical shielding, blocking engineering access outside maintenance windows and network segmentation in line with IEC 62443. When replacing equipment, you can make signed firmware a hard procurement requirement.

📌 In summary

Firmware signing ensures that only authentic, unaltered firmware from the manufacturer ends up on a device. In OT, this is crucial for protecting PLCs, RTUs and field devices against tampering via vendor updates, remote maintenance or physical access. The measure only truly works in combination with Secure Boot, a hardware root of trust and careful key management, and the Cyber Resilience Act makes secure updates a duty for suppliers from 2027.