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.
At a glance
What this is: This is an analysis of shorter code signing certificate lifespans and the governance gaps they expose for machine identities, release pipelines, and private key stewardship.
Why it matters: It matters because shorter validity windows turn code signing from a periodic renewal task into an ongoing identity governance problem that affects release integrity, ownership clarity, and key protection.
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.
Context
Code signing certificate lifespans are shrinking, and that changes the governance burden for non-human identities that secure software release pipelines. Code signing is not just a cryptographic formality: it is part of how organisations establish trust in software provenance, protect release integrity, and control the private keys that make signing possible.
The governance problem is wider than simple renewal timing. When certificate validity compresses, ownership tracking, key location, approval discipline, and offboarding of signing material all become operational controls rather than background administration. That is why certificate lifecycle management, not isolated renewal work, now sits at the centre of code signing risk.
For development teams, the practical impact shows up at build and release time. Expired or unmanaged signing credentials can delay patches, interrupt delivery, and weaken trust when unsigned or improperly signed code reaches users. The article frames this as a trajectory, not a one-off change, because the same shortening pattern has already reached other certificate classes.
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. The result is missed renewals, stalled builds, delayed patches, and inconsistent approval trails. It also increases the chance that nobody can quickly prove who owns a certificate or where its private key lives.
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: 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.
Technical breakdown
Why shorter certificate lifetimes change code signing governance
Code signing certificates bind trust to a private key, so the certificate lifetime defines how long a signing identity can remain valid before revalidation or renewal is required. As lifespans shrink, the organisation has less tolerance for weak inventory, ambiguous ownership, or keys stored outside controlled environments. The governance burden shifts from occasional certificate refresh to continuous lifecycle oversight across products, pipelines, and environments. That matters because the control failure is often not the cryptography itself but the process around issuance, storage, and renewal. Practical implication: treat code signing as an identity lifecycle problem, not just a PKI task.
Practical implication: move code signing into a governed lifecycle with clear ownership, inventory, and renewal accountability.
Where private key storage becomes the real risk
A signing certificate is only as safe as the private key behind it. If keys sit on developer workstations, shared file systems, or build servers, the compromise window is no longer theoretical because the attacker does not need to steal the certificate alone, only the signing capability. Hardware security modules reduce that exposure by keeping private keys in a protected enclave and separating key use from key disclosure. The article’s point is not that all key storage choices are equal, but that shorter validity makes insecure storage harder to excuse because renewal now happens often enough to expose bad habits repeatedly. Practical implication: centralise private key custody and remove signing keys from general-purpose endpoints.
Practical implication: relocate signing keys to HSM-backed storage and eliminate workstation-based key custody.
How release pipelines fail when signing is not automated
Shorter lifetimes create a predictable failure mode in CI/CD: a certificate expires mid-release cycle and the pipeline cannot sign code, which can delay patches and halt delivery. Manual renewal cannot reliably keep pace with that cadence because human timing, ticketing, and approval steps introduce drift between expiry and release needs. Automation matters here because it connects certificate status, renewal workflow, and signing permissions into a repeatable control plane. The underlying issue is not speed alone; it is removing dependency on remembered action when the operating window is shrinking. Practical implication: automate renewal and signing governance before expiry becomes a release blocker.
Practical implication: automate renewal workflows and tie them to release governance so expiry does not stop delivery.
Threat narrative
Attacker objective: The objective is to abuse trusted signing capability to deliver software that appears legitimate or to disrupt release pipelines by making signing unavailable.
- Entry occurs when signing keys are exposed in insecure storage such as workstations, build servers, or removable hardware tokens that can be lost.
- Credential abuse follows when an attacker or insider can use the signing capability before expiry, turning trusted code signing into a delivery channel for unsigned or malicious software.
- Impact arrives when expired, stolen, or unmanaged signing credentials interrupt releases, delay patches, or undermine operating-system trust in software provenance.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.
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 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.
Key custody, not certificate renewal, is the decisive control point. The article makes clear that insecure storage on workstations, build servers, or hardware tokens is where short-lived trust becomes brittle. That is why this topic aligns directly with OWASP-NHI and machine identity lifecycle thinking: if the private key is not protected, the certificate lifetime is almost irrelevant. The practitioner implication is that teams should define who can use the signing key, where it can exist, and how its use is audited.
Visibility becomes a prerequisite for governance once the renewal cadence tightens. You cannot govern code signing if you do not know which certificates exist, who owns them, where the keys live, and which pipelines depend on them. This is the same inventory problem that appears across NHI programmes, but shorter lifetimes make it operationally unavoidable. The practitioner implication is to move from ad hoc certificate knowledge to a continuously maintained inventory with accountable owners.
Build release integrity is now coupled to identity lifecycle discipline. A certificate expiry that halts releases is not merely an operational nuisance. It is evidence that signing identity lifecycle and software delivery lifecycle are misaligned. The practitioner implication is to treat code signing as a governed access path to production trust, with renewal, storage, and approvals managed as one control set.
Shortening lifespans are a signal, not a one-off policy change. The direction of travel across certificate classes suggests continued compression, which means organisations must assume further reductions rather than plan for a stable floor. That does not just accelerate automation; it validates the need for resilient certificate governance and auditability across the full machine identity estate. The practitioner implication is to design for repeated change, not a single renewal event.
What this signals
Certificate lifecycle discipline now matters more than renewal cadence alone. Once code signing validity windows compress, teams have to govern who owns each certificate, where the signing key resides, and how release pipelines react when expiry approaches. That shifts the control objective from periodic administration to continuous identity oversight across the build path.
Machine identity programmes should treat code signing as part of the same control family as workload credentials. The asset is different, but the governance pattern is familiar: inventory, custody, authorisation, and offboarding all determine whether trust survives routine change. Short-lived certificates simply expose weak process design faster.
Shorter lifetimes are a forcing function for better provenance controls. If software trust depends on a key that is easy to misplace or hard to track, shortening the validity window magnifies the weakness instead of solving it. Teams should expect more renewal pressure, not less, and design their process accordingly.
For practitioners
- Build a complete code signing inventory Audit every code signing certificate across products, pipelines, and environments. Record issuer, expiry date, owning team, and the exact location of the private key so nothing depends on tribal knowledge.
- Move signing keys into hardware protection Store private signing keys in an HSM rather than on developer workstations or generic file systems. Use the hardware boundary as the default place where signing authority lives.
- Automate renewal and expiry controls Tie certificate renewal to pipeline governance so expiring signing identities are detected before a release is blocked. Replace manual renewal tickets with scheduled workflow controls and clear ownership.
- Map signing authority to named owners Assign accountable owners for each certificate and the releases it supports, then remove orphaned or unused signing identities from active pipelines.
- Plan for further certificate shortening Assume the current validity window will keep shrinking and design renewal, storage, and audit processes that still work when the next reduction arrives.
Key takeaways
- Shorter code signing lifespans expose governance gaps in ownership, renewal, and private key custody across the software release path.
- The operational impact is real because expired or unmanaged signing credentials can interrupt releases, delay patches, and erode trust in signed code.
- Teams that centralise inventory, protect signing keys in hardware, and automate renewal are better positioned to absorb future certificate reductions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Shortening validity windows makes persistent signing credentials harder to govern safely. |
| NHI-02 — Secret Leakage | The article highlights keys stored on workstations and build servers, which raises leakage exposure. | |
| Recommendation — Audit signing credential lifetimes and remove any long-lived code signing secrets from active use. Scan build and developer environments for exposed signing keys and revoke any leaked credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs lifecycle handling for authenticators, including code signing credentials. |
| Recommendation — Apply IA-5 to enforce renewal, rotation, and revocation for code signing authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centers on ownership, access, and lifecycle control of signing identities. |
| Recommendation — Use CIS-5 to assign owners, remove stale access, and govern who can use signing credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen signing credentials can be abused to access trusted release paths and spread malicious code. |
| Recommendation — Map stolen signing keys to TA0006 and TA0008 to prioritise monitoring on release infrastructure. | ||
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.
- Private Signing Key: A private signing key is the secret material that creates a trusted software signature. If it is exposed or copied, an attacker can sign malicious code as if it were legitimate, which is why key storage, access control, and hardware-backed protection are central governance requirements.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Hardware Security Module: A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
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.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org