Code Signing Certificate Lifespans Are Getting Shorter

Code signing certificates authenticate software before it reaches end users. They confirm that a binary, installer, or update came from a verified publisher and has not been altered in transit. For years, the operational model around these certificates was simple: obtain one with a multi-year validity period, store it in a build environment, and renew it when the expiry reminder arrived. That model created a quiet but real risk, because a certificate valid for 39 months means a compromised private key remains trusted for that entire period unless someone catches it and revokes it in time.

Under CA/Browser Forum Ballot CSC-31, adopted on November 17, 2025, and incorporated in the Code Signing Baseline Requirements version 3.10.0, the maximum validity period for publicly trusted code signing certificates dropped from 39 months to 460 days, roughly 15 months. Any code signing certificate issued on or after March 1, 2026, must comply with this limit. Certificates issued before that date remain valid until their natural expiration, but at the time of renewal, the new timeline applies.

This is not an isolated event. It follows the same trajectory as TLS certificates, which dropped from 398 days to 200 days effective March 15, 2026, and are scheduled to fall further to 100 days on March 15, 2027, and 47 days on March 15, 2029, under CA/B Forum Ballot SC-081v3, passed in April 2025. Code signing and TLS are converging on the same principle: certificates should not outlive the trust conditions under which they were issued. The industry is betting on automation to make that practical.

This blog walks through what changed, where the risk sits, and what organizations need to address before the next renewal cycle.

Why Certificate Validity Periods Are Shrinking

The move toward shorter certificate lifespans is not arbitrary. It addresses two problems that have existed in public PKI for a long time: the gap between when a certificate is compromised and when it actually stops being trusted, and how slowly organizations move to stronger cryptographic standards when their existing certificates still work fine.

When a private signing key is exposed, the certificate tied to it stays valid until it either expires or gets revoked. Revocation has well-known reliability problems. Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) are not consistently checked by all platforms, and when a revocation check fails or times out, most systems treat it as a pass rather than a block.

The result is that a compromised certificate can remain a viable attack tool for as long as it remains trusted. Under the previous 39-month validity model, a single key compromise could potentially expose an organization to more than three years of risk. With the new 460-day limit, the maximum exposure window is significantly reduced.

The second problem is that organizations tend not to replace working certificates ahead of schedule, even when better algorithm options are available. The industry learned this during the SHA-1 deprecation and the move away from 1024-bit RSA keys. Both transitions dragged on far longer than necessary because long-lived certificates gave organizations no natural deadline to act.

Shorter validity periods change that. Every renewal is an opportunity to adopt current standards. This matters particularly now, given that NIST finalized its first post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), in August 2024. Organizations that renew certificates regularly will be far better positioned to adopt quantum-resistant algorithms as platform and CA support develops.

Shorter certificate lifespans narrow the damage from a key compromise, reduce reliance on revocation mechanisms that do not always work, and keep cryptographic standards current across the ecosystem. Applying this to code signing certificates is a direct step toward stronger software supply chain security. Ballot CSC-31 formalized that step with a specific maximum validity limit and a hard effective date for all publicly trusted code signing certificates.

What Ballot CSC-31 Actually Changed

CA/B Forum Ballot CSC-31 was proposed by Microsoft , with the voting period closing on October 13, 2025, and the ballot formally adopted on November 17, 2025, following the IP review period. Seven of nine Certificate Issuer members voted in favor, with two abstaining and none opposed. The sole Certificate Consumer vote, cast by Microsoft, was also in favor. The Intellectual Property (IP) review period closed on November 17, 2025, with no exclusion notices filed.

The updated Code Signing Baseline Requirements version 3.10.0 were published on November 17, 2025, with the new validity limit taking effect on March 1, 2026. The requirement applies to all publicly trusted code signing certificates, meaning certificates issued by CAs whose roots are embedded in operating system and browser trust stores. Private PKI used for internal signing workflows is not governed by CA/B Forum rules, though aligning internal practices to the same standard is a reasonable approach.

One practical detail that matters: the 460-day limit is calculated from the date of issuance, not the date the order was placed. A certificate requested before March 1, 2026, but issued on or after that date, is subject to the new cap. Most Certificate Authorities (CAs) stopped issuing 2-year and 3-year code signing certificates in late February 2026 to enforce the deadline cleanly. Any publicly trusted code signing certificate issued from March 1, 2026, onward has a maximum validity of 460 days.

Meeting the 460-day limit on paper is straightforward. The harder question is whether the existing signing infrastructure was ever built to operate on that cadence.

Why Signing Infrastructure Was Not Built for This

The jump from a 39-month certificate to a 460-day certificate sounds like a simple renewal calendar change. In practice, it exposes structural problems in how most organizations have set up their signing workflows.

