How should security teams protect code signing keys used for firmware and software updates?

Why This Matters for Security Teams

code signing keys are not ordinary secrets. They create trust for firmware, software updates, and sometimes recovery pathways, which means a single misuse can turn one compromised system into a fleet-wide supply chain event. That is why current guidance treats them as tier-0 assets, aligned with the same risk posture used for the most sensitive identities and signing authorities. NIST’s NIST Cybersecurity Framework 2.0 emphasizes protecting the systems and credentials that underpin trust, not just the endpoints that consume it.

For NHI practitioners, the lesson is straightforward: signing keys behave like high-impact Non-Human Identities because they authorize machine trust at scale. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is relevant here because code signing keys sit in the same blast radius class when they are exposed or misused. In practice, many security teams encounter signing-key abuse only after a malicious update has already been distributed, rather than through intentional key lifecycle control.

How It Works in Practice

Protecting signing keys starts with reducing how often the raw key material can ever exist outside a hardened trust boundary. The strongest pattern is to keep keys in HSM-backed workflows or similarly hardened vaults, then require all signing operations to occur through controlled services, not developer laptops, build runners, or ad hoc scripts. That separation supports both accountability and recovery.

Operationally, security teams should define three distinct stages: key issuance, signing use, and retirement. Each stage should have separate approval paths, separate operators where feasible, and logging that is tied to a reviewable change record. Continuous monitoring should cover every signing event, including who requested it, what artifact was signed, what policy allowed it, and whether the event matched the expected release pipeline.

• Use strong segregation of duties so no single person can create, approve, and release a signed artifact.
• Prefer short-lived or delegated signing workflows for release automation, with human approval at defined checkpoints.
• Restrict signing access to a minimal set of identities and systems, then review that access on a fixed cadence.
• Store recovery material and backup procedures with the same protection level as the primary key.

This also maps to broader identity discipline. The Schneider Electric credentials breach underscores how trust can be abused when sensitive credentials are insufficiently contained, while the NIST framework reinforces the need to manage identity-backed trust paths as part of resilience. These controls tend to break down when release engineering is decentralised across many CI/CD systems because ownership, logging, and revocation become inconsistent.

Common Variations and Edge Cases

Tighter signing-key controls often increase release overhead, requiring organisations to balance operational speed against the risk of distributing untrusted code. That tradeoff is especially visible in high-frequency release environments, where teams want automation but cannot afford to make every pipeline actor a signing authority.

There is no universal standard for this yet, but current guidance suggests a few practical variants. Some organisations use online signing only for low-risk artifacts and reserve offline or quorum-based approvals for firmware and other high-trust releases. Others split keys by product line, region, or environment so compromise does not immediately span the full estate. For highly regulated or safety-critical software, best practice is evolving toward stronger key isolation, release attestations, and immutable audit trails that can be reviewed after the fact.

Edge cases matter. Emergency hotfixes need an exception path, but that path should still preserve authorisation, logging, and post-event review. Open-source distribution, partner-built firmware, and outsourced release operations introduce extra trust boundaries, so the signing workflow must verify both the artifact and the actor requesting signature. A useful benchmark from NHI Management Group’s research is that 71% of NHIs are not rotated within recommended time frames, which is a reminder that signing keys should not be left on long-lived operational habit alone. The right question is not whether a key can sign, but whether the organisation can prove exactly when, why, and by whom it was allowed to do so.

Related resources from NHI Mgmt Group

• How should security teams plan for DNS outages that block record updates?
• How do security teams reduce identity blind spots across code and cloud?
• How should security teams protect secrets in staging environments?
• How should security teams prevent secrets from being hardcoded in Infrastructure as Code?