Code Signing

What is Code Signing?

Code signing is the cryptographic signing of software, Firmware, scripts and other executable files with a private key and a digital certificate, so that a system can check before installation or execution who produced the code and that it has not been modified since. A valid signature therefore proves origin (authenticity) and unaltered content (integrity). It does not prove that the code itself is safe or free of defects.

In OT environments, code signing is essential for Firmware updates, PLC programming and software distribution in production networks, where reliability and continuity are critical. A tampered update can affect not just data but a physical process.

🧠 Why does code signing matter in OT?

Installations in the process industries, energy and water run for ten to twenty years or longer and receive updates through many channels: engineering software, USB sticks, vendor portals, service engineers and, increasingly, over the air. Code signing makes each of those channels verifiable.

1. Protection against tampering - a modified file produces an invalid signature and is rejected or flagged.
2. Source verification - only code from trusted vendors or from your own engineering department is accepted.
3. Support for Secure Boot - only signed Firmware and bootloaders are executed at startup.
4. Less exposure to Malware - unsigned or wrongly signed code is blocked, for example through application whitelisting.
5. Demonstrable Compliance - code signing supports requirements in IEC 62443, NIS2 and the Cyber Resilience Act, although it does not make you compliant on its own.

🔧 How does code signing work, step by step?

Code signing uses asymmetric cryptography: the signer uses a secret private key, and the verifier uses the matching public key from the certificate.

1. Hashing - the build environment computes a cryptographic hash of the code, usually SHA-256 or SHA-384.
2. Signing - the private key is used to compute a signature over that hash (for example with RSA or ECDSA). The key lives in a hardware security module (HSM) and never leaves it.
3. Timestamping - a timestamping authority (following RFC 3161) confirms when the code was signed. This keeps the signature valid after the certificate itself has expired.
4. Packaging - the signature, certificate chain and timestamp are shipped inside or alongside the file.
5. Verification - the operating system, bootloader or update process recomputes the hash, checks the signature and the certificate chain up to a trusted root, and checks that the certificate has not been revoked.
6. Accept or reject - only valid, unaltered and trusted code is installed or executed; deviations are preferably recorded in logging.

The common explanation that the hash is “encrypted” with the private key is only accurate for classic RSA. With ECDSA, signing is a distinct mathematical operation. The principle stays the same: only whoever holds the private key can produce a valid signature.

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

All three use the same cryptography but differ in scope and in the moment of checking.

Firmware signing is therefore code signing applied to the lowest software layer. Secure Boot uses those signatures to check at every start that what is in memory is still correct. A Trusted Platform Module or another secure element can serve as the hardware root of trust on the device side.

🏭 Where is code signing used in OT?

🔐 How do you protect signing keys and certificates?

A signature is exactly as trustworthy as the private key. Anyone who steals the key can produce malware that looks legitimate. Key handling therefore belongs in certificate management, not on a developer’s laptop.

• Hardware storage - since June 2023 the CA/Browser Forum has required private keys for publicly trusted code signing certificates to be held in a hardware module meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, such as an HSM, cloud HSM or token.
• Shorter validity - certificates issued from 1 March 2026 are valid for at most 460 days, down from 39 months. Treat renewal as a routine process.
• Always timestamp - without a timestamp, a signature becomes invalid as soon as the certificate expires, while OT software is often installed years later.
• Separation of duties - following RBAC and least privilege, only a small number of authorised people or pipelines may sign, preferably with two-person approval.
• CI/CD integration - the build pipeline signs automatically after tests pass, so no manual copies of the key circulate.
• Revoke and log - revoke the certificate immediately if it is compromised. Log every signing operation so you can see afterwards what was signed with which key.

For internal code, such as your own scripts or PLC libraries, you can use an internal CA. You then have to distribute its root certificate securely to every system that verifies signatures.

⚠️ What can code signing not prevent?

A signature tells you who signed the code, not whether the code can be trusted. Three well-known incidents illustrate this:

