Topic starter
11/07/2026 8:22 pm
TL;DR: The CA/B Forum will reduce maximum code signing certificate validity from 39 months to 460 days on 1 March 2026, and GlobalSign says it will stop issuing 2-year and 3-year code signing certificates after 26 December 2025. Shorter lifetimes tighten compromise windows but increase renewal and inventory pressure across software supply chains.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “Änderungen bei der Gültigkeit von Code Signing-Zertifikaten: Was das für Sie bedeutet”.
By the numbers:
- The CA/B Forum is reducing maximum code signing certificate validity from 39 months to 460 days.
- GlobalSign will stop issuing 2-year and 3-year code signing certificates after 26 December 2025.
- The new validity change takes effect on 1 March 2026.
Key questions
Q: What breaks when code signing certificates move from 39 months to 460 days?
A: The biggest failure is lifecycle drift.
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
- Inventory every code signing certificate Map each certificate to a named owner, issuing CA, renewal date, signing system, and release dependency so no credential is invisible at expiry.
- Automate renewal before the cutoff date Tie renewal workflows to build and release pipelines so certificates are refreshed well before 26 December 2025 and the 1 March 2026 validity change.
- Restrict signing authority to named workflows Limit who and what can request, approve, and use code signing credentials, especially where build systems and delegated admins share access.
Bottom line: Shorter code signing lifetimes shrink the abuse window for compromised signing credentials, but they also punish weak ownership and renewal discipline.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 8:52 pm
Shorter code signing lifetimes turn certificate governance into software supply chain governance. The main security question is no longer whether a certificate exists, but whether every signing credential has a known owner, renewal path, and revocation path. That is an identity and lifecycle problem as much as a PKI one, because the authority to sign code is a privileged machine identity function. Practitioners should treat signing certificates as controlled identities with defined lifecycle boundaries.
A question worth separating out:
Q: How should teams manage code signing certificates as privileged identities?
A: Treat the signing certificate and private key as a high-value identity with an owner, an approved use case, and a revocation path. That means limiting who can sign production releases, logging all signing events, and tying renewal and retirement to access governance rather than ad hoc admin practice.
👉 Read our full editorial: Code signing certificate lifetimes are shortening to 460 days