Secure Code Signing: Reduced Certificate Validity to 460 days

If you manage code signing for your organization, the industry just changed the rules, and the deadline has already passed. On March 1, 2026, Ballot CSC-31, formally adopted by the CA/Browser Forum on November 17, 2025, came into effect. It reduces the maximum validity period for all publicly trusted code signing certificates from 39 months (approximately 3 years) to 460 days (approximately 15 months). Any code signing certificate issued on or after March 1, 2026, must comply with this new limit.

For development teams that have been operating on a “set it and forget it” renewal cycle, renewing every two or three years — this change fundamentally alters how code signing fits into the software release process. What was once a once-in-three-years administrative task is now a recurring, operationally significant obligation that must be deliberately managed and, in most cases, automated.

In this blog, we will walk through exactly what changed, why the CA/Browser Forum made this decision, who is most affected, and most importantly, what your team should be doing right now to stay compliant and keep signing operations running without disruption.

460-day code signing certificate validity, defined: the maximum lifetime the CA/Browser Forum permits for a publicly trusted code signing certificate issued on or after March 1, 2026, down from 39 months, under Ballot CSC-31 (adopted November 17, 2025), which roughly triples how often every signing certificate an organization operates needs to be tracked, renewed, and, if its key storage still depends on physical tokens, physically replaced.

Key Takeaways

• Ballot CSC-31 was voted and approved October 14, 2025, completed IPR review and was formally adopted November 17, 2025 (publishing Code Signing Baseline Requirements v3.10.0), and took effect March 1, 2026. Certificates issued before that date keep their original validity; anything issued on or after it is capped at 460 days, with no grace period.
• This is the canonical, most detailed page on this specific ballot and its operational fallout. For how this fits alongside the separate EU Cyber Resilience Act obligations covering the same signing infrastructure, see CRA Compliance Architecture for Secure Code Signing, which covers both regimes together rather than duplicating the ballot detail here.
• Shorter validity doesn’t reduce the need for revocation readiness, it changes the math: a compromised key now has at most 460 days of potential exposure instead of 39 months, but confirmed compromise still requires revocation within 24 hours under the Baseline Requirements, not whenever the certificate happens to expire.
• USB hardware tokens, tolerable on a 3-year cycle, become a recurring operational cost on a 15-month one; this is the single most common reason organizations migrate to HSM-backed signing after this change, not before it.

What Changed and When

The CA/Browser Forum’s Code Signing Certificate Working Group introduced Ballot CSC-31 to update the Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates, version 3.9.

Here is the timeline:

Milestone	Date
Ballot CSC-31 proposed	September 2025
Ballot voted and approved by CA/B Forum	October 14, 2025
IPR Review period completed, ballot formally adopted	November 17, 2025
New Code Signing Baseline Requirements v3.10.0 published	November 17, 2025
New 460-day maximum validity takes effect	March 1, 2026

Certificates issued before March 1, 2026 under the previous rules remain valid until their original expiration date. However, any certificate issued or renewed on or after March 1, 2026 is subject to the new 460-day ceiling. There is no grace period for newly issued certificates.

Why the CA/Browser Forum Made This Change

The move toward shorter certificate lifespans is not arbitrary, nor is it new. The CA/Browser Forum has been systematically reducing certificate validity across all certificate types for years. The reasoning is consistent and well-grounded in security principles.

1. Limiting the blast radius of key compromise: A code signing certificate’s private key can be compromised — through a data breach, ransomware, insider threat, or poor key storage practices. Under the old 39-month validity period, a compromised key remained useful to an attacker for up to three years, even if the certificate was revoked (since certificate revocation checking is inconsistently enforced across platforms).
   A shorter lifespan directly caps the window of exposure. If a key is compromised on day one of a 460-day certificate, the attacker has roughly 15 months of potential abuse rather than three years.
2. Stronger key management: When a team does not need to think about its signing certificate for three years, key storage practices, access controls, and audit trails tend to atrophy. Annual or near-annual renewals force organizations to revisit their signing infrastructure regularly — auditing who has access, where keys are stored, whether storage methods still meet current standards, and whether signing workflows are still appropriate.
3. Encouraging automation: Every organization that signs code with a publicly trusted code signing certificate is affected. Shorter validity periods make manual management increasingly impractical, which accelerates the adoption of automated tools.

The USB Token Problem

It is worth spending a moment specifically on the USB hardware token issue, because it represents the single largest operational challenge created by the 460-day change for many development teams.

The CA/Browser Forum’s Baseline Requirements have, for several years, required that private keys for publicly trusted code signing certificates be stored on hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+ standards. For many organizations, this requirement was met by issuing code signing certificates on USB hardware tokens shipped directly from the Certificate Authority — a model that satisfied the hardware key storage requirement without requiring the organization to operate its own HSM infrastructure.

