Code signing governance is a process problem, not a key problem

At a glance

What this is: This is an analysis of why code signing failures increasingly stem from signing process governance, not private key storage, and why visibility, central control, and lifecycle handling now matter more than the token or HSM alone.

Why it matters: For IAM and security teams, code signing is an identity and access problem for software release paths, so weak approval flow, poor inventory, and decentralised key use create avoidable trust exposure across NHI and DevOps programmes.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read GlobalSign's analysis of code signing governance beyond key storage

Context

Code signing is a trust control for software release, not just a certificate management task. The article argues that hardware-backed key storage has closed one layer of risk, while the larger failure mode now sits in who can sign, what gets signed, and whether the organisation can see that activity across builds and teams.

For IAM practitioners, that makes code signing a governance problem that cuts across NHI, DevOps, and lifecycle control. The signing path needs inventory, approval, and observability just as much as it needs protected keys, because decentralised signing decisions create identity risk even when the cryptography is sound.

Key questions

Q: How should organisations govern code signing across multiple engineering teams?

A: Treat code signing as a centrally governed identity workflow, not a local developer task. One team should own certificate procurement, signing approvals, and lifecycle oversight, while build systems consume that service through a controlled path. That reduces the chance that regional offices, acquired teams, or CI/CD pipelines create separate trust channels that the security programme cannot see or revoke.

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

A: 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.

Q: What do security teams get wrong about code signing visibility?

A: They often assume certificate inventory is the same as signing observability. It is not. Knowing that a certificate exists does not tell you which artefacts it signed, which system requested the signature, or whether the request followed policy. Good governance needs a record of signing events, not just a list of credentials.

Q: Who should be accountable when a signed release is later found to be unsafe?

A: Accountability should sit with the team that owns the signing control plane, because signing is an access decision as much as a release step. If release approval, certificate issuance, and audit evidence are split across groups, no one can reliably answer what was authorised. Governance should make that ownership explicit before the next release cycle.

Technical breakdown

Why hardware-backed keys do not solve signing governance

Hardware tokens and HSMs reduce the risk of private key extraction by making keys non-exportable. That improves the storage layer, but it does not answer the harder question of authorisation: who is allowed to request a signature, what artefact is being signed, and whether that request matches policy. The system typically sees only a hash, so it cannot judge business context on its own. In practice, code signing is governed by the process around the key, not the key container itself.

Practical implication: teams must treat signing approval and artefact provenance as control points, not rely on key custody alone.

Why code signing needs observability, not just access control

A secure signing system must be able to answer what was signed, by which certificate, and when. Without that record, organisations cannot reconcile signing activity across build agents, developer workstations, and CI/CD pipelines. That gap is especially dangerous when multiple teams or acquired units can obtain certificates outside the normal process. Visibility turns code signing into an auditable identity workflow rather than a hidden technical action, which is the only way to detect misuse after the fact.

Practical implication: log every signing event and maintain an inventory that ties certificates to artefacts and owners.

How certificate lifecycle changes reshape signing operations

Shorter certificate lifetimes increase the operational burden of code signing, especially for organisations still rotating manually. The article also points to crypto-agility, meaning the signing pipeline should tolerate changes in certificates, algorithms, and platform validation rules without rebuild-by-hand work. That is an architectural requirement, not a nice-to-have. If signing changes are hard to execute, the organisation will delay revocation, migration, or re-signing until risk is already material.

Practical implication: automate certificate lifecycle handling and make reconfiguration possible from a central control point.

Threat narrative

Attacker objective: The attacker or unauthorised insider aims to get unapproved code accepted as trusted software and shipped under legitimate organisational identity.

1. Entry occurs when a certificate is obtained through a local team, business unit, or third-party channel outside the central signing workflow.
2. Escalation happens when that signing authority is used to approve artefacts that were never reviewed or intended for release.
3. Impact follows when signed software is distributed under the organisation's trust mark, creating downstream supply chain trust and accountability exposure.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code signing has crossed from key protection into identity governance. The article shows that the central failure is no longer whether a private key can be copied off disk. The real control problem is who can exercise signing authority, what policy governs that authority, and whether the organisation can prove what was signed. That is an IAM and NHI governance issue, not a cryptography issue. Practitioners should treat signing as a governed identity workflow, not a token custody exercise.

