Code Signing Certificates Drop to 460 Days in 2026: What to Do About it

Key Takeaways

• The 39-month validity period will drop down to 460 days starting March 1, 2026, which means security teams should have certificate rotation built into their release pipelines now.
• Timestamping configuration is the most important audit item because properly timestamped codes are still trusted long after a signing certificate has expired.
• Extended Validation (EV) and Organization Validation (OV) signing certificates both fall under the 460-day validity period and require private keys stored in FIPS 140-2 Level 2+ HSMs
• Automated certificate lifecycle management can help organizations manage the shrinking validity periods for certificates.
• Cryptographic inventory, rotation capabilities, and the ability to address shorter certificate lifespans are all necessary to navigate post-quantum cryptography migration by 2030.

The CA/Browser Forum just approved something that’s going to change how software gets signed. Starting March 1, 2026, code signing certificates will drop from a 39-month validity period to just 460 days.

Why Shorter Certificate Lifespans?

Two forces converged to make this change inevitable: targeted attacks and forgotten certificates, causing significant outages.

• In late 2024, security researchers at HarfangLab uncovered the Hijack Loader operation, where criminals used legitimate code signing certificates to sign malware that deployed the Lumma information stealer. Because the files carried valid signatures, the malware bypassed security checks and reached far more victims than unsigned payloads would have.
• But that’s only part of the story. The operational risk became impossible to ignore when Microsoft experienced multiple high-profile outages tied directly to supply chain certificate management. Teams went down on December 18, 2024. Office 365 suffered an 18-hour global outage shortly after. The root cause in both cases: certificates buried in libraries and dependencies that expired unexpectedly. Every component in a software supply chain has certificates, and because you set them and forget them, they are easily forgotten, and when they expire, systems fail.

The logic behind shorter lifespans is straightforward, as they limit the window of exposure if a key gets compromised. The average time it takes attackers to penetrate a supply chain system is around 15 months. With certificates expiring every 460 days, you’re forcing rotation before that window typically closes. But just as importantly, shorter lifespans force the automation and visibility practices that prevent the kind of outages Microsoft experienced.

What Actually Changes on March 1, 2026?

The new rule, outlined in the Code Signing Baseline Requirements v3.10.0, is clear: any code signing certificate issued on or after March 1, 2026, cannot exceed 460 days of validity. Certificates issued before that date can still run their full 39-month term, so you’ll see both validity periods coexisting for a while.

Here’s what changes for development teams:

• Build systems need restructuring. If your build servers store a certificate for years, that approach won’t survive the shorter cycle. You’ll need to rotate keys on schedule, update build configurations, and prevent unexpected expiration mid-release.
• Air-gapped signing environments face tighter logistics. Sectors like industrial control, healthcare, and government often hand-carry certificates into isolated networks. They now need predictable import cycles and renewal tracking so signed software doesn’t stall waiting for a fresh certificate.
• Legacy signing tools will break unless updated. Old scripts that hardcode certificate paths or expect a single long-lived key will fail once that key expires. Pipelines need dynamic certificate selection and automated retrieval rather than static folders.
• Key leak incidents become easier to contain. Attackers can’t rely on a multi-year certificate that stays valid long after a breach. Organizations still need to revoke quickly, but the blast radius shrinks.
• Compliance and identity teams operate on a tighter clock. Teams managing EV or organization validation certificates must adjust internal calendars so renewal delays don’t block product releases.

The Timestamping Detail That Saves You

There is a bit of good news. Properly timestamped code remains valid even after the signing certificate expires. When you sign code with a timestamp from a trusted Time Stamping Authority (TSA), you’re proving “this code was signed when the certificate was still valid.” That timestamp locks in the validity at the moment of signing. This means your March 2025 release doesn’t suddenly become untrusted in April 2026 when your certificate expires.

This distinction becomes critical under the 460-day rule. You’ll rotate certificates more frequently, but users won’t face an avalanche of “invalid signature” warnings on older software versions.

