Notifications
Clear all
Topic starter
10/07/2026 4:16 pm
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.
NHIMG editorial — based on content published by GlobalSign: Code signing governance is a process problem, not a key problem
By the numbers:
- 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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about code signing visibility?
A: They often assume certificate inventory is the same as signing observability.
Practitioner guidance
- Inventory every signing identity and certificate Map which certificates exist, who requested them, which teams can use them, and what artefacts they sign.
- Centralise signing request and approval flow Require one managed path for certificate procurement, key issuance, and signing requests.
- Record every sign operation with artefact context Keep immutable logs that tie the signed hash, certificate, timestamp, build source, and approving identity together.
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.
👉 Read GlobalSign's analysis of code signing governance beyond key storage →
Code signing governance: where process control breaks down?
Explore further
10/07/2026 4:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Code signing governance is a process problem, not a key problem