USB token-based signing introduced its own problems even under the old 39-month validity period:

• Tokens could be lost, damaged, or stolen, and replacing them required re-issuance of the certificate.
• Signing required physical access to the token, which created bottlenecks for remote teams and automated CI/CD pipelines.
• Tokens could not be easily backed up, creating a single point of failure for the signing operation.

Under a 460-day validity period, all of these problems recur more frequently. The token logistics that were manageable on a three-year cycle become a recurring operational burden on a 15-month cycle.

The practical answer, and the direction the industry is clearly heading, is migration from USB tokens to cloud-based or on-premises HSM infrastructure accessed through a centralized signing platform. This approach stores the private key in FIPS-compliant hardware, allows signing operations to be performed via API from any authorized build system, eliminates the physical token logistics entirely, and integrates naturally with centralized code signing platform.

Why Timestamping Becomes Even More Critical Now

One of the most important technical considerations for shorter certificate lifespans is timestamping. When a code signing certificate expires, any software signed with that certificate does not automatically become untrusted. If the signing operation included a valid RFC 3161 timestamp from a trusted Timestamping Authority (TSA), the signature remains verifiable indefinitely — even after the certificate expires. The timestamp provides cryptographic proof that the signing operation occurred while the certificate was valid, and that proof persists beyond the certificate’s validity period.

Without a timestamp, the signed artifact’s trustworthiness is tied directly to the certificate’s validity period. Once the certificate expires, verification systems that check certificate validity will reject the signature. For any software with a service life longer than 15 months, which includes virtually every enterprise application, driver, firmware image, or long-lived executable, an absent or improperly applied timestamp means that software will eventually lose its trusted status.

When certificates are renewed annually, every signed artifact that lacks a proper RFC 3161 timestamp becomes a potential problem within 15 months of signing. The practical steps here are:

• Verify that your signing toolchain applies RFC 3161 timestamps by default on every signing operation.
• Configure your signing pipelines to treat a missing timestamp as a signing failure and not a warning.
• Ensure that timestamps are applied using SHA-256 hashing (not SHA-1, which is broadly deprecated).
• For artifacts with long service lives (firmware, drivers, enterprise software), verify that your timestamping configuration has been correctly applied to all historical artifacts as well.

Revocation Under the New Validity Window

Shorter validity is sometimes described as reducing the need for revocation. That’s not quite right: it reduces the maximum exposure a compromise can cause, but it doesn’t change the revocation obligation itself. Under the Code Signing Baseline Requirements §4.9.1.1, a CA must still revoke a certificate within 24 hours of confirming private key compromise, on a 460-day certificate exactly as on a 39-month one. What the shorter window changes is the ceiling: if a key is compromised the day after issuance and goes undetected, the maximum window an attacker could theoretically exploit it drops from roughly three years to about 15 months.

The practical implication for your audit checklist: confirm your organization can identify, within an hour of suspecting compromise, every artifact signed by a specific certificate. Waiting for a certificate to simply expire is not a revocation plan, and the faster renewal cadence this change introduces is not a substitute for a tested compromise response.

Old vs. New Requirements, Side by Side

Requirement	Before March 1, 2026	On or After March 1, 2026
Maximum certificate validity	39 months	460 days
Renewal frequency (typical)	Roughly every 3 years	Roughly every 15 months
Revocation timeline for confirmed key compromise	24 hours (unchanged)	24 hours (unchanged)
Private key storage	FIPS 140-2 Level 2+ or Common Criteria EAL4+ hardware (since June 2023)	Same requirement, unchanged
Maximum theoretical exposure from an undetected key compromise	Up to ~39 months	Up to ~460 days

Audit Checklist: What You Should Do Right Now

If your organization has not yet assessed the impact of the 460-day change, here is a practical starting point:

Step 1 — Audit your code signing certificate inventory. Identify every publicly trusted code signing certificate your organization uses. For each one, record the expiration date, the storage method (USB token, HSM, cloud HSM, software store), which signing workflows or pipelines depend on it, and who is responsible for renewal. If you do not have this information centrally documented, creating that inventory is the first priority.

Step 2 — Identify certificates already subject to the new rules. Any certificate issued on or after March 1, 2026 is limited to 460 days. Identify which of your certificates fall into this category and calendar renewal events with appropriate lead time — plan for renewal at least 30 to 60 days before expiration to allow for procurement, provisioning, and pipeline updates.

Step 3 — Assess your key storage infrastructure. If your organization is using USB hardware tokens, evaluate whether migration to a cloud HSM or on-premises HSM accessed through a centralized signing platform is appropriate. Given the recurring logistics of USB token renewal at 15-month intervals, this migration will likely be cost-effective within the first renewal cycle.