Unfortunately, not all signing tools implement timestamping by default, and some legacy systems don’t verify timestamps properly. If you sign code without a timestamp and the certificate expires, the program becomes untrusted. That’s the majority of signature validation issues we see in the field. It’s important for IT to audit code-signing processes now to ensure timestamping is configured correctly and happens every time.

What About HSMs and Key Storage?

If you’re dealing with publicly trusted code signing certificates, you need a Hardware Security Module (HSM). This is non-negotiable under current requirements, and it remains non-negotiable under the new baseline.

Key rotation is now effectively driven by the 460-day validity period. Every time you renew a certificate, you should be rotating the private key. This limits the window of private key exposure and forces better security practices throughout your signing infrastructure.

Also, both Extended Validation (EV) and Organization Validation (OV) code signing certificates are subject to the new rules. The differences between EV and OV remain at the identity verification level or in the way Certificate Authorities validate your organization before issuing the certificate. But once issued, both types follow the same 460-day validity requirement.

EV vs. OV Code Signing Certificate Comparison Under the 460-Day Rule

Attribute	Extended Validation (EV)	Organization Validation (OV)
Max Validity (Post-March 2026)	460 days	460 days
Identity Verification	Rigorous multi-step organization verification	Standard organization verification
Private Key Storage	FIPS 140-2 Level 2+ HSM required	FIPS 140-2 Level 2+ HSM required
SmartScreen Reputation	Immediate trust on Windows	Requires reputation building
Key Rotation on Renewal	Recommended with each renewal cycle	Recommended with each renewal cycle
Timestamping Requirement	Strongly recommended for all signed code	Strongly recommended for all signed code
Typical Use Case	Enterprise software publishers	Internal tools and smaller publishers

The Real Impact: Timing and Rhythm

With the new 460-day window, signing stops being a rare chore and becomes part of your operational processes. You notice sooner when a certificate is getting old, and your pipeline stays cleaner because rotation is built into the flow, instead of as an emergency.

For teams already using modern practices, shorter cycles will already match release schedules, so you’re less likely to get blindsided by an expired certificate right before delivery. If you’re moving toward cloud signing or HSM-based keys, the transition will feel smoother as rotation happens quietly in the background.

The Connection to Post-Quantum Cryptography

The 460-day certificate lifecycle creates a natural checkpoint for implementing the cryptographic inventory practices that will be essential for post-quantum cryptography (PQC) migration. While there’s no PQC application yet in code signing, that’s coming.

Organizations transitioning to 460-day certificates should leverage this moment to establish cryptographic posture management tools that inventory not just code signing certificates, but all cryptographic assets across their infrastructure. This positions teams for the larger PQC migration approaching by 2030.

Gartner has emphasized that shorter validity periods serve as forcing functions for better cryptographic discovery programs. The discipline you build now, handling 460-day code signing certificates, translates directly to handling the algorithmic transitions coming in the next few years.

The Four Stages of Crypto-Agility for Code Signing

There are many lessons we can apply from addressing the shrinking validity lifespans of SSL/TLS certificates starting March 15, 2026. With the combination of certificate validity and code-signing lifespans shrinking and compliance requirements tightening, organizations need a structured approach to adapt quickly. Here’s how to build resilience to ensure digital trust:

Stage 1: Visibility

Start with a solid foundation. Discover and inventory all code signing certificates across your development pipeline, build systems, and signing infrastructure. Know what certificates you have, where they’re used, who owns them, and when they expire. Without complete visibility, you can’t prevent signing failures that block releases.

Modern certificate lifecycle management platforms provide automated discovery that finds certificates wherever they live in build servers, CI/CD pipelines, isolated signing environments, and developer workstations.

Stage 2: Timestamping

Ensure every signed artifact includes a valid timestamp. This guarantees that properly signed code remains valid even after the certificate expires. Making timestamping mandatory in your signing workflows is not optional.

