Code signing certificate validity is the maximum number of days a publicly trusted code signing certificate can remain valid before it must be renewed. Since March 1, 2026, that number has dropped to 460 days, down from the 39 months teams have relied on for years. The rule comes from the CA/Browser Forum Code Signing Baseline Requirements, the group of certificate authorities and browser vendors that sets the rules every public certificate must follow. This blog covers what is changing, how signing and timestamping work, where private keys need to live, and how to prepare without scrambling at the last minute.
What Changed on March 1, 2026
The rule itself is simple. Any code signing certificate issued on or after March 1, 2026 cannot have a validity period longer than 460 days, or roughly 15 months. Certificates issued before that date keep running on their original schedule until they expire naturally, so for a while you will have a mix of long-lived and short-lived certificates at once. The rule applies equally to Organization Validation (OV) and Extended Validation (EV) certificates, with no exception for either type, and it mirrors a pattern the industry already worked through with TLS certificates. Code signing is simply catching up now.
The reasoning is straightforward from a risk angle. A code signing certificate represents trust, and that trust persists for as long as the certificate stays valid. If the private key behind it is ever stolen or misused, the damage lasts exactly as long as the certificate does. A three-year certificate gives an attacker a three-year window to keep using a stolen key. A 460-day certificate cuts that window by more than half and forces organizations to rotate keys on a predictable schedule instead of leaving them untouched for years.
Shorter lifespans push teams toward automation almost by force, since manual certificate management breaks down quickly once renewal happens every 15 months instead of every three years. That shift, from a rare chore to a routine operational process, is really the point of the rule, more than the specific number of days chosen.
How Code Signing and Timestamping Actually Work Together
When a publisher signs software, a hash is created, a unique fingerprint of the code that changes completely if even one byte is altered. That hash is signed using the publisher’s private key, producing a digital signature, which is attached to the software along with the publisher’s public certificate. When a user downloads the file, their operating system recalculates the hash and checks it against the signature using the public key. If it matches and the certificate chains back to a trusted root CA, the software is shown as verified; if anything changed since signing, the signature fails. This is why the private key matters so much, and why the rules around where it lives keep getting stricter.
This raises an obvious question: what happens to software you signed years ago once the certificate behind it expires? The answer is timestamping, the single most important detail in this transition. When you sign code, your tooling can also send the signature to a Time Stamping Authority (TSA), a trusted third party that records cryptographic proof of when the signature was created, following the IETF RF C 3161 Time-Stamp Protocol, a standard most signing tools already support.
Once a timestamp is attached, the OS can confirm the signature was created while the certificate was still valid, even after that certificate expires. Trust is locked in at the moment of signing, not when someone opens the file, which is what makes frequent rotation workable at all.
The catch is that timestamping is not automatic everywhere. Some older build scripts skip it, and some legacy tools do not verify it properly. With certificates now expiring roughly every 15 months, it is worth auditing your signing process today to confirm every build is timestamped correctly. Getting timestamping right is only half the job, though; the other half is making sure the pipeline around it can keep pace with certificates that now turn over every 15 months instead of every few years.
Preparing Your Build Pipeline
For most teams, the operational impact comes down to a few concrete shifts. Build systems can no longer hardcode a certificate path and assume it will work for years; pipelines need to pull the current valid certificate dynamically instead of pointing to a static file that will eventually go stale mid-release. Air-gapped signing environments, common in industrial control, healthcare, and government software, need a predictable schedule for importing new certificates, since they often cannot fetch a renewal automatically.
Multi-year certificate purchases need to give way to more frequent renewal budgeting and approval time, and anyone managing EV or OV certificates needs a renewal calendar that accounts for CA validation time, which can take a few days and should never be left to the last minute.
None of this is difficult on its own. The real challenge is that signing has historically been treated as a setup task done once every few years, not an ongoing process. Working through it as a short sequence makes the transition manageable. Start with a complete inventory: list every code signing certificate across build servers, CI/CD pipelines, signing workstations, and air-gapped environments, recording the issuing CA, issuance date, expiration date, and where each private key lives. This usually uncovers more certificates than teams expect.
Next, make timestamping non-negotiable by auditing your signing scripts to confirm every build is timestamped through a trusted TSA. Then automate renewal and key rotation wherever manual steps remain, since manual renewal does not scale once certificates expire every 15 months. Finally, set clear policy on key strength, approved algorithms, required HSM certification level, and certificate ownership, and keep an audit trail of every signing operation so compliance reviews stay painless.
A few mistakes show up repeatedly. Here are few points to defeat them:
- Do not assume all your certificates expire on the same date; you will have a mix of long and short validity certificates coexisting for a while.
- Do not forget that pipelines built around a static certificate file will break the moment that certificate expires, often mid-release.
- Do not treat timestamping as optional, since it is the biggest factor in whether older signed software stays trusted.
- Do not leave private keys untouched across renewals, since that defeats much of the security benefit shorter validity is meant to provide.
Handled this way, shorter certificate lifetimes stop being a scramble and become a routine part of how you ship software. And the habits you build now are exactly what the next, bigger cryptographic shift will demand, so the effort is never wasted.
How This Connects to Crypto-Agility and Post-Quantum Readiness
The same skills you build to handle 460-day code signing certificates, namely discovery, automation, and rapid rotation, are exactly what your organization will need for the broader shift toward post-quantum cryptography (PQC). NIST finalized its first post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. These are final standards, not drafts, and organizations are expected to plan around them today.
Code signing has its own deadline worth knowing. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) calls for software and firmware signing to support and prefer post-quantum algorithms, specifically the stateful hash-based schemes LMS and XMSS (NIST SP 800-208), a phase that began in 2025, with exclusive use required by 2030. Building strong cryptographic inventory and rotation habits now, while working through the 460-day transition, puts your team ahead of that shift instead of starting from scratch later.
Crypto-agility is the ability to replace cryptographic algorithms, keys, and certificates with minimal disruption to existing systems, allowing organizations to respond quickly to algorithm deprecation, evolving regulatory requirements, or emerging threats without redesigning their signing infrastructure. In practice, this means that migrating to new standards, such as those required under CNSA 2.0 or future post-quantum guidance, becomes an operational change to cryptographic policy rather than a costly engineering effort.
It also provides operational resilience. If a signing algorithm is deprecated, a vulnerability is discovered, or regulatory approval changes, organizations can transition to an alternative algorithm without interrupting software release pipelines. During the post-quantum migration period, the recommended strategy is hybrid code signing, where each artifact is signed using both a classical algorithm (such as ECDSA or RSA) and a post-quantum algorithm (such as ML-DSA or LMS). This allows relying parties to validate signatures using either scheme, preserving interoperability with existing systems while providing cryptographic continuity as post-quantum support becomes widespread.
Organizations that have already modernized their code-signing infrastructure with automated certificate lifecycle management, regular certificate rotation, secure key storage in hardware-backed environments, and RFC 3161-compliant timestamping are significantly better positioned to adopt new algorithms as standards evolve. In practice, reaching this level of crypto-agility is far easier with purpose-built tooling and the right expertise behind it.
How Encryption Consulting Can Help
Adjusting to shorter code signing validity is much easier when your certificate and key management practices are already organized, rather than scattered across teams and tools. Encryption Consulting works with security, PKI, and DevSecOps teams to bring structure to exactly this kind of transition, starting with a clear view of where every certificate and key actually lives today.
Our team helps organizations build and modernize their public key infrastructure, and our CodeSign Secure platform is built specifically to operationalize the practices in this blog: HSM-backed private key storage, policy-driven approval workflows, automatic timestamping on every signing operation, and detailed audit trails. CodeSign Secure also includes native support for post-quantum signing algorithms such as ML-DSA and LMS, so teams adopting it now are not starting a second migration project when CNSA 2.0 deadlines arrive.
Beyond code signing, we help with broader certificate lifecycle management, key management, and compliance mapping against standards like NIST and PCI DSS, so your signing process holds up under audit as well as under attack.
Conclusion
The move to 460-day code signing certificates is a meaningful shift, but a manageable one if you start now. Build a clear inventory of your certificates, make timestamping standard, rotate private keys with every renewal, and automate wherever manual steps remain. Teams that treat this as routine maintenance will barely notice the transition. Teams that wait will feel it in their release schedule, likely more than once, since this is the first of several certificate lifespan reductions still to come. If you want help getting your code signing and certificate lifecycle management ready for this change, or for what comes after it, Encryption Consulting is a good place to start that conversation.