Step 4 — Verify timestamping configuration. Audit your signing pipelines to confirm that RFC 3161 timestamps are being applied on every signing operation, using SHA-256 and also treat a missing timestamp as a blocking error in your pipeline.

Step 5 — Update pipeline configurations for dynamic certificate references. Review all CI/CD pipeline configurations, build scripts, and signing tool configurations that reference signing certificates. Replace static identifiers with dynamic references that will not need to be manually updated at each renewal.

Step 6 — Evaluate certificate lifecycle management automation. If your organization manages a significant number of certificates across multiple teams or products, evaluate a dedicated centralized signing platform that can automate discovery, renewal alerting, and pipeline-integrated deployment.

How Encryption Consulting’s CodeSign Secure Helps

CodeSign Secure is Encryption Consulting’s centralized, policy-enforced code signing platform. It was designed precisely for the environment that the 460-day change is accelerating: one where signing operation must be automated, keys must be centrally managed in HSM-backed infrastructure, and certificate lifecycle events must be tracked and acted upon without depending on individual developer awareness.

Centralized HSM-Backed Key Management

CodeSign Secure stores all private signing keys in FIPS 140-2 Level 3 certified Hardware Security Modules — eliminating the USB token model entirely. The platform integrates with Thales Luna, Entrust nCipher, Utimaco, Securosys, and major cloud HSMs from AWS and Azure. Private keys are generated inside the HSM, never exported, and accessible only through the platform’s signing API.

Certificate Lifecycle and Renewal Alerting

CodeSign Secure maintains a centralized inventory of all certificates under management, with expiration visibility and configurable renewal alerting. Security and operations teams receive advance notification before certificates expire, eliminating the risk of discovering an expired certificate.

CI/CD Pipeline Integration

The platform integrates natively with Azure DevOps, Jenkins, GitLab CI, and other major pipeline systems through both API and command-line interfaces. Signing operations are performed with the pipeline referencing the current valid certificate dynamically through the platform rather than through a static certificate reference. When a certificate is renewed, pipeline signing operations continue without interruption and without requiring pipeline configuration updates.

Post-Quantum Readiness

As the certificate industry transitions to shorter lifespans, it is also preparing for the post-quantum cryptography migration that NIST has already standardized. CodeSign Secure v3.02 supports ML-DSA (FIPS 204) for signing by providing detachable signatures, allowing organizations to begin transitioning their code signing infrastructure to quantum-resistant algorithms while maintaining compatibility with existing platforms.

Frequently Asked Questions

Does the 460-day limit apply to certificates I already have?

No. Certificates issued before March 1, 2026 keep their original validity period and expiration date. The 460-day cap applies only to certificates issued or renewed on or after that date, with no grace period.

Does shorter validity mean I can worry less about revocation?

No. Confirmed key compromise still requires revocation within 24 hours under the Code Signing Baseline Requirements, on a 460-day certificate exactly as on the old 39-month one. Shorter validity only lowers the maximum exposure window if a compromise goes undetected; it doesn’t replace the need for a tested revocation process.

Do I still need to worry about certificate expiry if I use trusted timestamping?

For already-signed, already-shipped software, no: a valid RFC 3161 timestamp keeps the signature verifiable after the certificate expires. You still need to renew the certificate itself before its expiration to keep signing new releases.

Is migrating off USB tokens mandatory under this change?

Not mandatory, but strongly favored by the economics of the change. The same FIPS 140-2 Level 2+ hardware requirement applies whether you use a token or an HSM; a 460-day renewal cycle just makes the recurring logistics of physical token replacement, loss, and CI/CD bottlenecks far more frequent than they were on a 3-year cycle.

How is this different from the CRA compliance requirements for code signing?

They’re separate regimes. This ballot is a CA/Browser Forum industry rule about certificate lifecycle; the EU Cyber Resilience Act is a separate legal obligation about product-level firmware integrity and vulnerability disclosure. An organization signing CRA-in-scope products needs to satisfy both; see CRA Compliance Architecture for Secure Code Signing for how they intersect.

Conclusion

The 460-day code signing certificate change that took effect on March 1, 2026, is not the end of this story — it is a step in a direction the CA/Browser Forum has been moving consistently for years. The organizations that will manage these changes with the least disruption are the ones that treat certificate lifecycle management as a disciplined, automated, infrastructure-level function — not as a periodic manual task.

For development teams still relying on USB tokens and manual renewal reminders, the 460-day change is the right moment to assess whether that approach is sustainable. The logistics of annual token replacement, pipeline configuration updates, and manual renewal tracking across multiple certificates will compound quickly as validity periods continue to shorten.

At Encryption Consulting, our CodeSign Secure platform is designed to make that transition practical, giving your team HSM-backed key security, automated certificate management, and pipeline-integrated signing that handles renewals without manual intervention.