Audit your current signing processes to confirm timestamping is configured correctly. Legacy tools may not implement it by default. Systems that don’t verify timestamps properly need updates before the March 2026 deadline.

Stage 3: Advanced Automation at Scale

Enable developers to request and renew code signing certificates through self-service workflows while security maintains governance. Automate certificate deployment to build servers, CI/CD pipelines, and signing tools. Eliminate manual provisioning bottlenecks that slow down release cycles.

Manual certificate management won’t scale to 460-day lifespans, especially as your organization grows. The administrative burden becomes impossible without automation. Modern CLM platforms integrate directly with build pipelines to ensure signing certificates are always current without requiring manual intervention.

Stage 4: Compliance and Control

Enforce enterprise-wide policies for code signing key strength, certificate validity periods, approved algorithms, and proper key storage in HSMs. Maintain audit trails that prove compliance with standards like NIST, Common Criteria, and industry-specific requirements. Make audits straightforward instead of scrambling for documentation.

Policy enforcement keeps automation from becoming chaos. You need guardrails that ensure certificates meet security standards, keys are stored properly, and every signing operation is logged for compliance purposes.

Stage 5: Crypto-Agility

Build resilience to handle shrinking certificate lifespans, algorithm deprecation (RSA to ECDSA transitions), and emerging requirements like post-quantum cryptography for code signing. Centralize management, automate at scale, and enforce consistent policies so you can adapt to cryptographic changes without disrupting software releases.

Crypto-agility isn’t just about speed. It’s about resilience. The cryptographic landscape is shifting faster than most organizations can track. TLS certificate lifespans are shrinking. Widely used encryption algorithms are nearing deprecation. PQC migration timelines are intensifying. To stay secure and compliant through these changes, your organization must be ready to adapt without scrambling.

Certificate Validity Reduction Timeline for Code Signing and TLS Certificates

Effective Date	Code Signing Max Validity	TLS Certificate Max Validity	Key Operational Impact
Pre-2026	39 months (1,170 days)	398 days	Annual or less-frequent renewals
March 1, 2026	460 days (~15 months)	200 days	Semi-annual renewals, and automation becomes essential
March 15, 2027	460 days (~15 months)	100 days	Quarterly TLS renewals and CLM platforms are critical
March 15, 2029	460 days (~15 months)	47 days	Monthly TLS renewals and full automation required
2030 (NIST target)	TBD – PQC algorithms expected	47 days + PQC transition	RSA is deprecated, and crypto-agility is mandatory

What 460-Day Code-Signing Means for Your Pipeline

The 460-day rule lands directly inside development, release, and vendor processes. It forces new habits that ultimately make your pipeline more resilient.

Signing becomes part of your operational release cadence instead of a background task you rarely think about. Certificate expiration moves from a rare emergency to a predictable event you plan for. Teams that adapt early avoid the scramble that happens when everyone realizes their 39-month certificates are expiring and there’s no process to replace them smoothly.

For organizations implementing code signing for the first time, this update sets the right expectations: trust isn’t something that sits untouched for years. It moves with the software it protects. The 460-day window is about protection and predictability.

Industry Trends for Lifespan Reduction

Shorter certificate lifespans are the broader trend across digital trust. Treat all certificates as short-lived. Make renewal simple, lightweight, and automated. Build systems that expect rotation rather than permanence.

March 2026 is approaching fast. Pipelines that adapt early will avoid the scramble later. Organizations that invest in certificate lifecycle management capabilities now will find the transition manageable. Those who wait until their 39-month certificates start expiring will face disruption.

Ready to prepare your code signing infrastructure for the 460-day rule? AppViewX provides complete visibility into your certificate estate, automates signing workflows, and integrates directly with your build pipelines. Learn more about how AppViewX ONE CLM can help you transition smoothly to shorter code signing lifespans while building crypto-agility for what comes next.