Code-Signing Trust Window Shrinks to 460 Days

Code-signing certificates will soon get much shorter lifespans. A new industry rule approved on 17 November 2025 cuts their maximum validity from 39 months to 460 days, effective 1 March 2026. The change appears in the updated Code Signing Baseline Requirements v3.10.0.

All major CAs in the working group backed the change: 7 voted “YES,” 2 abstained, none opposed. On the platform side, the only participating vendor, Microsoft, also voted “YES.” The clear consensus signals broad industry alignment toward tighter certificate hygiene.

What’s Driving the Push for Shorter Certificate Lifetimes?

In late 2024, researchers at HarfangLab uncovered the Hijack Loader operation, a campaign in which criminals usedvalid code-signing certificates to sign malware built to deploy the Lumma information stealer. Because the files carried legitimate signatures, the malware slipped past many security checks and reached far more victims than an unsigned payload ever would.

There is also a broader shift happening across digital trust. SSL certificates have already moved from multi-year validity to short rotation cycles. Code-signing now follows the same path. With post-quantum cryptography approaching, the industry needs faster turnover, cleaner key management, and more frequent verification. Long-lived certificates slow that transition and leave too much room for silent compromise.

What Changes for Developers?

The new validity window lands directly inside development, release, and vendor processes. The change forces new habits across the chain:

• Systems that rely on long-term keys will need restructuring: Build servers that store a certificate for years won’t survive the shorter cycle. Teams must rotate keys on schedule, update build configs and prevent unexpected expiry mid-release.
• Air-gapped signing environments will 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 cert.
• 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 cert that stays valid long after a breach. Organizations still need to revoke quickly, but the blast radius shrinks.
• Compliance and identity teams will operate on a tighter clock: Teams that manage EV or organization validation must adjust their internal calendars so renewal delays don’t block product releases.

Code Signing Certificate Availability and HSM Requirements

Code-signing options depend on the Certificate Authority, and this directly affects how you manage your keys:

• DigiCert and GoGetSSL only offer 1-year code-signing certificates. You can choose either a CA-provided hardware security module (HSM) or use your own HSM.
• Sectigo (Comodo) lets you order certificates for up to 3 years, but the setup changes:
  • For a 1-year certificate, you can use a CA-provided HSM or your own HSM.
  • For 2- or 3-year certificates, you must use your own HSM. No CA hardware is provided.

If you go multi-year, you take full control of key storage and security.

What It Means When You’re the One Shipping Builds?

The 460-day window changes one thing above all: timing. Signing stops being a rare chore and becomes part of your release rhythm. You notice sooner when a cert is getting old. And your pipeline stays cleaner because rotation is built into the flow, not an emergency.

For SSL Dragon customers, this shift aligns with how most teams already operate. Shorter cycles line up with modern release schedules, so you’re less likely to get blindsided by an expired cert right before a delivery. If you’re moving toward cloud signing or HSM-based keys, the transition feels even smoother, and rotation happens quietly in the background.

The Trend Is Clear: Shorter Trust, Faster Rotation

Shorter lifetimes won’t fix every supply-chain risk, but they push the industry toward healthier practices. Signing keys can no longer sit unnoticed for years, and release workflows must stay aligned with the new rhythm. March 2026 is approaching fast, and the pipelines that adapt early will avoid the scramble later.

SSL Dragon’s Take

From our side of the fence, this change is good news. It creates cleaner habits and reduces the damage a lost or stolen key can do. The teams that suffer most from certificate issues are rarely the ones with bad intentions. They’re the ones who had a single long-lived cert buried in an old build machine and found out about it at the worst possible moment. A 460-day window forces that risk into the open.

For our customers, the shift is mostly about awareness rather than workload. The shorter window makes certificate rotation part of the natural release instead of a rare maintenance task. The faster cycle also exposes where older pipelines or forgotten machines still depend on long-lived certificates without anyone noticing, which is often where delays or security gaps appear.

If you’re getting code signing for the first time, this update sets correct expectations. Trust isn’t something that sits untouched for years. It moves with the software it protects. The new window is all about protection and predictability, and we’re here to help customers choose the right products and workflows so the transition feels smooth, not disruptive.

Source: CA/Browser Forum – Ballot CSC-31: Code Signing Certificate Lifetime Reduction