Single-entry signing governance is the right response to decentralised release risk. When regional teams, acquired units, or individual developers can source certificates independently, the organisation loses lifecycle control before the first signature is created. That breaks the assumption that signing authority is centrally visible and centrally revocable. In OWASP-NHI terms, the risk is uncontrolled credential issuance with no consistent ownership model. Practitioners should rethink procurement and approval pathways as part of the trust boundary.

Observable signing activity is a named control gap, not a convenience feature. If a team cannot say what was signed in the last 90 days, code signing is already outside governance. The article correctly reframes the problem as loggable, queryable signing behaviour across build systems and workstations. That aligns with NIST CSF and NIST SP 800-53 Rev 5 expectations around access control and auditability. Practitioners should make signing records part of the control evidence set, not an after-the-fact forensic luxury.

Code signing lifecycle automation has become a resilience requirement. Shorter certificate lifetimes and algorithm shifts mean manual rotation will fail under pressure even when the cryptography itself remains sound. This is where lifecycle governance meets operational reality: the programme must absorb revocation, renewal, and reconfiguration without bespoke team-by-team intervention. Practitioners should view crypto-agility as a release-governance capability, not a future technology project.

Named concept: signing authority sprawl. The article describes a pattern where signing rights, certificate sourcing, and release execution spread across teams without a single accountable process. That sprawl creates trust ambiguity that no HSM can resolve because the failure is organisational, not technical. The implication is that code signing programmes need ownership clarity first, then technical hardening.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing how persistence turns exposure into ongoing access risk.
• Guide to the Secret Sprawl Challenge explains why inventory, ownership, and revocation must work together, not in isolation.

What this signals

Signing governance now needs the same operational discipline as NHI lifecycle control. If a programme cannot inventory, approve, and retire signing authority centrally, it will struggle as certificate lifetimes shorten and release paths become more distributed. The practical shift is to manage signing like an identity lifecycle, with clear ownership and revocation paths.

signing authority sprawl is the pattern most teams should watch for. It emerges when certificates are purchased or used outside the main control plane, especially in acquired business units or independent DevOps teams. That creates invisible trust channels that are difficult to audit after the fact and easy to miss during change reviews.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader lesson is that machine-to-tool trust paths now fail in many places, not just in repositories. Code signing sits in the same governance class because the control gap is not key strength, but operational visibility and accountable use.

For practitioners

• Inventory every signing identity and certificate Map which certificates exist, who requested them, which teams can use them, and what artefacts they sign. Include regional units, acquired teams, and CI/CD pipelines so shadow signing paths are visible.
• Centralise signing request and approval flow Require one managed path for certificate procurement, key issuance, and signing requests. Remove side channels where teams can buy or use certificates outside the main governance process.
• Record every sign operation with artefact context Keep immutable logs that tie the signed hash, certificate, timestamp, build source, and approving identity together. Make the question of what was signed answerable in minutes, not days.
• Design for certificate and algorithm changeovers Use central configuration so certificate rotation, revocation, and re-signing can be executed without editing build scripts across every team. Build the release path to tolerate shortened validity and algorithm migration.

Key takeaways

• Code signing failures now come more often from governance gaps than from stolen private keys.
• Visibility, central approval, and lifecycle automation determine whether signing remains trustworthy at scale.
• Organisations that cannot explain what was signed, by whom, and under which policy already have a control problem.

Key terms

• Code Signing Governance: Code signing governance is the set of ownership, approval, logging, and lifecycle controls that determine who may sign software and under what conditions. It goes beyond certificate custody and focuses on whether release trust is observable, revocable, and centrally accountable across teams and pipelines.
• Signing Authority Sprawl: Signing authority sprawl occurs when certificate use, signing approval, and release execution spread across multiple teams or channels without one control point. The result is hidden trust paths, inconsistent policy enforcement, and poor revocation visibility, especially in large engineering organisations and acquired business units.
• Crypto-Agility: Crypto-agility is the ability to change certificates, algorithms, or validation mechanisms without redesigning the surrounding release process. In practice, it means the signing pipeline can absorb revocation, renewal, and platform shifts through configuration and automation rather than manual code changes.
• 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.

What's in the full article

GlobalSign's full article covers the operational detail this post intentionally leaves for the source:

• How to structure a central signing workflow across DevOps, release engineering, and security.
• How to make signing events observable with logs, approvals, and artefact traceability.
• How to adapt certificate rotation and reconfiguration when validity windows shorten.
• How to handle algorithm migration and crypto-agility without rewriting every build script.

👉 GlobalSign's full article covers the signing process, lifecycle changes, and crypto-agility details

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.