Code Signing Certificate Validity Reduction Starting March 1, 2026

Imagine setting a calendar reminder for something three years in the future. That’s been the reality for code signing certificate management — buy a cert, file the paperwork, set a reminder, forget about it until the renewal notice arrives. That era ends on March 1, 2026.

Starting then, new code signing certificates max out at 1 year (398 days). That 3-year cert you were planning to renew in 2028? Fine — existing certs remain valid. But the next one you buy will last one year. And the one after that. This isn’t a temporary policy; it’s the industry converging on shorter lifespans across all certificate types, and you’ll want to be operationally ready before the date arrives.

What’s Changing?

Current State (What We’re Leaving Behind)

• Maximum validity: 3 years (approximately 1,095 days)
• Common practice: Buy a cert, forget about it for 2-3 years
• Renewal frequency: That one time you had to scramble when your cert expired unexpectedly

New Reality (Starting March 1, 2026)

• Maximum validity: 1 year (398 days)
• All new certificates: Must comply with the new limit—no exceptions, no CA will issue longer
• Existing certificates: Can remain valid until expiration (so that 3-year cert you bought in 2025 is safe)
• Timeline: Mandatory from March 1, 2026
• Real-world impact: You’ll be renewing certificates 3x more often, which means 3x more chances to forget, 3x more procurement hassle, 3x more deployment headaches

Who Is Affected?

If you’re involved in shipping software, this affects you:

• Software developers who sign applications, executables, installers, and anything that needs to convince Windows/macOS that it’s not malware
• DevOps teams managing CI/CD pipelines—prepare to update your certificate rotation playbooks
• Release engineers who already dread certificate renewals during critical release windows
• IT/Security teams responsible for certificate lifecycle management and dealing with expired cert incidents at 3 AM
• Organizations that distribute signed software (Windows apps, macOS apps, mobile apps, browser extensions)
• Hardware vendors signing firmware and drivers—one expired cert and your entire hardware line stops working

The good news? You’re not alone. Everyone’s dealing with this.
The bad news? You’ll be dealing with it every year now.

Why Is This Happening?

The CA/Browser Forum (the folks who decide these things) isn’t doing this to annoy you—though it certainly feels that way. There are legitimate security reasons:

1. Enhanced Security (The Theory)

• Reduced exposure window: If someone steals your private key, they can only abuse it for a year instead of three
• Faster key rotation: More frequent renewals = newer cryptographic keys more often
• Modern cryptographic standards: Forces organizations to adopt stronger algorithms instead of clinging to old certificates with outdated crypto

2. Better Incident Response (The Reality Check)

• Faster recovery: When a CA gets compromised or your private key leaks, shorter validity means less long-term damage
• Reduced revocation challenges: Ever tried to revoke a 3-year-old certificate that’s embedded in a million installed applications? It’s a nightmare
• Practical impact: You’ll spend less time explaining to management why that compromised cert from 2 years ago is still a problem

3. Compliance and Industry Alignment

• Trend alignment: SSL/TLS certificates already went through this pain—now it’s code signing’s turn
• Regulatory pressure: Security frameworks and compliance requirements increasingly mandate shorter certificate lifespans
• Audit trails: More frequent renewals = more documentation for your ISO 27001 auditor to review (you’re welcome)

The Broader Context: SSL/TLS Certificate Validity Reduction

Code signing isn’t the only area seeing shorter certificate lifespans. If you want the full picture of where SSL/TLS certificates are headed — including the proposed move to 47-day validity periods — our detailed breakdown of SSL/TLS certificate validity shortening: 200, 100, and 47 days covers what that means operationally. The CA/Browser Forum has been progressively reducing SSL/TLS certificate validity periods:

The SSL/TLS Timeline

• Before 2015: Certificates valid for up to 5 years
• 2015-2018: Maximum reduced to 3 years (1,095 days)
• 2018-2020: Further reduced to 2 years (825 days)
• September 2020: Current maximum of 398 days (13 months)
• Proposed future changes:
  • Reduction to 200 days
  • Further reduction to 100 days
  • Eventually down to 47 days
  • DCV (Domain Control Validation) reuse period reduction to 10 days

Why This Matters

This isn’t just bureaucracy—shorter validity periods mean:

• Better security: Compromised certificates have a smaller window of abuse
• Faster crypto agility: Organizations adopt new algorithms and key sizes more frequently
• More operational overhead: More frequent renewals mean more chances for human error, forgotten certificates, and service outages

