Code-Signing Certificates Move to 460 Days: What Changes and How to Prepare
Code signing is one of those controls that runs quietly in the background until a deadline forces it into view. A change agreed by the CA/Browser Forum is about to do exactly that. The maximum validity of code-signing certificates is being cut from 39 months to 460 days, with the change taking effect from 1 March 2026. For teams that have treated code signing as a set-and-forget task, this is a prompt to rethink the process before it becomes a source of disruption.
This article explains what is changing, why it matters operationally, and how to prepare in a way that improves your security posture rather than simply adding renewal overhead.
What is changing
Today, a code-signing certificate can be valid for up to 39 months, a little over three years. Under the new rule, the maximum drops to 460 days, roughly fifteen months. The direction of travel mirrors what has already happened with TLS certificates: shorter lifetimes, more frequent renewal, and a clear expectation that the process is automated rather than manual.
The rationale is the same as elsewhere in the certificate world. Shorter validity limits the window in which a compromised or mis-issued certificate remains useful, and it pushes organisations towards processes that can keep pace.
Why this is more than a diary change
The obvious impact is more frequent renewals. The less obvious, and more important, impact falls on organisations that sign using hardware tokens. If your signing keys live on physical tokens, a shorter validity means handling those renewals roughly every fifteen months instead of every three years, with all the logistics that implies: shipping tokens, re-enrolling, and coordinating across teams. For organisations with multiple signers or distributed development, that overhead multiplies.
There is also a risk dimension. Manual renewal processes are where things slip. A missed code-signing renewal can break a release pipeline or, worse, leave software unsigned or signed with an expired certificate at the moment it ships.
How to prepare
Move towards cloud and automated signing
The clearest way to absorb shorter validity is to remove the physical-token bottleneck. Cloud-based signing services allow keys to be held securely and signing to be performed through controlled, automatable workflows. Renewals through ACME or vendor APIs can then become a managed process rather than a manual scramble.
Protect signing keys in hardware
Shorter validity does not reduce the importance of protecting the signing key itself. A code-signing key is a high-value target; if it is misused, attackers can sign malicious software that appears to come from you. Keeping signing keys inside a hardware boundary remains best practice, which is where HSM-backed signing comes in. The goal is to combine strong key protection with an automatable signing workflow, rather than trading one off against the other.
Treat code signing as part of your wider PKI
Code signing is often managed separately from the rest of an organisation's certificates, which is how it ends up neglected. Bringing it into a coherent PKI strategy, with proper visibility and lifecycle management, ensures that validity changes like this one are absorbed routinely rather than handled as one-off fire drills.
A short checklist
- Identify every code-signing certificate you hold and where its key lives.
- Flag any that rely on hardware tokens for manual renewal.
- Evaluate cloud or HSM-backed signing with automated renewal.
- Put the 1 March 2026 change on your roadmap now, not in February 2026.
Frequently asked questions
Does the 460-day limit apply to certificates already issued?
Will this affect our release pipeline?
Where to start
If your code signing still depends on hardware tokens and manual renewals, the time to change is before the deadline, not after. Speak to Unsung about HSM-backed signing and bringing code signing into a managed PKI strategy.