• Stuxnet (2010) - the worm’s drivers were signed with stolen certificates from Realtek and JMicron, so Windows installed them without warning. VeriSign revoked both certificates in July 2010.
• SolarWinds (2020) - attackers planted the SUNBURST backdoor in the Orion build environment. The trojanised DLL was signed with SolarWinds’ legitimate certificate and distributed through normal updates, from at least March 2020.
• 3CX (2023) - the VoIP vendor’s desktop app was compromised through an earlier supply chain attack and shipped signed with 3CX’s valid certificate.

Code signing is therefore one security layer alongside a secure development process, an SBOM, patch management, network detection and testing in a staging environment before production.

📜 Which standards and laws call for code signing?

• IEC 62443-4-1 - vendors must protect private keys used for code signing (practice SM-8) and deliver updates in a way that lets users verify their authenticity (SUM-4).
• IEC 62443-4-2 - CR 3.4 requires software and information integrity; EDR 3.10 RE(1) requires a device to verify the authenticity and integrity of an update.
• IEC 62443-3-3 - at system level this falls under SR 3.4 Software and information integrity.
• NIST SP 800-218 (SSDF 1.1, February 2022) - task PS.2.1 asks producers to make integrity verification information, such as hashes and signatures from an established CA, available to acquirers.
• Cyber Resilience Act - Annex I requires protection of software integrity and secure distribution of updates. Reporting obligations apply from 11 September 2026, the full requirements from 11 December 2027.
• NIS2 and the Dutch Cybersecurity Act - the duty of care covers supply chain security and security in the acquisition, development and maintenance of systems. Signed software is a common way to demonstrate this.

🧭 How do you introduce code signing in an OT environment?

1. Take inventory of the software, firmware and scripts you use and which of them are already signed. Ask vendors about their signing process and certificates.
2. Enable verification wherever possible: Secure Boot on IPCs, firmware checks on PLCs, AllSigned for PowerShell and application control on Windows systems.
3. Put requirements in procurement - ask for signed updates, published hashes and an SBOM, in line with IEC 62443-4-1 and the CRA.
4. Set up a signing service for your own code, with an HSM, internal CA or public certificate, timestamping and approval through change management.
5. Verify on receipt - check the signature and hash of every update before use, including installations via USB or by a service engineer.
6. Plan for lifecycle and emergencies - renew certificates in time, rehearse revoking a key and consider post-quantum algorithms for long-lived systems.

❓ Frequently asked questions

What is the difference between code signing and encryption?

Code signing protects the authenticity and integrity of code but does not keep its content secret. Anyone can read signed code; they just cannot change it unnoticed. Encryption instead makes content unreadable to anyone without the key.

Is signed software always safe?

Signed software is not automatically safe. Code signing only proves who signed the code and that it has not been modified since. In the Stuxnet and SolarWinds attacks, malicious code was signed with genuine or stolen certificates.

What happens to a signature when the certificate expires?

If the code received a timestamp when it was signed, the signature remains valid after the code signing certificate expires. Without a timestamp, many systems reject the code after the expiry date. For OT software that is still installed years later, timestamping is therefore essential.

How long is a code signing certificate valid?

Publicly trusted code signing certificates issued from 1 March 2026 are valid for at most 460 days. Before that the maximum was 39 months. Internal certificates from your own CA follow your organisation’s own policy.

Why should the signing key be stored in an HSM?

A stolen code signing key lets an attacker produce malware that looks legitimate. An HSM performs the signing without the private key ever leaving the device. For publicly trusted code signing certificates, hardware storage has been mandatory since June 2023.

Can I sign my own PLC code or scripts?

You can sign your own scripts, libraries and software with a certificate from an internal or a public CA. Whether PLC projects themselves can be signed depends on the vendor and the engineering software. Check this per platform and record it in your change management process.

📌 In summary

Code signing is an indispensable Security layer in OT environments for trusting software and Firmware: it proves who produced the code and that it was not changed along the way. Without a digital signature there is no guarantee that code is original and unmodified. The signature alone is not enough: protect the signing key in an HSM, use timestamps, verify every update and combine code signing with a secure development process, an SBOM and patch management.