Code-signing certificate validity is shrinking to 460 days

At a glance

What this is: The CA/Browser Forum is shortening public code-signing certificate validity to 460 days, forcing more frequent renewal and rotation.

Why it matters: IAM and security teams need to treat code-signing certificates as governed machine identities, because renewal cadence, ownership, and automation now affect release integrity and outage risk.

By the numbers:

• The CA/Browser Forum has approved a new ballot that reduces the maximum validity period for publicly trusted code-signing certificates from 39 months to 460 days.

👉 Read DigiCert's analysis of the 460-day code-signing certificate change

Context

Code-signing certificates are trusted identities used to prove that software came from a known publisher and has not been altered. When their validity period shrinks, the operational burden moves from occasional renewal to continuous lifecycle management, which exposes weak inventory, manual approvals, and brittle build pipelines.

For identity teams, this is a machine identity governance problem as much as a software supply chain issue. Certificate renewal, private key storage, and revocation ownership now need the same discipline that organisations apply to other non-human identities, especially where release pipelines depend on signed artifacts.

Key questions

Q: How should teams prepare for shorter code-signing certificate lifetimes?

A: Teams should first inventory every signing certificate, owner, and renewal path, then remove any manual dependency that could delay re-issuance. The practical goal is to make renewal routine, visible, and testable before the new validity window forces it. If certificates are tied to release pipelines, lifecycle control must be built into those pipelines.

Q: What breaks when code-signing renewals are still handled manually?

A: Manual renewal breaks when the organisation cannot guarantee that someone will notice expiry in time. The result is delayed builds, failed releases, and avoidable trust interruptions. As certificate lifetimes shorten, manual handling becomes a governance defect because the identity lifecycle is too fast for spreadsheets and ad hoc reminders.

Q: How do security teams know if certificate lifecycle automation is working?

A: It is working when renewals happen predictably, outages from expiry disappear, and ownership is visible in policy rather than tribal knowledge. A healthy process also produces auditable records for issuance, rotation, and revocation. If teams still scramble near expiry, the workflow is not automated enough to be trusted.

Q: Who should own code-signing certificate governance in the organisation?

A: Ownership should sit jointly with identity, security, and release engineering, because code signing affects trust, access, and software delivery at the same time. A single technical owner is rarely enough. The accountable team must define renewal policy, approve key handling, and ensure revocation can happen without delay.

Technical breakdown

Why shorter code-signing certificate validity changes the operating model

A shorter validity period compresses the time window in which a certificate can remain trusted before renewal or replacement is required. That does not change what code signing does, but it changes the rhythm of governance around it. The control issue is lifecycle latency: if certificate inventory, renewal logic, and ownership are weak, the environment becomes dependent on humans noticing expiry before builds fail. Shorter lifetimes therefore expose whether signing is a managed identity process or an ad hoc operational habit.

Practical implication: map every signing certificate to an owner, system, and renewal path before the new validity window takes effect.

Why manual signing workflows create avoidable identity risk

Manual certificate handling turns a predictable lifecycle event into a recurring failure point. Spreadsheets, ticket queues, and one-off renewals work only when certificate counts are low and expiry windows are generous. As validity shrinks, those approaches increase the chance of missed renewals, inconsistent key handling, and release interruptions. In identity terms, this is privilege persistence without governance, because the signing identity continues to exist long after the process that maintains it has become unreliable.

Practical implication: remove manual renewal steps from build and release processes where code-signing certificates are used regularly.

How automation supports certificate lifecycle governance

Automation changes code signing from a calendar-driven task into a repeatable identity control. When renewal, issuance, and rotation are integrated into pipelines and signing services, the certificate lifecycle becomes observable and enforceable instead of dependent on individual operators. That also improves accountability, because policy can define who approves issuance, where keys may reside, and when revocation should occur. The important distinction is that automation supports governance only when ownership and policy are defined first.

Practical implication: automate renewal and rotation only after you have defined ownership, policy, and revocation responsibilities.

NHI Mgmt Group analysis

Shorter certificate lifetimes expose identity lifecycle debt, not just operational inconvenience. The move from 39 months to 460 days compresses the time available for renewal, review, and re-issuance. That matters because many organisations still treat code-signing certificates as occasional assets rather than governed machine identities. The implication is that certificate lifecycle control now sits inside the core identity programme, not beside it.