The first is key storage. The Code Signing Baseline Requirements already require that private keys for all publicly trusted code signing certificates, both standard Organization Validated (OV) and Extended Validation (EV), be stored in a hardware cryptographic module conforming to at least Federal Information Processing Standards (FIPS) 140-2 Level 2 or Common Criteria EAL 4+. As FIPS 140-2 validations move to the Historical list on September 21, 2026, organizations procuring new hardware should prioritize modules with active FIPS 140-3 validation to ensure continued compliance beyond that date.

For standard OV certificates, hardware tokens such as USB-based devices are a common choice, but they create a physical management problem. Tokens can be lost, they are tied to specific individuals, and renewal means re-provisioning the hardware. At a 460-day cycle, that process happens every year instead of every three years, which creates significantly more work and more opportunity for things to go wrong, if not managed properly.

The second problem is pipeline integration. Many build systems sign artifacts using a certificate and key that were manually placed into a file system path, environment variable, or secrets manager entry. When the certificate is replaced, something in that chain breaks. At a 460-day cycle, that break happens more often. Teams without end-to-end automation across certificate provisioning, Certificate Signing Request (CSR) generation, CA interaction, and deployment will find this schedule difficult to manage reliably.

The third problem is inventory. A single organization may have dozens of code signing certificates spread across product lines, build environments, and contractor-managed systems. The teams that owned those certificates three years ago may have moved on. Without a centralized record of what exists, who owns it, and when it expires, a 460-day renewal cycle becomes unmanageable.

The structural gaps in signing infrastructure do not just create renewal friction; they become critical liabilities the moment a certificate is compromised.

What Happens When a Code Signing Certificate Is Compromised

A compromised code signing certificate is not just a security event. It is an operational emergency with a hard deadline. Under the Code Signing Baseline Requirements version 3.10.0, a Certificate Authority (CA) must revoke a code signing certificate within 24 hours of being notified that the certificate was used to sign malware or that the private key was stolen or exposed. That 24-hour window leaves very little room for a slow or disorganized response.

The immediate problem is identification. Before a CA can act, the certificate in question must be identified precisely: its serial number, the issuing CA, and the current revocation status. For organizations without a centralized certificate inventory, this step alone can take hours. If signing certificates are spread across teams, build environments, and contractor systems with no single owner on record, finding the right certificate under pressure is not easy.

Once revoked, the certificate cannot be used to sign anything new, and the CA will publish the revocation through its CRL and OCSP infrastructure. However, revocation checking is not consistently enforced across all platforms. This means a revoked certificate may still be accepted in some environments for a period after revocation, which is exactly the behavior that shorter certificate lifespans are designed to limit over time.

The replacement certificate must then be issued and deployed across every pipeline that depended on the compromised one. Without documented pipeline integration and automated deployment, this is another manual effort under time pressure. Organizations with Hardware Security Module (HSM)-backed key storage are better positioned here because the compromise is typically limited to the certificate rather than the underlying hardware, and new key generation can happen within the HSM without re-provisioning physical tokens across teams.

The operational lesson is straightforward: the same gaps that make a 460-day renewal cycle difficult to manage, such as incomplete certificate inventories, manual signing pipelines, and software-stored private keys, are also the gaps that make incident response slower and more error-prone. Addressing these weaknesses before a compromise occurs is significantly less costly than trying to fix them during an active incident.

Incident response does not end with certificate revocation and replacement. Organizations also need to understand how timestamping affects the trust and usability of previously signed software.

The Timestamping Question Most Teams Overlook

One aspect of code signing that matters more under shorter certificate lifespans is RFC 3161 timestamping. When a signature includes a trusted timestamp from a Time-Stamping Authority (TSA), the validity of that signature extends beyond the certificate expiration date.

The timestamp provides cryptographic proof of when the software was signed, allowing the signature to remain valid even after the code signing certificate expires, provided the TSA’s certificate chain remains valid and trusted at the time of verification. As a result, software that was signed and distributed before certificate expiration does not automatically lose trust under the new 460-day validity limit. 

What changes is the signing credential itself. A valid, unexpired certificate is required to sign new releases, new builds, and updated packages. Once a code signing certificate expires, it cannot be used to sign anything new, even if older signatures from that certificate remain valid. The impact is direct: any gap in certificate availability stops software delivery. At a 460-day cycle, a missed renewal does not allow three years of slack. It stops the pipeline on day 461.

These operational realities make one thing clear: organizations need signing workflows designed for continuous certificate renewal rather than occasional certificate replacement.

What Needs to Change in Signing Workflows

Getting compliant with the 460-day limit is only the starting point. Building a workflow that holds up through the next reduction, which is likely given that TLS certificates are already on a scheduled multi-year reduction path, requires structural changes.

Start with discovery. Managing code signing certificates on a 460-day renewal cycle requires knowing how many exist, where they are deployed, what pipelines depend on them, and who owns each one. For organizations that have been running on the old 39-month model, this inventory often does not exist in a usable form. Building it is the first step before anything else can be automated or managed reliably.

