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.
At a glance
What this is: GlobalSign explains that code signing certificate validity is being shortened to 460 days, with the change intended to tighten security and reduce the misuse window for compromised certificates.
Why it matters: For IAM, PKI, and software supply chain teams, shorter code signing lifetimes turn certificate inventory, renewal timing, and issuer governance into operational controls that must be monitored continuously.
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.
- GlobalSign will continue to issue 1-year code signing certificates with a 366-day validity.
Context
Code signing certificates are used to prove that software was produced by a trusted publisher and has not been altered since signing. When certificate lifetimes shorten, the security model shifts from long-lived trust anchors toward more frequent renewal and tighter lifecycle control.
This change matters because certificate expiry is no longer a background administration issue. It affects software release pipelines, certificate inventory, renewal automation, and the controls that govern who can sign, renew, and revoke code signing credentials across the software supply chain.
Key questions
Q: What breaks when code signing certificates move from 39 months to 460 days?
A: The biggest failure is lifecycle drift. Teams that rely on manual tracking or loosely owned certificates will miss renewal dates, disrupt release pipelines, and leave stale signing credentials in place. Shorter validity also exposes orphaned certificates faster, so inventory accuracy becomes the first control that must hold up.
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. That matters because signed software carries downstream trust, so stale credentials create a wider opportunity for tampering, misuse, or accidental release interruption. Security value only appears when lifecycle controls keep pace.
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. Another warning sign is when teams can name the tool that signs code but not where the signing key lives or who can use it.
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.
Technical breakdown
Why shorter code signing lifetimes change trust assumptions
Code signing works because consumers trust that a certificate links software to an approved publisher. Longer validity periods give attackers more time to exploit a stolen signing key or an orphaned certificate, while shorter periods reduce that window and force more frequent validation of ownership. The trade-off is not just renewal overhead. It also changes the operational burden on teams that must know where certificates live, who can renew them, and whether any signing credentials are still in use after ownership changes or compromise.
Practical implication: Treat certificate expiry as an active control point, not a calendar reminder.
Why certificate inventory becomes the real control surface
When lifetimes contract, weak inventory becomes a release risk. Teams cannot reliably renew what they cannot see, and code signing often spans build systems, release tooling, HSM-backed keys, and delegated admin access. The security gap is usually not cryptography itself but lifecycle visibility: stale certificates, unmanaged renewals, and unclear ownership create failure points that show up only at expiry or during incident response. In practice, certificate governance becomes part of software supply chain resilience.
Practical implication: Build a complete certificate inventory that includes owner, renewal date, and signing dependency.
How renewal automation reduces exposure to expired or misused credentials
Renewal automation matters because manual code signing renewal does not scale well once validity windows shrink. The objective is not simply to renew earlier, but to make renewal predictable, auditable, and tied to the release process. That requires access controls around signing systems, timely revocation when keys are lost, and clear segregation between development identities and production signing authority. Without those controls, shorter lifetimes can expose weak process discipline rather than improve security.
Practical implication: Automate renewal and revoke paths so signing authority is never trapped in a manual queue.
Threat narrative
Attacker objective: The objective is to distribute malicious software under a trusted signature so it blends into normal software delivery and user trust.
- Entry occurs when attackers obtain a code signing key or certificate through compromise, theft, or unmanaged retention in the release environment.
- Credential access or abuse follows when the signing identity is used to stamp malicious or altered software as trusted.
- Impact occurs when signed software is delivered to users or downstream systems with inherited trust, making the malicious payload harder to question.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
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
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.
Certificate inventory is becoming the deciding control, not certificate issuance. Once validity drops to 460 days, unmanaged sprawl becomes the hidden failure mode. Expired certificates, orphaned renewals, and undocumented signing dependencies will create release disruption before they create obvious security incidents. The practical conclusion is that inventory accuracy, ownership, and renewal orchestration now define resilience.
The 460-day shift aligns trust with revocability, which is the real security gain. Long-lived signing credentials extend the blast radius of compromise, especially in build and release environments where access is distributed across people, services, and tooling. Shorter validity does not eliminate risk, but it narrows the period in which a stolen or forgotten signing credential remains useful. Teams should read this as a prompt to reduce standing trust in release systems.
Code signing credentials should be governed like privileged access, not treated as static certificates. The article highlights an identity security pattern that is easy to miss: the signer itself is an NHI with privileged authority over software trust. That means onboarding, renewal, ownership changes, and revocation need the same discipline often reserved for PAM or service account governance. The practitioner takeaway is to manage signing identities as high-value credentials, not passive artefacts.
What this signals
Code signing should now be treated as privileged identity governance. The shrinking lifetime is a signal that trust in software release pipelines has to become more dynamic, with ownership, renewal, and revocation handled as first-class controls. For practitioners, the practical shift is from keeping certificates valid to proving that every signing identity remains authorised and visible throughout its lifecycle.
Shorter validity windows expose weak inventory faster than they improve cryptography. In many environments, the problem will not be the new limit itself but the discovery that nobody can say with confidence which systems still depend on a given signing certificate. Teams should expect certificate lifecycle management to become a release readiness issue, not a back-office task.
For practitioners
- 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.
- Revoke or retire unused signing credentials Remove stale 2-year and 3-year certificates from active rotation plans and ensure any obsolete signing keys are no longer reachable in release tooling.
- Validate release dependencies against new validity windows Check whether packaging, notarisation, or downstream distribution processes assume long-lived certificates and adjust them for 366-day or 460-day cycles.
Key takeaways
- Shorter code signing lifetimes shrink the abuse window for compromised signing credentials, but they also punish weak ownership and renewal discipline.
- The main operational risk is not cryptography failure. It is certificate inventory drift, missed renewals, and release dependencies that assume long-lived trust.
- Teams should manage code signing certificates as privileged identities with explicit ownership, automation, and revocation paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-57, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | Code signing certificates are governed through lifecycle handling of signing keys and credentials. |
| Recommendation — Apply key lifecycle governance to signing credentials so renewal, rotation, and retirement are controlled end to end. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Signing authority is a privileged access function that must be tightly owned and reviewed. |
| Recommendation — Review who can use production signing credentials and remove excess authorization to sign releases. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate owners and signing authorities need accountable lifecycle management as access windows shrink. |
| Recommendation — Track every signing account and credential to ensure ownership, renewal, and retirement are current. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Stolen signing credentials can be abused to distribute trusted malicious software across environments. |
| Recommendation — Map signing credential exposure to credential access and lateral movement monitoring in your detection program. | ||
Key terms
- Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
- Certificate lifetime: Certificate lifetime is the period a public or private certificate remains valid after issuance. In practice it defines how long a trust assertion can be relied on before it must be replaced, renewed, or revalidated. Shorter lifetimes reduce exposure but increase lifecycle management pressure.
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
- Signing Key: A signing key is a secret used to create or verify trusted authentication material. When that key is tied to identity infrastructure, it can become a high-value trust anchor that affects many systems at once. If it is reused or left unrotated, compromise can spread far beyond the original service.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners translate lifecycle controls into operational discipline across modern environments.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org