Topic starter
06/06/2026 2:19 am
TL;DR: Code signing certificates have been reduced to a 460-day maximum for publicly trusted issuance from March 1, 2026, extending the CA/B Forum’s broader move toward shorter certificate lifetimes and making renewal, ownership, and key storage problems more urgent, according to Keyfactor. The governance issue is no longer renewal cadence alone, but whether teams can maintain control of non-human identities when validity windows keep compressing.
Editorial analysis by NHI Mgmt Group, based on content published by Keyfactor: “Shorter Certificate Lifespans Are Coming for Code Signing”.
By the numbers:
- Starting March 1, 2026, publicly trusted code signing certificates are limited to a maximum validity of 460 days.
- The CA/B Forum passed a ballot in April 2025 to reduce the maximum validity of SSL/TLS certificates to just 47 days by 2029.
- SSL/TLS certificate lifetimes have fallen from five years to one year to 200 days.
Key questions
Q: What breaks when code signing certificates are left to manual renewal?
A: Manual renewal breaks when expiry windows become shorter than human workflows can reliably manage.
Q: Why do shorter code-signing lifetimes matter for software supply chain security?
A: Shorter lifetimes reduce the window in which a compromised signing key can be abused and push organisations toward more frequent key rotation.
Q: What signs show code signing governance is failing?
A: Common signs include certificates scattered across products without a clear owner, private keys sitting on workstations or build servers, and renewals happening only when a release fails.
Practitioner guidance
- Build a complete code signing inventory Audit every code signing certificate across products, pipelines, and environments.
- Move signing keys into hardware protection Store private signing keys in an HSM rather than on developer workstations or generic file systems.
- Automate renewal and expiry controls Tie certificate renewal to pipeline governance so expiring signing identities are detected before a release is blocked.
Bottom line: Shorter code signing lifespans expose governance gaps in ownership, renewal, and private key custody across the software release path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 3:55 am
Shorter code signing lifetimes turn certificate management into a machine-identity governance problem. A signing certificate is not just a document with an expiry date; it is an identity binding between a private key, a release process, and software trust. When validity windows shrink from years to months, organisations that still treat signing as periodic admin work lose the governance margin they used to rely on. The practitioner implication is that code signing now belongs inside the same control conversation as ownership, access scope, and lifecycle enforcement for NHI credentials.
A question worth separating out:
Q: Should organisations centralise code signing or keep it embedded in development teams?
A: Centralisation is usually the better governance model when certificates are short-lived, because ownership, key custody, and audit logging become easier to enforce. Embedded team workflows can still work, but only if they operate inside a shared policy for inventory, hardware-backed key storage, and automated renewal. Without that, accountability fragments quickly.
👉 Read our full editorial: Shorter code signing certificate lifespans raise NHI governance risk