The code signing validity reduction to 1 year (398 days) is part of this industry-wide trend toward shorter certificate lifecycles.

What You Need to Do

Here’s the playbook. Follow it now before you’re firefighting an expired cert during a critical release.

1. Audit Your Current Certificates (Start Here)

Find all your code signing certificates before they find you:

# Check certificate expiration dates
# Windows (PowerShell)
Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object {$_.EnhancedKeyUsageList -match "Code Signing"}

# macOS/Linux (check keychain/keystore)
security find-identity -v -p codesigning

Action items:

• Create an inventory of all code signing certificates (yes, including that one the contractor bought 2 years ago that nobody documented)
• Document which applications/products use each certificate—trust me, future-you will thank you
• Identify certificates expiring after March 1, 2026
• Find out who actually has access to renew these things (spoiler: it’s probably someone who left the company)

2. Update Your Renewal Process (Before It Bites You)

Establish a renewal calendar that actually works:

• Set reminders 60 days before expiration (and 30 days, and 7 days, because you’ll ignore the first two)
• Plan for annual renewal process instead of “set it and forget it for 3 years”
• Budget for more frequent CA fees—finance won’t be happy
• Assign backup contacts for renewals (because the primary will be on vacation when it expires)

Automate where possible (or face the consequences):

• Integrate certificate monitoring into your DevOps pipeline
• Set up alerts that actually notify the right people (not just a shared mailbox nobody checks)
• Consider using centralized certificate management tools like CrtMgr to track all your certificates in one place—when you’re managing dozens of certificates with annual expirations, a spreadsheet won’t cut it
• Test your alerting system before you rely on it

3. Review Your CI/CD Pipeline (This Is Critical)

Update build and signing processes:

• Ensure your CI/CD tools can handle certificate rotation without breaking the entire build
• Document certificate replacement procedures (step-by-step, as if explaining to someone who’s never done it before)
• Test certificate updates in staging environments—never test in production
• Add certificate expiration checks to your pre-build validation
• Plan for rollback procedures when things go wrong

Example GitHub Actions workflow update:

- name: Check Code Signing Certificate Expiry
  run: |
    CERT_EXPIRY=$(security find-certificate -c "Your Code Signing Cert" -p | openssl x509 -noout -enddate)
    echo "Certificate expires: $CERT_EXPIRY"
    # Add logic to warn if expiring within 60 days
    # Better yet, fail the build if expiring within 30 days

Real-world considerations:

• Certificate updates during active development can block releases
• Plan your renewal windows during low-activity periods
• Have a communication plan for when certificate rotation causes issues
• Keep old certificates accessible for verifying historical signatures

If you’re managing certificates in Kubernetes environments alongside code signing certs, cert-manager with Let’s Encrypt can handle the SSL/TLS side automatically while you focus on the code signing workflow.

4. Implement Timestamping (Non-Negotiable)

Critical: Always use RFC 3161 timestamping when signing code! This is not optional.

Here’s why: Timestamping proves that your code was signed when the certificate was valid. Without it, your signature expires when the certificate expires. That means:

• Your software gets blocked by Windows SmartScreen
• macOS Gatekeeper refuses to run it
• Users see scary warning messages
• Your support team gets flooded with “this app won’t run” tickets
• You have to re-sign and re-distribute everything

With timestamping, your signed code remains valid indefinitely, even after the certificate expires. It’s the difference between “sign once, work forever” and “re-sign everything annually.”

Example timestamping usage:

# Windows (signtool)
signtool sign /f certificate.pfx /p password /t http://timestamp.digicert.com /fd sha256 application.exe

# macOS (codesign with timestamp)
codesign -s "Developer ID Application" --timestamp application.app

# Java (jarsigner)
jarsigner -tsa http://timestamp.digicert.com -keystore keystore.jks application.jar

Recommended timestamp authorities:

• DigiCert: http://timestamp.digicert.com
• Sectigo: http://timestamp.sectigo.com
• GlobalSign: http://timestamp.globalsign.com

Pro tips:

• Always verify timestamping worked after signing
• Use multiple timestamp servers as fallback (some have occasional downtime)
• Monitor timestamp server availability in your build pipeline
• If timestamping fails, your build should fail—don’t ship untimestamped binaries

5. Plan for Hardware Security Modules (HSMs)

For enhanced security (and to make your security team happy), consider using HSMs or cloud-based signing services:

