Starting March 1, 2026, publicly trusted code signing certificates are limited to a maximum validity of 460 days – roughly 15 months – down from the previous 39-month maximum. This change is mandated by CA/Browser Forum Ballot CSC-31, adopted on November 17, 2025. Any certificate issued on or after that date must comply with the new limit. Certificates issued before the deadline remain valid until their original expiration. For development teams managing their own signing workflows, this means annual renewal is no longer optional – it is the rule.
What Is the Code Signing Certificate Validity Change?
Code signing certificate validity refers to how long a publicly trusted certificate remains active after issuance. Under the old standard, certificates could be issued with lifetimes up to 39 months. Under Ballot CSC-31, the CA/Browser Forum reduced that ceiling to 460 days.
The 460-day figure shortens key exposure windows while still giving teams a buffer beyond a strict annual cycle. In practice, most organizations should plan around a 12-month renewal rhythm to avoid cutting it close.
Why Did the CA/Browser Forum Reduce Code Signing Validity?
The CA/Browser Forum reduced code signing certificate validity to limit the damage window when a private key is compromised. A certificate that lives for three years gives an attacker nearly three years to silently sign malicious software under a stolen identity. Cutting that window to 15 months shrinks that risk significantly.
Three factors drove the decision:
- Key exposure risk. Longer-lived certificates create wider abuse windows if private keys are stolen or leaked. Frequent rotation limits how long a compromised credential remains useful to an attacker.
- Algorithm currency. Shorter cycles force teams to renew against current cryptographic standards rather than locking in older algorithms for years.
- Identity accuracy. Organization data embedded in a certificate – legal name, address, registered contacts – can become outdated over three years. Annual renewal keeps that identity information current.
|
Effective Date |
Max Certificate Validity |
Max DCV Re-use |
|
March 15, 2026 |
200 days |
200 days |
|
March 15, 2027 |
100 days |
100 days |
|
March 15, 2029 |
47 days |
10 days |
This change follows a broader industry trend. SSL/TLS certificate lifetimes have fallen from five years to one year over the past decade, with further reductions already scheduled. Code signing certificates are now on the same path. According to CA/Browser Forum Ballot CSC-31 (November 2025), the ballot passed with unanimous support from all voting Certificate Issuers.
Who Is Most Affected by the 460-Day Limit?
Not every team feels this change equally. The impact depends almost entirely on how private keys are stored and how renewal is currently handled.
- Hardware token users face the biggest operational shift. Teams that store private keys on USB tokens or FIPS-compliant hardware security modules must now physically replace or rekey that hardware every 15 months instead of every three years. Many organizations historically ordered multi-year tokens and renewed infrequently – that workflow ends March 1, 2026.
- Manual CI/CD pipelines require updates. Any build or release pipeline that references a static certificate file will break when that certificate expires. Teams that have not automated certificate rotation need to update their pipelines before the deadline.
- Cloud-based signing platforms see minimal disruption. Managed signing services that already handle certificate lifecycle management behind the scenes absorb the change automatically. The shorter validity period is largely invisible to users of these platforms.
To understand the full range of storage approaches and how they interact with this change, the certificate delivery methods guide covers each option in detail.
Does the Validity Reduction Affect Signed Software That Already Exists?
No. The 460-day limit applies to how long a certificate can remain active – not to the trust status of code that was already signed while that certificate was valid.
When code is signed with a valid certificate and a trusted timestamp is included, the signature remains trusted indefinitely, even after the certificate expires. The timestamp proves the code was signed during a period when the certificate was active and unrevoked. That trust model has not changed.
What the shorter validity period does prevent is this: a certificate issued years ago continuing to sign new software long after the organization’s identity data or cryptographic keys may have become stale.
The practical implication for publishers is that existing signed releases are unaffected, but any new signing activity after a certificate expires requires a freshly issued credential.
What Is the Difference Between OV and EV Code Signing Under the New Rules?
Both OV (Organization Validation) and EV (Extended Validation) code signing certificates are now subject to the 460-day maximum. The new validity limit applies to all publicly trusted certificate types without exception.
|
Feature |
OV Code Signing |
EV Code Signing |
|
Maximum validity (post-March 2026) |
460 days |
460 days |
|
Key storage requirement |
FIPS 140-2 Level 2 hardware |
FIPS 140-2 Level 2 hardware |
|
Microsoft SmartScreen reputation |
Builds over time |
Builds over time |
|
Required for kernel-mode drivers |
No |
Yes |
|
Validation level |
Organization identity |
Extended organization identity |
One common question is whether EV code signing certificates still provide instant SmartScreen reputation. As of March 2024, Microsoft updated SmartScreen to treat EV and OV certificates equally – neither earns instant reputation bypass. Both build trust through download volume.
How Should Teams Prepare Before the March 1, 2026 Deadline?
Preparation now prevents a signing outage later. The steps below apply to any team that manages code signing certificates directly.
- Inventory all active certificates. Document every code signing certificate across all products, pipelines, and environments. Record the issuing CA, issuance date, expiration date, and storage method. Visibility is the prerequisite for everything else.
- Identify certificates expiring after the deadline. Any certificate with validity extending beyond March 1, 2026 under the old rules can still be used until expiration – but reissuing after the deadline truncates the new certificate to 460 days.
- Evaluate key storage. Teams using USB tokens should assess whether cloud HSM or managed signing services reduce the burden of the new renewal frequency.
- Update CI/CD pipelines. Identify every build step that references a certificate path, thumbprint, or credential. Update those references to support rotation without manual intervention.
- Set a 12-month renewal calendar. Align internal scheduling to roughly 12 months – giving a 30–60 day buffer before the 460-day ceiling.
- Contact your CA early. CAs are managing a surge in validation requests as the deadline approaches. Starting revalidation 60–90 days before a certificate expires reduces the risk of a signing gap.
For teams evaluating which CA to renew with, the best code signing certificate providers comparison covers pricing, validation timelines, and platform trust across major options.
Will Code Signing Certificate Validity Be Reduced Further?
Almost certainly, yes. The pattern is consistent across every publicly trusted certificate category. SSL/TLS certificates dropped from five years to one year over roughly a decade, and the CA/Browser Forum has already approved a further reduction to 47 days for TLS certificates by 2029.
Code signing certificates are now on the same trajectory. The shift to 460 days should be read as a midpoint, not a destination. Organizations that build flexible, automated renewal infrastructure now will absorb future reductions with far less disruption than those who treat this as a one-time compliance event.
The Shorter Cycle Is an Infrastructure Upgrade Opportunity
The reduction to 460-day maximum validity is already in effect as of March 2026. Every new certificate issued through a publicly trusted CA now carries a 15-month ceiling – without exception. Teams that treat this as a one-time deadline to hit will face the same friction again in 15 months. Teams that treat it as a trigger to build automated renewal infrastructure will find each future rotation takes minutes, not days.
Start with an audit of what you currently have. If you need a foundation on what a code signing certificate does and how signing workflows function, that context is worth building before evaluating renewal options. The operational changes are real, but teams that adapt first will absorb future reductions with far less friction.
Frequently Asked Questions
What happens to code signing certificates issued before March 1, 2026?
Certificates issued before March 1, 2026, are unaffected and remain valid until their original expiration date. However, if you reissue one of those certificates on or after that date, the new certificate will be subject to the 460-day maximum regardless of when the original order was placed.
Can I still buy a 2-year or 3-year code signing certificate?
No. As of the enforcement date, certificate authorities can no longer issue publicly trusted code signing certificates with a validity period exceeding 460 days. Some CAs stopped accepting multi-year requests in late December 2025 or February 2026 ahead of the official deadline.
Does the 460-day limit apply to timestamps?
No. The 460-day limit applies only to the code signing certificate itself – not to the timestamp token. A trusted timestamp from an RFC 3161-compliant timestamping authority remains valid indefinitely, which is why timestamping signed builds is non-negotiable.
Does a shorter certificate validity period invalidate existing signed software?
No. Software that was signed while the certificate was valid and includes a trusted timestamp continues to be trusted after the certificate expires. The signature remains verifiable for as long as the timestamping authority’s chain is trusted.
How do hardware token users handle more frequent renewals?
Hardware token users must either replace or rekey their tokens more frequently or migrate to cloud-based HSM or managed signing services that handle certificate rotation automatically. Given the renewal frequency now required, many teams are using this change as the trigger to evaluate cloud signing alternatives.
Is this change specific to Windows code signing?
No. The 460-day maximum applies to all publicly trusted code signing certificates regardless of platform – Windows, macOS, Linux, or any other distribution target. The mandate comes from the CA/Browser Forum and applies to any CA issuing publicly trusted code signing credentials.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