Manual signing processes are the failure mode this change is designed to flush out. Spreadsheets, token logistics, and human-tracked renewals create a renewal dependency that breaks as validity windows shrink. This is the same pattern seen across machine identity management, where scale outruns visibility and ownership becomes diffuse. Practitioners should recognise that the problem is not shorter certificates, but the fragility of the process around them.

Code-signing certificates should be managed as workload identities with defined ownership and revocation rules. Public trust for software release depends on the same discipline as other non-human identities: inventory, assignment, renewal, and revocation. That aligns most closely with OWASP-NHI and NIST CSF thinking, because the trust decision is only as strong as the lifecycle behind it. The practitioner takeaway is to govern signing certificates as part of identity operations, not as isolated crypto objects.

Automation becomes mandatory when release integrity depends on expiry-driven controls. Short-lived certificates are only sustainable when renewal is systematic and observable. The market signal is clear: software trust is moving toward continuous control rather than periodic upkeep, which means release teams and identity teams must share the same operational model. Practitioners should re-evaluate whether their signing flow can survive a tighter renewal cadence without human intervention.

Certificate expiry as an outage driver: The underlying governance assumption is that renewals can be handled manually before trust breaks. That assumption fails when certificate populations grow, build systems become distributed, and renewal windows shrink to the point where missed handoffs become outages. The implication is that lifecycle governance must be designed for continuous renewal, not periodic attention.

From our research:

• The average time to detect a compromised machine identity: 214 days, according to The Critical Gaps in Machine Identity Management report.
• Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
• For broader identity context, read Ultimate Guide to NHIs , What are Non-Human Identities for the lifecycle patterns that code-signing governance now has to match.

What this signals

Certificate lifecycle control is now a board-relevant identity issue, not an infrastructure convenience. As validity windows shrink, organisations that still rely on manual renewals will see the same pattern that already affects machine identities more broadly: delayed detection, ownership gaps, and avoidable operational failure. The governance question is whether certificate management sits inside identity operations or remains scattered across delivery teams.

Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report, which means most organisations will feel this change as friction before they feel it as control. That gap should push practitioners to treat code-signing renewal as an identity workflow with measurable SLAs, not an occasional administrative task.

The wider lesson is that shorter validity periods reward organisations that can combine inventory, ownership, and pipeline automation under one governance model. Teams that cannot do that will keep rediscovering the same failure mode at each expiry cycle, while mature programmes can use the change to tighten control over release trust.

For practitioners

• Inventory every code-signing certificate and owner Create a complete map of signing certificates, issuance dates, expiration dates, system owners, and the build pipelines that consume them. Without that inventory, the March 2026 validity change becomes an outage risk rather than a lifecycle update.
• Automate renewal inside release pipelines Move issuance and renewal into pipeline logic or managed signing services so certificates rotate without waiting for manual tickets or calendar reminders. This reduces expiry failures and makes the signing identity easier to govern at scale.
• Review private key storage and token dependence Assess where private keys live, who can access them, and whether hardware-token workflows are creating unnecessary friction. If renewal depends on physical token handling, the process is already lagging behind the new validity model.
• Update policy for renewal, revocation, and escalation Revise security and operations policies so ownership, revocation authority, and escalation paths are explicit before certificates approach expiry. Policies should align the certificate lifecycle with release management, not react after failures occur.

Key takeaways

• Shorter code-signing validity turns certificate renewal into a continuous identity governance problem rather than a periodic admin task.
• The biggest risk is not the 460-day limit itself, but the manual process debt that it exposes across build and release operations.
• Organisations that map ownership, automate renewal, and align revocation policy to release pipelines will absorb the change far more safely.

Key terms

• Code-signing certificate: A code-signing certificate is a public trust credential used to prove that software or scripts were published by a specific signer and have not been altered after signing. In practice, it is a machine identity that must be issued, renewed, stored, and revoked under strict lifecycle control.
• Certificate lifecycle management: Certificate lifecycle management is the set of processes that track issuance, usage, renewal, rotation, and revocation for digital certificates. For identity teams, the important part is not the certificate itself but the governance around ownership, expiry, and automated replacement before trust breaks.
• Signing workflow automation: Signing workflow automation is the integration of certificate issuance and renewal into release pipelines or managed services so humans are not the control point for every expiry event. It reduces operational drift, but only works well when policy, access, and revocation are defined first.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Understanding the New Code-Signing Certificate Validity Change. Read the original.