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

Why This Matters for Security Teams

Code signing is the trust anchor for firmware updates, secure boot, and device integrity. When signing keys are exposed, approvals are ad hoc, or release checks are inconsistent, the result is not just a technical flaw but a supply chain control failure. That can turn a routine update path into a route for malicious code, unauthorized changes, and long-lived compromise across connected devices.

This matters because compliance regimes increasingly expect demonstrable control over build, signing, and release integrity. The NIST Cybersecurity Framework 2.0 and the EU Cyber Resilience Act both push organisations toward traceable security-by-design practices that include trusted software supply chains. NHIMG research also shows why this is not theoretical: the Ultimate Guide to NHIs — Key Challenges and Risks highlights how weak lifecycle controls become persistent exposure points, especially when identities and secrets are not managed as part of the same system.

In practice, many security teams encounter code signing failures only after a bad build, stolen key, or emergency release has already created a device trust problem.

How It Works in Practice

A secure signing process separates the act of building code from the act of authorising release. That means protecting the private signing key, limiting who can invoke signing, recording every signing event, and verifying that the artifact presented for signing is exactly the one that passed review and testing. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of integrity, auditability, and access restriction, while ISO/IEC 27001:2022 Information Security Management reinforces the need for controlled change management and documented accountability.

For connected devices, the practical controls usually include:

• Storing signing keys in hardware-backed modules or managed key services with strong access segmentation.
• Using short-lived, tightly scoped access for signing operations instead of shared long-lived credentials.
• Requiring approval workflows that are deterministic, logged, and resistant to bypass during urgent releases.
• Verifying artifact provenance so the signed binary matches the reviewed source and build output.
• Maintaining revocation and rollback paths so compromised keys or bad firmware can be contained quickly.

NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant here because signing systems often rely on non-human identities, tokens, and service accounts that must be governed with the same discipline as the firmware itself. Where teams still use manual release gates, shared signing credentials, or ad hoc exception handling, the control becomes hard to audit and easy to subvert. These controls tend to break down in fast-moving device fleets with offline update paths because revocation, attestation, and rollback are difficult to enforce consistently across all endpoints.

Common Variations and Edge Cases

Tighter signing controls often increase operational overhead, requiring organisations to balance release speed against stronger assurance. That tradeoff is especially visible in product lines that ship frequent hotfixes or support third-party integrators. There is no universal standard for every signing architecture yet, but best practice is evolving toward automated, policy-driven release pipelines rather than human-only approval chains.

Edge cases appear when devices must update in low-connectivity environments, when multiple vendors contribute firmware components, or when legacy products cannot support modern key protection. In those situations, teams should at minimum isolate signing authority, require tamper-evident logs, and enforce key rotation and revocation procedures. The ISO/IEC 27002:2022 Information Security Controls provides a useful control baseline, while the Top 10 NHI Issues underscores that poor lifecycle handling of machine identities and secrets is a recurring root cause of preventable compromise.

For regulated environments, the most common failure mode is not total absence of signing but inconsistent signing discipline across product teams, suppliers, and emergency change paths. That inconsistency creates audit gaps even when the underlying cryptography is sound.

Related resources from NHI Mgmt Group

• Who is accountable when Infrastructure as Code changes create compliance or security failures?
• Why do manual ID card processes create risk for access control and compliance?
• Why do non-human identities create compliance risk even when policies exist?
• Why do connected medical devices create identity security risk for hospitals?