TL;DR: Hardware-backed key storage has become the baseline for code signing, but most high-impact failures still come from process gaps around who can sign, what gets signed, and whether organisations can see and control signing activity, according to GlobalSign. The real risk is governance drift: code signing behaves like a programme, not a certificate.
At a glance
What this is: This is an analysis of why code signing risk now sits in governance and process control rather than only in private key protection.
Why it matters: It matters because IAM, PAM, and NHI teams increasingly need observable approval paths, inventory, and lifecycle control around signing authority, not just stronger key storage.
Context
Code signing is a governance problem when organisations can protect the key but still cannot control what gets signed, who signs it, or whether anyone can trace signing activity. The operational gap is no longer at the hardware token or HSM layer; it is in the access, approval, and visibility process around the signing event.
For identity and access programmes, that makes code signing a lifecycle issue as much as a cryptographic one. The article treats signing as a managed workflow that spans certificate issuance, approval, build integration, and auditability, which is why central policy and observability matter more than isolated key custody.
Key questions
Q: What breaks when code signing is treated as a key-storage problem only?
A: Teams keep the cryptographic material safe but still lose control over who signs, what gets signed, and whether the signed artefact was ever approved. That creates a governance gap where trusted signatures can attach to unauthorised releases. The failure is not in the HSM, but in the workflow surrounding it.
Q: Why does centralised signing authority matter for software supply chain governance?
A: Because decentralised buying and signing paths create shadow authority under the organisation’s brand. If regional teams can source certificates or sign outside the central process, security loses inventory, policy enforcement, and auditability. Centralised authority turns code signing into a governed identity workflow instead of a local convenience.
Q: How do you know if code signing controls are actually working?
A: They are working if every certificate is discoverable, every private key is stored in a controlled enclave, and renewals happen before expiry without release disruption. A mature programme can show ownership, audit logs, and predictable renewal timing across all products and environments.
Q: Should organisations manage code signing as part of identity governance or DevOps?
A: Both, but the governance model has to come first. Code signing lives inside the release pipeline, yet the authority to sign, approve, and revoke is an identity and access question. When those controls are split, the organisation gets automation without accountability and cryptographic trust without operational control.
Technical breakdown
Why key protection is no longer the main failure mode
Hardware-backed storage closes the obvious risk of exporting or copying a private key, but it does not decide whether a request deserves to be signed. In practice, the signing system often only sees a hash and a certificate reference, not the business meaning of the artefact. That means secure storage can coexist with unsafe authorisation, weak release control, and poor traceability. The technical boundary moved: the control problem is now the signing workflow, not the cryptographic container. Practical implication: treat signing approval, artefact validation, and audit logging as part of the control plane, not as optional process steps.
Practical implication: Move controls from key custody alone to the approval and audit layer around every signing event.
How observability turns code signing into a governed workflow
A signed binary is only defensible if the organisation can answer what was signed, when, and by whom. That requires logged signing events, certificate-to-artefact mapping, and rapid queryability across build agents, developer systems, and CI/CD pipelines. Traditional certificate discovery tools are usually not enough because they identify certificates, not actual signing activity across distributed build paths. When attribution takes days or weeks, the organisation has lost operational control even if the key itself remains secure. Practical implication: instrument signing so each artefact can be traced back to a specific certificate and approved workflow entry.
Practical implication: Build traceability from certificate to artefact so incident review does not depend on manual reconstruction.
Why centralised signing policy matters more than local flexibility
The article highlights a common failure pattern: a team acquires a certificate outside the approved process and starts signing under the organisation’s brand with no central visibility. This is not a key-management failure, it is a process bypass that creates shadow signing authority. Once multiple business units improvise their own acquisition and usage paths, the organisation loses lifecycle control, renewal control, and policy consistency. A single governed entry point is therefore an access-control problem as much as a procurement problem. Practical implication: make certificate request, issuance, and signing execution pass through one approved path with no local exceptions.
Practical implication: Enforce a single signing path so no team can create unmanaged signing authority outside policy.
Threat narrative
Attacker objective: To place trusted-looking software into circulation while avoiding the scrutiny that should accompany a signing event.
- Entry occurs when an unmanaged team or build path gains signing access through an unsanctioned certificate or workflow.
- Privilege is then abused when that signing authority is used to approve artefacts that the security team never reviewed or approved.
- Impact follows when signed software ships under the organisation’s name without a reliable record of what was actually signed or by whom.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Code signing is now a governance programme, not a certificate problem: The article’s central insight is that hardware-backed key storage solved the wrong layer of the problem. The failure mode now sits in who can sign, what can be signed, and whether the organisation can explain the signing trail after the fact. Practitioners should stop treating code signing as a procurement or crypto-only topic and manage it as an identity and workflow control.
Centralised signing authority is the real control boundary: When regional teams or acquired units can source and use certificates independently, the organisation creates shadow signing authority under its own brand. That is a policy failure, not a tooling gap, and it breaks the assumption that signing is visible to the central security function. The implication is that code signing governance must be owned as a single programme with one authorised path.
Observability is the missing control plane for signing: A hash-based signing request tells you almost nothing about the business legitimacy of the artefact. Without event logs that map artefact, certificate, time, and approver, security teams cannot answer the simplest governance questions quickly enough to matter. The practical conclusion is that traceability must be engineered into the release pipeline, not reconstructed after an incident.
Shorter certificate lifetimes expose process maturity, not just renewal burden: The article shows that tighter validity windows only hurt organisations that still rotate signing material manually. Mature programmes absorb the change because lifecycle handling is already automated and centralised. That means the new operational pressure is a useful diagnostic: if renewal creates friction, the programme is not yet governed as infrastructure.
Signing-chain drift: The deeper issue is the gap between cryptographic trust and organisational control. Code can be correctly signed and still be wrong, unauthorised, or untraceable. Practitioners should use that gap as the design test for whether signing belongs inside identity governance rather than beside it.
What this signals
Signing-chain drift: Code signing now fails when process ownership and cryptographic trust diverge. The lesson for practitioners is that certificate protection only becomes meaningful when issuance, approval, and signing execution are governed as one lifecycle.
Organisations should expect certificate renewals, key changes, and signing-policy shifts to expose weak points in their release architecture. If a change requires manual edits across teams, the programme is still fragile even when the private key is hardware-backed.
For practitioners
- Centralise certificate request and signing approval Route every request for code signing material through one governed path so local teams cannot acquire or use certificates outside policy.
- Instrument signing events end to end Log the artefact, certificate, approver, timestamp, and build context for every signing operation so you can answer what was signed and where it came from.
- Map signing authority to named owners Assign explicit accountability for each certificate, token, and pipeline that can sign software, including inherited environments after acquisition or reorganisation.
- Automate certificate lifecycle changes Design renewal, revocation, and replacement so certificate turnover does not depend on manual updates across individual build scripts or teams.
- Validate release gating before sign-off Require code review, build provenance, automated checks, and release approval to complete before the signing step is allowed to execute.
Key takeaways
- Code signing failures increasingly come from process bypass, unmanaged signing authority, and weak traceability rather than from stolen private keys alone.
- The article argues that strong hardware-backed key storage does not solve the core governance problem when organisations cannot see or control what gets signed.
- Practitioners should centralise signing authority, instrument the signing trail, and automate lifecycle changes so code signing behaves like governed infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Signing authority becomes risky when too many people or systems can sign under one trust boundary. |
| NHI-01 — Improper Offboarding | Inherited certificates and team changes create unmanaged signing paths if offboarding is weak. | |
| Recommendation — Review signer access and trim every certificate to the smallest possible approved scope. Revoke signing access when teams, tools, or business units no longer need it. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing certificates need lifecycle handling across issuance, rotation, and revocation. |
| Recommendation — Apply IA-5 to govern signing credentials through issue, rotate, and revoke stages. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centers on controlling who can use signing authority across the organisation. |
| Recommendation — Use account management controls to inventory, approve, and remove signing access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Abused signing trust can enable delivery and spread of trusted malicious software. |
| Recommendation — Map compromised signing workflows to credential access and lateral movement detections. | ||
Key terms
- Software Signing Governance: The set of policies, controls, and ownership rules that determine who can sign software, what can be signed, and under what conditions. It turns signing from a technical operation into a governed trust decision with lifecycle, audit, and enforcement requirements.
- Signing Chain Drift: Signing chain drift is the gap that appears when cryptographic trust remains intact but organisational control over signing decisions erodes. In practice, it shows up when artefacts are signed outside the approved workflow and the business cannot reconstruct who authorised them.
- Signing Observability: Signing observability is the capacity to trace what was signed, by which identity, at what time, and from which build or approval path. It turns code signing from a hidden event into a verifiable control, which is essential for audit, investigation, and release accountability.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org