Why do insecure code signing processes create compliance and security risk for connected devices?

How insecure code signing undermines trust in connected device updates

Code signing is the trust gate that tells a device whether firmware, software, or an update package should be accepted. When that process is weak, the device can no longer distinguish approved code from altered code, which turns the update channel into a high-value control point. That matters because connected devices often operate with long service lives, limited user visibility, and privileged access to physical or operational environments.

For security teams, the issue is not just whether a signature exists, but whether the signing workflow protects the private keys, the approval path, and the release integrity end to end. A weak process can allow an attacker, contractor, or insider to ship tampered code that still appears authentic. It can also create audit gaps when organisations cannot prove who approved what, when the artifact was signed, and whether the version on the device matches the intended build. The EU Cyber Resilience Act is one of the clearest examples of why this matters, because secure update assurance is now part of product security accountability rather than a niche engineering concern. In practice, many teams discover code-signing weaknesses only after a release pipeline or signing key has already been treated as trusted for too long.

EU Cyber Resilience Act

What has to work for signing to remain a real control

For code signing to reduce risk, it has to protect more than the cryptographic signature itself. The private signing key must be tightly controlled, the build artifact must be the exact artifact that gets signed, and the release process must prevent bypass, substitution, or last-minute tampering. If any one of those steps becomes informal, the signature starts to certify the wrong thing.

That is why insecure signing processes create both compliance and security exposure. Compliance risk arises when an organisation cannot demonstrate repeatable control over release approvals, key custody, version traceability, or update integrity. Security risk arises when trust in the update channel becomes easy to fake. A compromised signing key is especially damaging because the malicious package may still pass device verification, which makes the attack look legitimate to the endpoint. In connected-device environments, that can extend compromise across fleets, remote sites, or embedded deployments before anyone notices.

Common failure points include shared signing credentials, manual approval steps without independent verification, long-lived keys with weak storage, and build systems that let unsigned or differently built artifacts slip into the release path. Mature programmes usually treat signing as part of the software supply chain, not as a final engineering checkbox. That is also where control frameworks become useful: NIST CSF 2.0 helps anchor governance around protect, detect, and recover outcomes, while EU product-security requirements make update assurance a lifecycle obligation. NIST Cybersecurity Framework 2.0

• Protect the signing key as a high-impact secret, not as a routine build credential.
• Bind the signed artifact to the verified build output, not to a manually handled file.
• Require traceable approval and retention evidence for each release path.
• Validate that devices reject unsigned, expired, or downgraded packages.

Where this guidance breaks down is in environments that cannot reliably control the signing root of trust across all release channels, because then the signature may preserve integrity in theory but not in practice.

When signing problems become fleet-wide edge cases

Tighter signing controls often increase operational overhead, requiring organisations to balance release speed against trust assurance.

Not every connected-device programme uses the same signing model, and that is where the edge cases matter. Some products rely on a single central signing authority, while others use staged signing, delegated release approvals, or third-party manufacturing and update services. Each variation changes where the trust boundary sits and where a compromise can occur. The security question is not whether the process is elegant, but whether the organisation can still prove that the device received the exact code it intended to ship.

Teams also underestimate how quickly exception handling becomes a control weakness. Emergency hotfixes, temporary signing access, and offline manufacturing workflows can all be legitimate, but each one widens the gap between policy and actual trust enforcement. If exceptions are not time-bound and reviewed, they become the normal path for getting code into production. That is when the compliance problem starts to merge with the security problem, because the organisation can no longer show consistent control over its trusted release process. In the connected-device context, that inconsistency is often more dangerous than a single technical flaw, because it repeats across many versions, locations, and device classes. The practical test is simple: if a team cannot explain who can sign, what was signed, and how a device validates it, the process is already too weak to rely on.

Practitioner Guidance: Treat code signing as a trust-chain problem first and a build-step second. The most important decision is whether release authority, key custody, and artifact integrity are all independently verifiable; if they are not, the signature is providing assurance without control.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do connected medical devices create identity security risk for hospitals?
• Why do manual compliance processes create security risk?
• Why do code-signing certificates create a security risk when business identity is weak?