TL;DR: The CA/Browser Forum has reduced the maximum validity period for publicly trusted code-signing certificates from 39 months to 460 days, effective March 1, 2026, according to DigiCert. The real issue is not shorter certificates but the assumption that manual renewal and static signing workflows can keep pace with faster rotation.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: A policy change shortens publicly trusted code-signing certificate lifetimes to 460 days, pushing organizations toward more frequent renewal and automated signing operations.
Why it matters: IAM and security teams responsible for machine trust, software release integrity, and certificate lifecycle governance need to treat code signing as a recurring operational control, not a one-time procurement.
By the numbers:
- The new maximum validity period for publicly trusted code-signing certificates is 460 days.
- The previous maximum validity period was 39 months, roughly three years.
- The change takes effect on March 1, 2026.
Context
The core issue is not simply shorter certificate lifetimes. It is the governance assumption that signing credentials can stay stable long enough for manual renewal and ad hoc release operations to keep up.
Code-signing sits inside software supply chain security because the certificate is part of how organisations prove release authenticity and integrity. When the renewal window shrinks, the operational model around key storage, issuance, and rotation has to become more disciplined.
For teams still depending on legacy build systems or hardware-token workflows, the change exposes where certificate lifecycle management has been treated as a periodic task instead of a controlled identity process.
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: How do teams know if their signing process is ready for 460-day certificates?
A: A signing process is ready when renewal is automated, certificate ownership is explicit, and expiry dates are visible inside the release workflow. If teams still depend on spreadsheets, manual token handling, or last-minute approvals, the process is not yet operating as a controlled lifecycle.
Q: Should organisations keep using hardware tokens for code signing?
A: They can, but only if the renewal burden, custody controls, and operational overhead remain acceptable at a 15-month cadence. Where token handling introduces release friction or missed renewals, managed signing services may fit the lifecycle better. The decision should be based on renewal risk, not habit.
Technical breakdown
Why shorter code-signing lifetimes change release operations
Publicly trusted code-signing certificates are used to prove that software came from the expected publisher and has not been altered. When validity shrinks, the certificate lifecycle becomes more tightly coupled to build and release cadence. That matters because signing keys, issuance approvals, and renewal steps now happen more often, which raises the cost of any manual handoff or forgotten dependency. The practical effect is that release integrity starts to depend on whether the organisation can treat code signing as an automated control rather than a periodic administrative task.
Practical implication: map every code-signing certificate to an owner, renewal trigger, and automated issuance path.
Hardware tokens versus cloud-based signing services
The article draws a clear operational split between teams that store private keys on hardware tokens and teams using managed signing services. Token-based workflows tend to be more brittle because renewal, distribution, and physical custody all have to be handled explicitly. Cloud-based signing platforms reduce that friction by centralising renewal and key rotation inside a managed environment. The governance question is not whether token use is acceptable in principle, but whether the lifecycle overhead creates avoidable risk when certificate validity keeps shrinking.
Practical implication: reassess whether token-bound signing still fits your release volume and renewal tolerance.
Automating certificate rotation in build pipelines
The operational response is to integrate issuance and rotation into the build system using automation interfaces such as ACME or vendor APIs. This matters because certificate validity is now short enough that human-driven renewal can become a failure point rather than a control. In identity terms, code-signing certificates behave like managed machine credentials: they need inventory, lifecycle ownership, and revocation handling. The architecture should therefore connect certificate state to pipeline execution, not to a separate manual calendar.
Practical implication: connect certificate issuance and renewal directly to CI/CD workflows so expiring keys do not interrupt releases.
Threat narrative
Attacker objective: The attacker seeks to abuse trusted signing paths so malicious or altered software is accepted as legitimate.
- Entry occurs through the release pipeline when signing credentials or certificates are used to authenticate software artifacts.
- Escalation happens when a compromised or stale signing process allows untrusted code to inherit release trust.
- Impact follows when signed software is treated as authentic and is distributed to downstream users or customers.
Breaches seen in the wild
- SolarWinds supply chain compromise: A backdoored Orion build reached 18,000 customers; attackers then forged SAML tokens and hijacked app service principals.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Code-signing certificates now function as machine identities with a shorter governance horizon. The validity change is not just a calendar adjustment. It turns signing credentials into a lifecycle discipline that has to be owned, automated, and continuously observed. Organisations that still treat code signing as an infrequent procurement event will find the operational burden shifts into release engineering and security operations.
Manual renewal is the control most exposed by 460-day validity. A human-paced renewal model assumes there is enough slack between issuance and expiry to notice, schedule, approve, and execute the change. That assumption weakens as validity shrinks, because the margin for forgotten tokens, stale documentation, and release bottlenecks disappears. The practical conclusion is that renewal behaviour now matters as much as certificate strength.
Short-lived signing credentials improve resilience only when the surrounding lifecycle is governed. The security value of shorter validity comes from forcing rotation, inventory accuracy, and key custody discipline. Without those controls, the organisation merely converts rare renewal events into frequent failure opportunities. That means certificate lifecycle management belongs in the same governance conversation as machine identity, not as a separate infrastructure detail.
Software supply chain security depends on the trust boundary around signing, not just on signing itself. The article correctly ties shorter validity to stronger controls against tampering and malware injection. But the deeper point is that signed release integrity is only as strong as the process that creates, stores, rotates, and revokes the signing credential. Practitioners should treat release trust as a governed identity path, not a static artifact property.
Certificate renewal cadence is becoming an operational signal for broader identity maturity. Teams that can absorb the 460-day limit cleanly will usually have tighter ownership, better inventory, and more automation around secrets and machine credentials. Teams that cannot will expose where governance is still built around human memory and manual exception handling. The implication for practitioners is straightforward: the certificate timeline is now a test of identity operating model maturity.
What this signals
Certificate lifecycle has become release governance: when code-signing validity keeps shrinking, renewal belongs inside the CI/CD operating model, not outside it. The practical shift is from periodic certificate administration to continuous ownership of issuance, rotation, and revocation.
Teams should expect the most failure-prone environments to be the ones that still separate key custody from release execution. In those environments, the certificate expiry date becomes a late signal of a deeper governance gap, not the root problem itself.
For practitioners
- Inventory every public code-signing certificate Record where each certificate is used, who owns renewal, and when it expires so no signing path depends on tribal knowledge.
- Move renewal into build automation Use ACME or certificate APIs to trigger issuance and rotation from the pipeline instead of relying on manual reminders.
- Reassess hardware-token workflows Compare token custody, renewal effort, and outage risk against managed signing services before the new limit takes effect.
- Update policy ownership for signing lifecycle Assign explicit responsibility for renewal, rotation, and revocation so the certificate lifecycle is governed like any other machine credential.
Key takeaways
- Shorter code-signing validity changes the control model from occasional renewal to recurring lifecycle governance.
- The biggest risk is not the 460-day limit itself but the operational dependence on manual renewal and static release workflows.
- Teams that automate issuance, renewal, and revocation inside their build pipelines will handle the transition with less disruption.
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 NIST CSF 2.0 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 | Short-lived code-signing certificates are the mirror image of long-lived credential risk. |
| NHI-01 — Improper Offboarding | Revocation and retirement are part of the certificate lifecycle discussed in the article. | |
| Recommendation — Treat code-signing certificates as expiring machine credentials and automate renewal before expiry. Revoke and retire signing certificates through a defined offboarding process when keys or workflows change. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Code-signing certificates are authenticators whose issuance and rotation need lifecycle control. |
| Recommendation — Apply IA-5 to enforce issuance, rotation, and revocation for signing credentials. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Compromised signing credentials enable trusted delivery and downstream impact. |
| Recommendation — Map signing credential abuse to credential access and impact tactics in your threat model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate lifecycle governs who and what is authorised to sign release artifacts. |
| Recommendation — Review signing entitlements and renewal ownership under PR.AA-05. | ||
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 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.
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
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 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org