Move signing keys into hardware. Private keys stored on file systems, developer machines, or build servers need to be moved into an HSM. HSM-based storage meets the FIPS 140-2 Level 2 minimum that the CA/B Forum Code Signing Baseline Requirements currently specify, removes the physical re-provisioning problem that USB tokens create at annual renewal cycles, and reduces the risk of a compromised key being used to sign and distribute malicious software. Because all FIPS 140-2 validations move to the Historical list on September 21, 2026, new hardware procurements should target modules with active FIPS 140-3 validation.

Automate the renewal pipeline. The CA/B Forum Code Signing Baseline Requirements do not mandate automation, but a 460-day cycle makes manual renewal unreliable at any meaningful scale. Certificate Signing Request (CSR) generation, CA submission, issuance, and deployment should run through a repeatable, auditable workflow rather than a manual process started a few days before expiry. The Automatic Certificate Management Environment (ACME) protocol, where CA support is available, removes manual steps from the renewal process entirely.

Plan for the next reduction. Code signing certificates are now on the same reduction path as TLS. Organizations that build automation-first signing infrastructure today will be able to absorb future validity reductions without rebuilding from scratch. Organizations that treat 460 days as a permanent ceiling may face the same disruption again when the next ballot passes.

For many organizations, building this level of operational maturity requires specialized expertise, appropriate tooling, and a phased implementation strategy. That’s where Encryption Consulting can help.

How Encryption Consulting Can Help

CodeSign Secure is Encryption Consulting’s enterprise-class code signing management platform, designed to provide the infrastructure controls that industries need.

HSM-Backed Key Management

CodeSign Secure stores all private signing keys inside FIPS 140-2 Level 3 certified Hardware Security Modules, integrating with Thales Luna, Entrust nShield, Utimaco, Securosys, and cloud HSMs from AWS and Azure. Per-product key isolation is enforced at the HSM partition level: each product line receives its own dedicated key, generated inside hardware and never exported.

M-of-N Signing Quorum and RBAC

The platform’s Role-Based Access Control model enforces M-of-N approval requirements for production firmware signing. No single individual can initiate and approve a signing operation. Signing requests, approvals, and rejections are all logged. The RBAC configuration itself is auditable and version-controlled, providing the documented signing policy that CRA conformity assessments require.

Immutable Audit Logging

Every signing event in CodeSign Secure generates an immutable log entry capturing the artifact hash, the key identifier, the certificate used, the approving identity, and the RFC 3161 timestamp. Logs are centralized, separately stored from the signing infrastructure.

Cross-Platform Firmware Format Support

CodeSign Secure supports signing of firmware artifacts across the full range of formats that a diverse product portfolio requires: .bin, .img, .hex, .fw, .dfu, and .efi, satisfying the CRA’s requirement for consistent controls across product lines without rebuilding the signing infrastructure for each platform.

Post-Quantum Cryptography Support

CodeSign Secure v3.02 supports production-grade ML-DSA (FIPS 204, at ML-DSA-44, ML-DSA-65, and ML-DSA-87 security levels) and SLH-DSA (FIPS 205) as detachable signatures alongside classical algorithms. For manufacturers building products with five-plus year CRA support obligations, PQC signing today is the architecture that protects against the HNDL threat before a Cryptographically Relevant Quantum Computer  (CRQC) arrives.

CI/CD Pipeline Integration

CodeSign Secure integrates with Azure DevOps, Jenkins, GitLab CI, and other major pipeline platforms through API and command-line interfaces. Firmware signing is a controlled, policy-enforced stage in the build pipeline, not a manual step.

Organizations working through the 460-day transition, whether assessing current certificate inventory, moving keys into hardware, or building automated renewal workflows, can reach out to Encryption Consulting for a hands-on consultation. The team works directly with organizations to identify gaps in their signing infrastructure and build a practical path forward before the next renewal cycle creates pressure.

Conclusion

CA/B Forum Ballot CSC-31 marks a real shift in how publicly trusted code signing certificates are managed. The 39-month validity period that most teams built their workflows around is no longer available. Organizations that have not yet adapted will face their first 460-day renewal soon, and the infrastructure decisions made at that point will determine whether future reductions cause disruption or are handled smoothly.

The organizations that navigate this well are not the ones that add a calendar reminder and carry on. They are the ones that treat the 460-day limit as the signal it is: the industry is moving toward shorter certificate lifespans across the board, TLS certificates are already on a confirmed multi-year reduction schedule, and code signing is now on the same path. Building an automated, auditable signing infrastructure now means not having to rebuild it again at the next reduction.

The CA/B Forum has been consistent in its direction. Certificate lifespans will continue to shorten, and manual renewal processes will become increasingly difficult to sustain. Organizations that invest in discovery, hardware-backed key storage, and automated code signing certificate lifecycle management today are not just meeting a current requirement. They are building the foundation that will carry them through every future reduction in certificate validity.