title: “Code Signing Certificate Changes in 2026: What Enterprise Teams Need to Know”
slug: “code-signing-certificate-changes-2026-enterprise-preparation-guide”
url: “/code-signing-certificate-changes-2026-enterprise-preparation-guide”
date: “2026-05-06”
author: “Mike Walton”
keywords:
– “code signing certificate”
– “code signing certificate 460 days”
– “code signing certificate management”
– “software supply chain security”
– “HSM code signing”
tags:
– “Certificate Management”
– “Code Signing”
– “IT Security”
– “Software Development”
status: “draft”

Code Signing Certificate Changes in 2026: What Enterprise Teams Need to Know

By Mike Walton, Founder of CertMS

If your organization signs software—internal applications, drivers, scripts, or anything else—you’re probably about to deal with a significant operational shift. As of March 1, 2026, code signing certificates are capped at 460 days of validity. That’s down from the previous 39-month (roughly 1,095 days) maximum.

With 20+ years in IT infrastructure and PKI management, I’ve seen plenty of certificate policy changes come and go. This one is different. It’s not just a minor adjustment—it’s a fundamental rethinking of how the industry handles software trust. And it hits right as SSL/TLS certificates are also shrinking to 200 days, creating a perfect storm of renewal complexity.

Let me break down what changed, why it happened, and what your team needs to do about it.

What Actually Changed on March 1, 2026

The CA/Browser Forum passed Ballot CSC-31 in November 2025, cutting the maximum validity period for publicly trusted code signing certificates from 39 months to 460 days. Both Organization Validation (OV) and Extended Validation (EV) certificates fall under this new limit.

Two weeks later, on March 15, 2026, a separate change reduced the subject identity information validation reuse period to 398 days. That means even if your certificate is still technically valid, the identity verification behind it expires sooner, which can complicate multi-year renewal strategies.

Here’s the timeline that matters:

• February 16, 2026: Major CAs including DigiCert and Sectigo stopped accepting requests exceeding the new thresholds
• March 1, 2026: The 460-day maximum officially took effect for all new code signing certificates
• March 15, 2026: Identity validation data reuse dropped to 398 days

If you purchased a code signing certificate before these dates, it remains valid for its original lifespan. But any new certificate issued after March 1 can’t exceed 460 days.

Why the Industry Made This Change

Two forces drove this decision: real-world attacks and operational stagnation.

In late 2024, security researchers at HarfangLab uncovered the Hijack Loader operation. Criminals obtained legitimate code signing certificates and used them to sign malware—specifically, payloads deploying the Lumma information stealer. Because the files carried valid signatures, security tools trusted them. The malware reached far more victims than unsigned payloads would have.

Then in April 2026, things got worse. According to CipherSecurity’s analysis, attackers compromised DigiCert’s internal support portal and fraudulently obtained 60 Extended Validation code signing certificates. At least 11 of those certificates were used to sign Zhong Stealer malware—a credential and cryptocurrency theft tool linked to threat group APT-Q-27. DigiCert revoked all identified certificates by April 17, 2026, but the damage highlighted just how valuable stolen code signing certificates are to attackers.

The logic behind shorter validity periods is straightforward: if a private key gets compromised, the window of exploitation shrinks dramatically. Instead of attackers having three years to abuse a stolen certificate, they get 15 months at most. And if organizations rotate keys with each renewal, that window shrinks even further.

Research from Google and GitGuardian found that over 140,000 TLS certificates could be mapped to leaked private keys discovered on GitHub and DockerHub. As of September 2025, 2,600 of those certificates were still valid. The average time it takes attackers to penetrate a supply chain system hovers around 15 months—almost exactly matching the new 460-day limit.

The HSM Factor: Hardware Security Requirements

Here’s something that catches teams off guard: the CA/Browser Forum’s Baseline Requirements have required FIPS 140-2 Level 2 hardware security modules (HSMs) for all new code signing certificates since June 1, 2023.

That means your code signing private keys can’t just sit in a software keystore on a build server. They need to be stored in tamper-resistant hardware—either physical USB tokens, network-attached HSMs, or cloud HSM services like Azure KeyVault, Google Cloud KMS, or DigiCert KeyLocker.

For organizations still using physical hardware tokens, the 460-day validity period creates significant logistics. Many teams historically purchased multi-year token-based certificates and renewed infrequently. That workflow is now obsolete. You’ll need to either:

• Replace tokens annually: Order new tokens, distribute them to signing workstations, update build processes
• Migrate to cloud-based key storage: Services that handle certificate lifecycle management behind the scenes, making renewals largely invisible to your development workflow

The second option is where the industry is heading. GlobalSign and other enterprise-focused CAs are pushing hard on cloud key management precisely because it eliminates the token logistics nightmare.

Impact on CI/CD Pipelines

If your organization signs code as part of automated build pipelines, you’re going to feel this change.

Manual CI/CD pipelines that reference static certificate files will break when those certificates expire. Any pipeline that was configured once and “just works” needs attention. Teams that haven’t automated certificate rotation into their deployment processes need to update pipelines before deadlines hit.

AppViewX’s analysis recommends integrating certificate issuance and rotation directly into build pipelines using the ACME protocol or CA-provided APIs. The goal is making renewal invisible to developers—the signing workflow continues working while certificate management happens automatically in the background.

For organizations managing multiple code signing certificates across different products, teams, or platforms, this means:

• Inventory all certificates: Know what code signing certificates you have, where they’re used in which pipelines, and when they expire
• Document signing workflows: Which build servers sign code? What tools do they use? Where are private keys stored?
• Test renewal procedures: Before a certificate actually expires, verify that your team knows how to renew it and update the build pipeline

