A firmware update is one of the most powerful things you can push to a field device, because it replaces the code the device runs from the ground up. That power cuts both ways: if an attacker can get a device to accept a firmware image of their choosing, they own the device completely. Firmware code signing is the safeguard that lets a device tell a genuine vendor update from a tampered or counterfeit one by checking a cryptographic signature before it installs anything. This guide explains how code signing works, why the custody of the signing key is the whole game, and how signing pairs with secure boot and matters for supply-chain trust.
Firmware Code Signing in one line: Firmware code signing is the practice of attaching a cryptographic signature, made with the vendor's private signing key, to a firmware or update package, so that a device can verify the signature before accepting the update. The device checks the signature against the vendor's trusted public key, and installs the firmware only if it verifies, which proves the image genuinely came from the vendor and was not altered in transit. This blocks tampered, counterfeit, or malicious firmware from being installed, because such an image cannot carry a valid signature.
Code signing works by giving each firmware image a signature that only the legitimate vendor could have produced. The vendor holds a private signing key and uses it to sign the firmware, and the device holds the matching public key, placed there as a trusted value. When an update arrives, the device does not simply flash it. It first computes over the image and checks the attached signature against the vendor's public key, confirming two things at once: that the image was signed by the holder of the private key, meaning it really came from the vendor, and that not a single byte has been changed since it was signed, because any modification would break the signature. Only if both hold does the device proceed to install.
The consequence is that tampering and forgery are caught at the door. An attacker who intercepts an update and modifies it invalidates the signature, so the device rejects the altered image. An attacker who fabricates a malicious image from scratch cannot sign it acceptably, because they do not hold the vendor's private key, so that image is rejected too. Even a corrupted download fails verification and is refused rather than half-installed. The device is no longer trusting an update because it arrived through the expected channel or looks plausible; it is trusting the update because it carries a signature only the genuine vendor could have made, which is a far stronger basis than the delivery path alone.
Every bit of assurance code signing provides rests on one assumption: that the private signing key is held only by the legitimate vendor and no one else. If that key leaks, the entire scheme inverts, because an attacker who holds it can sign malicious firmware that every device will accept as genuine, and the very mechanism meant to keep bad firmware out now waves it through. There is no clever recovery from a stolen signing key short of retiring it and re-establishing trust in a new one across the whole fleet, which for deployed field devices is slow and painful. This is why the custody of the signing key is not a detail but the central problem of code signing.
Protecting that key is therefore treated with the seriousness the consequences warrant. The signing key is commonly generated and kept inside a hardware security module, so that signing happens inside the hardware and the key never exists in a form that can be copied off a compromised build server. Access to signing is restricted and logged, so it is clear who signed what and when, and the operations are separated from ordinary development so that a breach of a developer's machine does not put the key within reach. The through-line is that a code-signing key is one of the most consequential secrets an organization holds, because it is the thing that lets devices trust incoming firmware, and it deserves protection commensurate with the fact that its loss would let an attacker impersonate the vendor to every device in the field.
Code signing and secure boot are two applications of the same idea, verifying signatures on code, working at different moments. Code signing is checked when an update is installed, gating what firmware is allowed onto the device in the first place. Secure boot is checked every time the device starts, gating what firmware is allowed to run. Together they cover both ends: signing keeps unauthorized firmware from being written, and secure boot keeps unauthorized firmware from executing even if it somehow got written, so an attacker has to defeat both a trusted install path and a trusted boot path rather than just one. This layering is why the two are so often deployed as a pair rather than treated as alternatives.
The broader value of code signing is supply-chain trust. Firmware and updates travel a long path from the vendor's build system through distribution channels, download servers, and update tools before they reach a device, and any point along that path is a chance for something to be swapped or tampered with. A signature made at the source and verified at the destination lets the device ignore everything that happened in between and judge the firmware on whether it genuinely came from the vendor unaltered, which shrinks the trusted path down to the two endpoints. For OT, where devices are numerous, remote, and long-lived, that end-to-end assurance matters. It complements the delivery mechanics of over-the-air updating by supplying the trust layer: the update process moves the firmware efficiently, and code signing is what tells the device whether to believe the firmware it received. For a cloud SCADA operation that relies on keeping distributed field assets current, that combination, reliable delivery plus verifiable authenticity, is what lets firmware be maintained across a fleet without turning the update pipeline into an attack path.
The vendor signs each firmware image with a private key, and the device verifies that signature against the vendor's trusted public key before installing. A tampered image fails verification because any change breaks the signature, and a fabricated malicious image fails because an attacker cannot produce a valid signature without the vendor's private key. The device installs only firmware that verifies, so altered, counterfeit, or corrupted images are rejected rather than accepted.
The protection inverts: an attacker holding the key can sign malicious firmware that every device accepts as genuine, so the mechanism meant to keep bad firmware out now lets it through. There is no easy recovery short of retiring the compromised key and re-establishing trust in a new one across the whole fleet, which is slow for deployed field devices. This is why signing keys are guarded closely, often kept inside a hardware security module and with access tightly restricted and logged.
Code signing is verified when an update is installed and gates what firmware is allowed onto the device, while secure boot is verified every time the device starts and gates what firmware is allowed to run. They apply the same signature-checking idea at different moments, and together they cover both writing and executing firmware. An attacker would have to defeat both the install path and the boot path, which is why the two are usually deployed as a pair.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.