Why is hardware-backed key storage not enough for code signing security?

Hardware-backed storage protects the private key from export, but it does not control who is allowed to request signatures or what software gets signed. The real risk sits in authorisation, release discipline, and evidence. If the organisation cannot explain why a binary was signed, the key may be safe while the trust decision is not.

Why This Matters for Security Teams

Hardware-backed key storage solves a narrow but important problem: it makes private keys harder to extract. It does not answer the more consequential questions in code signing, which are who may request a signature, what artifact is eligible, and whether the signed output can be proven to match a controlled release. NIST guidance on control design, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, treats this as an authorisation and accountability problem, not just a cryptographic one. NHIMG research shows why that distinction matters: 96% of organisations store secrets outside of secrets managers in vulnerable locations, which means the signing key may be protected while surrounding workflows remain exposed. See the Ultimate Guide to NHIs. When signing is triggered from CI/CD, developer laptops, or loosely governed automation, the key can remain non-exportable and still be abused to bless malicious or unreviewed code. In practice, many security teams discover this only after an attacker, compromised pipeline, or over-permissioned release job has already obtained a legitimate signature.

How It Works in Practice

A sound code-signing model separates key custody from signing authority. Hardware security modules, TPMs, and cloud HSMs are useful because they protect the signing key material, but the control plane around them must decide whether a signing request is valid at runtime. That means binding every request to a workload identity, release identity, or service principal, then evaluating policy before the signature is issued.

Current best practice is to combine several controls:

• Use non-exportable keys in an HSM or equivalent hardware-backed boundary.
• Require strong workload identity for the signer, such as OIDC-backed identity or SPIFFE/SPIRE, so the request is tied to what the signing job is, not just where it runs.
• Apply just-in-time approval or ephemeral authorisation for each release, especially for production binaries.
• Log the artifact hash, build provenance, approver, policy decision, and timestamp so the signature can be explained later.
• Enforce policy-as-code at request time, rather than relying only on static ACLs or manual process notes.

This is where NHI governance becomes operational. The signing key behaves like any other privileged non-human identity: it needs lifecycle controls, tight scope, rotation discipline, and revocation paths. NHIMG’s The State of Non-Human Identity Security reports that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is a reminder that key protection alone does not equal release integrity. For implementation detail, SPIFFE is commonly used to establish workload identity, while NIST SP 800-207 Zero Trust Architecture supports the idea that every signing request should be verified in context, not trusted because it originated inside the network. These controls tend to break down in high-velocity build systems where many microservices can request signing on behalf of multiple products because provenance and approval chains become too fragmented to audit consistently.

Common Variations and Edge Cases

Tighter signing control often increases release friction, requiring organisations to balance speed against traceability. That tradeoff becomes most visible in emergency patching, open-source release pipelines, and container image signing, where teams may want rapid automation but still need provable authorisation. Current guidance suggests that this is not a reason to weaken control, but a reason to make the policy adaptive: high-risk releases can require human approval, while routine internal builds can use pre-approved contexts with short-lived credentials.

There is no universal standard for this yet, but the emerging pattern is clear. Hardware-backed storage is necessary when the threat includes key exfiltration, yet it is insufficient when the threat includes misuse of legitimate signing capability. That is why security teams increasingly pair signing infrastructure with release attestations, restricted signing scopes, and immutable logs. The lesson is especially important in environments with distributed CI/CD, outsourced build agents, or shared signing services, because a protected key can still be used to certify the wrong artifact if the request path is not governed end to end. See also the Schneider Electric credentials breach and the Google Firebase misconfiguration breach for examples of how control failures around access and configuration create outsized trust exposure.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Why is single-provider AI agent governance not enough for enterprise security?
• Should organisations prioritise hardware-backed key storage before shortening renewal cycles?
• How should security teams prioritise NHI remediation in cloud environments?