On October 14, 2025, the CA/Browser Forum passed Ballot CSC-31, reducing the maximum validity period for publicly trusted code signing certificates from 39 months (approximately three years) to 460 days (approximately 15 months). The change took effect March 1, 2026. CAs began enforcing it in late February: DigiCert started on February 24, GlobalSign stopped issuing multi-year certificates in December 2025.
The practical result: code signing certificates issued from March 2026 onward are valid for approximately one year. Organizations that previously purchased two-year or three-year certificates and planned their signing operations around that longer renewal cycle must now adapt.
This article explains what changed, what it means for different types of signing operations, and the specific actions developers and security teams need to take.
What Changed and What Didn’t
| Item | Before March 2026 | From March 2026 |
| Maximum certificate validity | 39 months (~3 years) | 460 days (~15 months) |
| Certificates CAs will issue | 1-year, 2-year, 3-year options | 1-year maximum (up to 460 days); custom within that limit |
| Existing certificates issued before the cutoff | Valid until original expiry | Unchanged: grandfathered, still valid until their original expiry date |
| Multi-year pricing plans | Covered 2 or 3 years with one certificate | Now cover multiple sequential certificates, each up to 460 days |
| EV code signing | Same 39-month maximum | Same 460-day maximum; applies to both OV and EV |
| Private CA certificates | Not affected (only publicly trusted CAs covered by CA/B Forum) | Not affected |
Certificates issued before March 1, 2026 remain valid until their stated expiry date regardless of whether that date is more than 460 days from now. A 3-year certificate issued in January 2025 remains valid until January 2028. No action is needed for currently valid certificates. The change applies to new certificates issued from the effective date onward.
Why the CA/B Forum Made This Change
The reduction follows the same security rationale that drove shorter TLS certificate lifetimes. Shorter validity periods limit the window of exposure when a private key is compromised: if a key is stolen, the attacker can only use it for the remaining certificate validity, not for years. Shorter validity also drives more frequent key rotation, which is a security positive independent of compromise scenarios.
The change also reflects the reality that software supply chain security has become a higher-profile concern since incidents like SolarWinds (2020) and the 2025 Azure Trusted Signing malware abuse. The CA/B Forum is pushing toward shorter certificate lifetimes across all certificate types as a supply chain security measure.
Code signing was behind the TLS certificate validity reduction curve. TLS certificates moved from 398 days to 200 days in March 2026 (simultaneous with this change), and are scheduled to reduce further to 100 days in 2027 and 47 days by 2029. Code signing certificates at 460 days are now roughly in line with TLS certificate validity, with both expected to continue shortening over time.
How This Change Affects Different Types of Signing Operations
Individual developers signing manually
If you sign software manually (one release every few months, signing at your workstation with a hardware token), the change from a 3-year to a 1-year certificate means an additional renewal event each year. Instead of renewing approximately every three years, you renew approximately every year. The renewal process itself is unchanged: order a new certificate, complete OV or EV validation, receive the certificate, install it on your hardware token, sign with it.
The increase in operational overhead is real but manageable for individual developers. The main risk is forgetting to renew before the certificate expires, which immediately blocks signing. Setting a calendar reminder 60 days before the certificate expires is sufficient mitigation for manual signers.
Development teams with automated CI/CD signing pipelines
This is the group most significantly affected. Automated pipelines that sign every build, release candidate, or deployment artifact need to handle certificate rotation as part of their operational model. A pipeline that was designed for a 3-year certificate lifetime has roughly 2.5 years of runway to drift from best practice without consequence. A pipeline with a 1-year certificate has less than 12 months before a lapse breaks signing.
The specific failure mode: the certificate in the pipeline’s key store or cloud HSM service expires, all subsequent build signing attempts fail, and the first indication may be user reports of unsigned binary warnings or security tools flagging unsigned artifacts in a release. If the pipeline also enforces that builds must be signed before deployment, the release pipeline stops entirely.
Automated signing pipelines need: certificate expiry monitoring with alerts well in advance (60-90 days), a documented renewal process that can be executed under time pressure, and ideally a rehearsed rotation procedure so the team knows how to update the certificate in the pipeline without disruption.
Enterprises with large software portfolios
Organizations that sign many different products across multiple teams face a certificate fleet management challenge that worsens with shorter validity. Each product’s signing certificate now needs annual renewal instead of triennial. If certificates expire staggered throughout the year, the renewal workload is distributed but continuous. If they were all issued on similar dates, a renewal spike hits annually.
Certificate lifecycle management tooling that tracks signing certificate expiry alongside TLS certificate expiry becomes important at this scale. Many enterprises that implemented certificate management platforms after TLS validity reductions now need to include their code signing certificate fleet in the same inventory and renewal process.
The Physical Hardware Token Problem at Annual Frequency
Code signing certificates are required to be stored on hardware meeting FIPS 140-2 Level 2 standards. For certificates delivered on physical USB tokens (the traditional delivery method), annual renewal means the CA ships a new physical token approximately every year. For a single developer this is acceptable. For a development team or enterprise, physical token management at annual renewal frequency creates logistics challenges.
Physical tokens need to be present at the signing machine. For automated CI/CD pipelines, physical tokens are not workable at all: you cannot plug a USB token into a build server in a cloud environment. This was already a problem before the validity change; annual renewal sharpens the urgency.
The solution adopted by most teams with automated signing requirements is cloud HSM signing services. With cloud HSM, the private key is stored in the service provider’s hardware security modules and signing operations happen via API call. The signing machine calls the service, the service signs inside the HSM, and the signature is returned. No physical token is present anywhere in the pipeline.
Annual certificate rotation with cloud HSM is operationally simple: when the certificate approaches expiry, renew it through the CA’s portal, the new certificate is provisioned in the HSM service, and the pipeline continues without physical intervention. The CA partners (DigiCert KeyLocker, SSL.com eSigner, Sectigo cloud signing) all support this model.
The 460-day validity change accelerates a shift that was already underway: from physical token-based signing to cloud HSM-based signing. Organizations that were previously comfortable managing physical tokens on a 3-year renewal cycle may find that annual renewal tips the cost-benefit calculation toward cloud HSM. The administrative overhead of physical token management at annual frequency (receiving shipments, securing tokens, maintaining chain of custody documentation for OV/EV compliance) scales poorly compared to an API-based cloud signing service.
What Multi-Year Pricing Plans Mean Now
Many CAs continue to offer multi-year pricing plans for code signing certificates. These plans are still available and their pricing structure still provides a discount compared to purchasing single-year certificates annually. What changed is what the plan delivers.
A 3-year plan purchased before February 2026 delivered a single certificate valid for 3 years. A 3-year plan purchased from March 2026 onward delivers multiple sequential certificates: each issued for up to 460 days, with successive certificates issued as each expires within the plan term. The CA manages the certificate issuance schedule within the plan. The discounted pricing applies to the entire plan term.
The operational implication: under a multi-year plan, certificate rotation events happen more frequently than before. The plan does not change the 460-day validity limit on individual certificates. If the plan includes automated renewal (where the CA proactively reissues as each certificate approaches expiry), the rotation may be relatively transparent. If the plan requires the subscriber to initiate each renewal, the renewal events happen more frequently and require more subscriber action per plan term than before.
Action Checklist: What to Do Now
For each type of signing operation:
If you currently have a multi-year certificate (issued before March 2026)
- No immediate action required. Your certificate remains valid until its stated expiry date.
- Check the expiry date and set a calendar reminder 60-90 days before it expires.
- When you renew, you will receive a new certificate valid for up to 460 days. Plan your renewal workflow accordingly.
- If your current certificate expires within the next 6 months and you are running an automated pipeline, use this window to review and update your rotation procedure before the change becomes urgent.
If you use a CI/CD pipeline for automated signing
- Audit your pipeline: how does it obtain the signing certificate? Where is the certificate or key stored? Is there an automated process for certificate rotation, or is it manual?
- Set up certificate expiry monitoring for your signing certificate specifically. Many teams monitor TLS certificates but not code signing certificates.
- If your pipeline uses a physical hardware token, evaluate cloud HSM signing services. Annual physical token rotation is operationally painful; this is the time to migrate.
- Document the certificate rotation procedure and run through it once before the certificate actually expires. Emergency rotation under time pressure is worse than planned rotation.
- Review pipeline failure handling: what happens when a signing step fails? Does the build abort? Does an unsigned artifact get deployed? The answers matter more with annual renewal frequency.
If you manage signing certificates for a larger team or enterprise
- Add code signing certificates to your certificate inventory if they are not already tracked there. Requirement 4.2.1.1 of PCI DSS v4.0 requires certificate inventory for cardholder data environments; broader certificate governance is good practice regardless.
- Identify all code signing certificates in use: product name, CA, expiry date, signing method (physical token vs cloud HSM), and responsible owner.
- Plan renewal scheduling to distribute workload: avoid a scenario where all certificates were issued simultaneously and all require renewal in the same month.
- Evaluate whether cloud HSM signing consolidation across products simplifies the operational model compared to managing multiple physical tokens.
The Trend: Code Signing Validity Will Continue to Shorten
The 460-day limit is not the end state. TLS certificates followed a clear reduction path: 398 days in 2020, 200 days in March 2026, 100 days in March 2027, 47 days by March 2029. Code signing has now aligned with TLS certificate validity at approximately 15 months. The CA/B Forum’s general direction across all certificate types is toward shorter validity periods.
Whether code signing certificates follow the same further reduction timeline as TLS certificates is not yet determined by any passed ballot. However, the architectural pressure is consistent: shorter validity means more frequent rotation, which means automation is not optional but required.
Organizations that invest now in certificate lifecycle automation (cloud HSM signing, automated renewal monitoring, documented rotation procedures) are positioned for whatever further changes come. Organizations that manage certificate rotation manually will face increasing operational burden with each validity reduction.
Frequently Asked Questions
Does the 460-day limit apply to certificates I already have?
No. Certificates issued before the effective date of March 1, 2026 remain valid until their stated expiry date. A 3-year certificate issued in 2024 is valid until 2027. The 460-day limit applies to new certificates issued from March 1, 2026 onward. No action is required on existing valid certificates.
Does this apply to both OV and EV code signing certificates?
Yes. CA/B Forum Ballot CSC-31 applies to all publicly trusted code signing certificates, both Organization Validated (OV) and Extended Validation (EV). Both certificate types are now subject to the 460-day maximum validity. The validation process and requirements for each type are unchanged; only the maximum validity period is affected.
I have a 3-year plan but it expires in 2027. What happens?
If your 3-year plan was purchased before the cutoff and includes a certificate valid until 2027, that certificate remains valid. Your plan terms depend on how your CA structured it. For plans that delivered a single certificate, that certificate continues as issued. For plans that automatically reissue within the plan term, subsequent certificates issued within the plan will now be subject to the 460-day limit. Contact your CA to confirm how your specific plan handles this transition.
My CI/CD pipeline uses a physical hardware token for signing. What should I do?
Evaluate migrating to a cloud HSM signing service before your current certificate expires. Annual physical token replacement creates logistics, custody, and operational complexity that scales poorly. Cloud HSM signing services (DigiCert KeyLocker, SSL.com eSigner, Azure Trusted Signing) provide API-based signing where the private key stays in an HSM on the CA’s infrastructure. Certificate renewal with cloud HSM does not require physical token shipment or manual installation. For automated build pipelines specifically, cloud HSM is the standard approach and the one most compatible with annual renewal frequency.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.