Why does unsigned code create a serious trust problem for connected devices and operational technology?

Why unsigned code breaks trust at the device boundary

On connected devices and operational technology, code signing is not a nice-to-have control. It is the mechanism that lets a device or controller treat software as authentic, intact, and approved before execution. Without a valid signature, the device has no cryptographic proof that the update came from the expected publisher or that the binary is the one operators intended to deploy.

That matters because trust in embedded and industrial environments is usually built on a narrow release path, constrained change windows, and limited runtime visibility. If unsigned code is accepted, the device is asked to execute first and trust later, which is the opposite of how resilient control systems are supposed to work.

Unsigned code also removes an important boundary between routine maintenance and malicious tampering. A compromised build server, intercept point, or distribution channel can replace or alter software without an obvious integrity signal, so operators lose the ability to distinguish an authorised patch from an unauthorised modification.

Why the risk is higher for connected devices and OT than for ordinary endpoints

Connected devices and operational technology often control physical processes, safety interlocks, sensors, actuators, and production logic. When software changes touch those functions, a trust failure is not just an IT problem, it can become a process safety, availability, or quality problem. That is why strong device identity, attestation, and firmware signing are treated as core safeguards in device and OT security guidance, not optional hardening.

The operational context also makes recovery harder. Many devices have long service lives, vendor-specific tooling, and limited patch flexibility, so a bad or unauthorised image can persist longer than it would on a standard workstation. In practice, that means one unsigned package can create a long-lived exposure across fleets, not just a single compromised host.

For device trust and onboarding patterns, Device and IoT Identity Guide is the natural reference point for the identity and attestation side of the problem, while OT and ICS Identity and Access Guide shows how trust failures interact with shared accounts, vendor access, and segmented industrial environments.

What unsigned code means for integrity, provenance, and release control

Unsigned code weakens three controls at once: provenance, integrity, and release discipline. Provenance tells you who published the code. Integrity tells you whether the payload changed after release. Release discipline tells you whether the image matches the approved build, version, and change record. Without a signature, none of those checks is reliable enough to support autonomous acceptance on a device.

This is why secure update pipelines usually pair signing with verification, version controls, and revocation-aware trust stores. The signature is not only about authentication, it is also the practical proof that the update is part of the authorised software lifecycle. If that proof is absent, the operator must compensate with out-of-band controls, which are slower and easier to bypass at scale.

For teams adopting zero trust principles, Zero Trust Identity Guide helps frame why trust should be continuously verified rather than assumed. For the underlying OT architecture perspective, NIST SP 800-82 Rev 3, OT Security Guide is the clearest external reference.

Risk and Threat Considerations

Unsigned code creates an easy abuse path for supply-chain compromise, malicious field updates, and persistence inside low-visibility devices. If the platform will execute whatever arrives, an attacker only needs a delivery path, not a valid publisher identity, which lowers the effort required to introduce unsafe behaviour into a device or controller.

Failure mechanism: A device trusts the package format or transport channel but has no cryptographic proof that the code was authorised, so altered or rogue software can be accepted as if it were legitimate.

Impact: The result can be unsafe control actions, denial of service, loss of production integrity, or a foothold that survives normal monitoring because embedded and OT assets are often difficult to inspect in real time.

Practitioner Guidance

What to verify: Treat signature verification as a deployment gate, not a post-deploy audit. Confirm that devices reject unsigned images, enforce certificate or key revocation where supported, and record the exact build identity that was accepted.

Decision rule: If a device can affect a physical process, safety function, or industrial control path, unsigned code should be treated as an exception condition requiring explicit risk acceptance, not as a routine compatibility workaround.

Common mistake: Teams sometimes secure the transport channel and assume that is enough. Transport security protects the path, but it does not prove the software came from the expected publisher or that the payload matches the approved release.

Practitioner takeaway: For connected devices and OT, unsigned code is a trust failure because it removes provenance and integrity at the exact point where the device decides whether to execute. If that decision is weak, every downstream safety and reliability control starts from a compromised assumption.

Related resources from NHI Mgmt Group

• Why do connected devices create a different identity governance problem than users?
• Why do mobile robots create higher operational risk than static connected devices?
• Why do code review models create a trust problem for appsec teams?
• Why do GitHub release assets create a different trust problem than source code alone?