• Benefits: Private keys never leave the HSM, centralized signing, audit logging, role-based access
• Cloud options: Azure Key Vault, AWS CloudHSM, DigiCert ONE, Google Cloud HSM
• On-premise: USB security tokens (like YubiKey), network-attached HSMs (Thales, nCipher)
• Cost consideration: More expensive upfront, but better security and potentially easier key rotation

Reality check: If you’re signing software that thousands of users depend on, storing your private key in a .pfx file protected by a password in a Jenkins environment variable is not a great security posture.

6. Update Documentation and Training (Don’t Skip This)

• Update internal documentation with new certificate validity periods and renewal procedures
• Train developers on new renewal schedules—make sure they know it’s annual now
• Communicate changes to stakeholders who approve certificate purchases (procurement, finance, security team)
• Document the blast radius: What breaks when a certificate expires? Who needs to be notified? What’s the emergency procedure?
• Create runbooks: Step-by-step guides for both planned renewals and emergency “oh crap the cert expired” scenarios

Transition Timeline

Common Questions

Q: Do I need to replace my existing 3-year certificate?
A: No, existing certificates can remain valid until their expiration date. The new limit only applies to certificates issued on or after March 1, 2026. So if you bought a 3-year cert in February 2026, congrats—you’ve got until 2029.

Q: Will this affect my already-signed software?
A: If you used timestamping (you did, right?), your already-signed software will continue to work indefinitely. If you didn’t use timestamping, signatures expire with the certificate, and you’ll need to re-sign everything. This is why timestamping is critical.

Q: Can I get a longer validity period from my CA?
A: No, this is an industry-wide standard enforced by all trusted Certificate Authorities. They literally cannot issue longer certificates without losing their trusted status. Asking won’t help.

Q: How does this affect Extended Validation (EV) code signing certificates?
A: The same 1-year limit applies to both standard and EV code signing certificates. EV certs still require additional validation and typically use hardware tokens, but they’re also limited to 398 days.

Q: Will certificate prices increase due to more frequent renewals?
A: CA pricing models vary. Some may adjust pricing to reflect annual purchases, while others might offer multi-year bundles where you buy multiple 1-year certificates at a discount. Expect to pay more overall—that’s the cost of “enhanced security.”

Q: What happens if I forget to renew and my certificate expires?
A: If you’ve been timestamping (seriously, use timestamping), your existing signed software continues to work. But you can’t sign new releases until you get a new certificate. This means production disruption, angry users, and awkward conversations with your manager about why the release is blocked.

How CrtMgr Can Help

When you’re juggling SSL/TLS certificates that expire every 13 months and code signing certificates that also expire annually, centralized certificate management stops being a “nice to have” and becomes essential.

While CrtMgr primarily focuses on SSL/TLS certificate management, the operational challenges are similar: more certificates, shorter lifespans, more frequent renewals, and more opportunities for something to slip through the cracks.

Why centralized management matters with shorter validity periods:

• Single source of truth: Stop maintaining spreadsheets that are outdated the moment you save them
• Automated alerts: Get notified 60, 30, and 7 days before expiration—sent to the right people, not buried in a shared mailbox
• Audit trails: Document every renewal, every expiration, every incident for compliance reviews
• Integration: Connect with your monitoring, alerting, and ticketing systems so certificate management becomes part of your normal workflow

The reality is simple: the more certificates you manage, and the more frequently they expire, the more critical it becomes to have a system that tracks them automatically. Manual tracking worked when certificates lasted 3 years. It won’t work when they last 1 year.

Resources and Further Reading

The CA/Browser Forum Code Signing Working Group maintains the official standards. Microsoft and Apple both provide comprehensive code signing best practices guides. NIST offers detailed guidelines on key management that apply to code signing scenarios.

The shift from 3-year to 1-year code signing certificate validity is an operational change that happens to come with security benefits. The security argument is real — shorter lifespans reduce exposure windows and force more frequent key rotation. But for most teams, the practical impact is simply: more work, more coordination, and more chances for human error if you don’t automate.

The organizations that come through this change without disruption will share a few traits: they audited their certificate inventory early, they automated renewal before the deadline forced their hand, they implemented proper timestamping (non-negotiable), and they built monitoring so nothing expired silently.

Start with the audit. Find every code signing certificate in your organization — including the ones nobody documented. Then build the calendar, automate what you can, and document the manual steps for what you can’t. The March 2026 deadline is fixed; your level of preparation isn’t.

Need help managing your SSL/TLS certificates? Check out CrtMgr for automated certificate monitoring and lifecycle management.