If your organization signs both public software (using publicly trusted CA certificates) and internal applications (potentially using internal CA certificates), you may have different management requirements for each. Public certificates fall under the 460-day rule; internal certificates follow whatever policy your organization sets.

Timestamping Becomes Critical

Here’s the most important audit item most teams overlook: timestamping configuration.

When you sign code with a timestamp from a trusted timestamping authority, that signature remains valid even after your code signing certificate expires. The timestamp proves the code was signed while the certificate was still valid.

Without proper timestamping, your signed code becomes untrusted the moment your certificate expires. For software with long deployment lifecycles—think enterprise applications running for years, embedded systems, or archived releases—this creates major problems.

With 460-day certificates, timestamping isn’t optional anymore. Every signing operation should include a timestamp from a reputable authority. Your build pipelines need to be configured to fail if timestamping fails—better to catch the problem during development than discover years later that a critical release has invalid signatures.

The Double Deadline Problem

Here’s what makes 2026 particularly challenging: code signing certificate validity dropped to 460 days on March 1, and SSL/TLS certificate validity dropped to 200 days on March 15. Two major certificate policy changes hit within two weeks of each other.

Organizations already scrambling to handle shorter TLS certificate lifespans now face parallel challenges with code signing. The skills and tooling overlap, but the workflows differ. TLS certificate renewal is often automated via ACME protocol; code signing renewal typically involves more manual steps, especially with HSM-stored keys.

If your certificate management strategy relies on manual tracking and periodic renewal projects, you’re facing compounding complexity. The math on manual certificate management was already brutal for TLS certificates alone. Add code signing certificates to the mix, and the workload becomes unmanageable.

Existing Certificates Are Grandfathered

One piece of good news: certificates issued before March 1, 2026 remain valid for their original lifespan. If you purchased a 39-month code signing certificate in February 2026, it continues working until it naturally expires—you’re not forced to replace it early.

This matters for planning. Organizations with recently issued long-validity certificates have a grace period to prepare. Those whose certificates expire in the coming months need to act immediately.

Check your code signing certificate inventory now. Any certificate expiring after mid-2026 will need replacement with a 460-day certificate. Build that into your renewal planning.

Preparation Checklist for Enterprise Teams

If you manage code signing certificates for your organization, here’s what to tackle:

This Week

• Inventory all code signing certificates – Where are they? What products/teams use them? When do they expire? What HSM or key storage method is used?
• Identify certificates expiring in the next 6 months – These are your immediate priorities
• Document current signing workflows – Which build servers? Which tools? What’s the renewal process?

This Month

• Evaluate cloud HSM options – If you’re still on physical tokens, consider migration to reduce renewal complexity
• Verify timestamping configuration – Every signing operation should include a timestamp; pipelines should fail if timestamping fails
• Update renewal procedures – Ensure documentation reflects the 460-day reality

This Quarter

• Automate certificate lifecycle where possible – API-driven renewal integrated into build pipelines
• Train development teams – Make sure developers understand the changes and know how to request renewals
• Plan HSM migration – If moving from physical tokens to cloud HSM, start the project now

INTERNAL LINK: [Certificate Discovery: Finding the Certs Your Team Forgot About]

How CertMS Helps

While CertMS focuses on certificate monitoring rather than code signing automation, it provides the visibility foundation that makes code signing certificate management tractable.

Here’s how:

Certificate inventory: CertMS tracks certificates across your infrastructure, including code signing certificates installed on build servers. You get a centralized view of what certificates exist and when they expire.

Expiration alerting: Configure alerts at multiple intervals—90 days, 60 days, 30 days—so your team has runway to handle renewals before pipelines break.

Server association: CertMS maps certificates to the servers where they’re deployed. When a code signing certificate approaches expiration, you know exactly which build servers need attention.

Documentation integration: Attach renewal procedures directly to certificates. When an alert fires, responders get context immediately instead of hunting for instructions.

Help desk integration: Trigger automatic ticket creation when certificates approach expiration. Renewals become part of your existing workflow rather than a separate process.

For organizations juggling the combined complexity of shorter TLS and code signing certificate lifespans, centralized visibility isn’t optional—it’s survival.

INTERNAL LINK: [Maintaining Digital Trust: A Deep Dive into CertMS Features]

The Bottom Line

Code signing certificate management just got more demanding. The 460-day maximum validity period means more frequent renewals, tighter operational discipline, and—for many organizations—fundamental changes to signing workflows.

The organizations that will handle this smoothly are those investing in visibility and automation now. They know what certificates they have, they’ve automated what can be automated, and they’ve documented procedures for everything else.

The organizations that will struggle are those running on manual processes, physical HSM tokens distributed across teams, and build pipelines configured once and never touched.

With supply chain attacks increasing and certificate lifespans shrinking, the gap between these two groups is about to become very visible.

Don’t let your software updates become the next malware delivery vector because a code signing certificate quietly expired.

---

Need visibility into your certificate landscape? CertMS discovers and tracks certificates across Windows CAs, servers, and URLs—giving you the centralized monitoring and alerting that keeps certificates from becoming emergencies. Start your free trial and see what’s hiding in your infrastructure.

---

Mike Walton is the founder of CertMS, a certificate management platform. He has 20+ years of experience in IT infrastructure and PKI management.

---

*Word count: 2,124*

Sources:

• AppViewX: Code Signing Certificates Drop to 460 Days in 2026
• DigiCert: Understanding the New Code-Signing Certificate Validity Change
• GlobalSign: Businesses Must Prepare for Certificate Lifecycle Reductions
• Security Boulevard: Code Signing Certificate Validity Changes Now in Effect
• CipherSecurity: DigiCert Support Portal Breach
• GitGuardian: Certificates Exposed Study
• CA/Browser Forum: Code Signing Baseline Requirements
• SSL2Buy: Code Signing Certificate Validity Reduced