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.
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.
- 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. - 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.
- 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.
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.
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.
