Code Signing Certificate Validity: The New 460-Day Limit

What changed: 460 days, not three years

The maximum validity for a publicly trusted code signing certificate is now 460 days — a little over 15 months. Before March 1, 2026, a certificate could be issued for up to about 39 months, so teams routinely bought three-year certificates and renewed rarely. The new limit, set by CA/Browser Forum Ballot CSC-31 (adopted November 17, 2025), applies to both Organization Validation and Extended Validation code signing, with no exceptions for one type over the other.

The 460-day figure isn't arbitrary. It's 395 days — the target validity — plus a 65-day grace window that lets certificate authorities and buyers handle renewals without a hard cliff. The practical takeaway is simpler: the longest term you can now get on a single certificate is a bit over a year, and everything you used to do once every three years, you'll now do roughly annually.

This mirrors a broader industry direction. TLS certificate lifetimes are on their own path down to 47 days by 2029, and code signing is following the same logic a step behind: shorter certificates limit how long a mistake or a compromise can quietly stay in effect.

Why the Forum cut the limit

Shorter certificate lifetimes are a supply-chain security measure. A code signing certificate is a powerful thing to hold: a signature made with it tells Windows, and users, that software is genuinely from your organization. If a signing key is quietly stolen or misused, a long-lived certificate gives an attacker years of runway. Capping validity at 460 days shrinks that window and forces the identity behind the certificate to be re-confirmed far more often.

The change also fits the hardware rules that already reshaped code signing. Since June 1, 2023, every publicly trusted code signing key must be generated and held on certified hardware — a FIPS 140-2 Level 2 or Common Criteria EAL 4+ token, HSM, or cloud signing service — and the key can't be exported. Software-only certificate files stopped being an option then. Shorter validity is the next turn of the same screw: harden where the key lives, then limit how long any one certificate stays trusted. Our code signing certificates explainer covers the hardware mandate and the OV-versus-EV split in more depth.

There's a knock-on effect worth naming. Identity revalidation data — the documents and checks a CA uses to confirm your organization — also has a reuse window that's being shortened alongside validity. When you reissue a certificate after that window closes, you may have to revalidate, so the renewal cadence isn't purely a technical reissue; occasionally it comes with paperwork too.

Who's affected — and who isn't

The dividing line is the issue date, and nothing else. A code signing certificate issued before March 1, 2026 is untouched: it runs to the expiry date printed on it, even if that's two or three years out. There's no retroactive shortening, no forced reissue, and no action required on a certificate you already hold. If yours was issued in 2025 with a long term, keep signing as usual.

The cap meets you at your next issuance — a new purchase, a renewal, or a reissue that produces a fresh certificate. From that point, 460 days is the ceiling, regardless of whether it's OV or EV, and regardless of whether the key sits on a USB token or in a cloud HSM. One scheduling detail matters: the CA/Browser Forum set March 1, 2026 as the deadline, but a few authorities applied their own operational cutoffs slightly earlier, so if you're timing an issuance around the change, confirm the exact date with your CA rather than assuming the first of March everywhere.

Multi-year purchases and reissues

Multi-year products didn't disappear — they changed shape. You can still buy a two- or three-year code signing service, but no single certificate inside it can exceed 460 days. What you're really buying is a paid term backed by free reissues: a first certificate valid for up to 460 days, then a reissue when it nears the end of its window, repeated until your term runs out. The total coverage you paid for is honored; it just arrives as a sequence of shorter certificates.

From how we handle Certum orders, the practical rule is to reissue while the current certificate is still live rather than after it expires. On a two-year purchase, that means requesting the second certificate somewhere in the window between roughly day 270 and day 460 of the first — early enough to avoid a gap, late enough to use most of the first certificate's life. Reissue too late and you risk a stretch where you can't sign a fresh build; reissue while it's still valid and the coverage simply overlaps.

One thing to plan for: if your identity revalidation data has aged out by the time you reissue, the CA may ask you to revalidate before the next certificate is released. It's worth keeping your organization details and contacts current so a reissue doesn't stall on paperwork at an awkward moment. A multi-year plan is still often the better buy under the new rules — it locks your price across a shrinking-validity landscape — but it now comes with a renewal rhythm you should put on a calendar.

Renewing more often, with less friction

When renewals were a once-every-three-years event, the friction of a physical token barely registered. At an annual cadence, it starts to. Every renewal on a shipped USB token can mean waiting on hardware, and depending on how your CA provisions it, occasionally re-keying or replacing the token inside the 460-day window. That's manageable for a solo developer and genuinely awkward for a team that signs from more than one place.

This is where cloud signing earns its keep. With a service like Certum's SimplySign, the private key sits in a certified cloud HSM instead of on a card, so a reissue is a remote operation — no shipment, no physical swap, and the same key infrastructure across renewals. It also travels better: a distributed team signs against one cloud session rather than passing a token around. If you're weighing the two, our comparison of cloud code signing versus USB tokens lays out the trade-offs in delivery time, sharing, and cost.

Two habits make frequent renewals almost boring. First, automate signing in your pipeline so a certificate swap is a configuration change rather than a manual ritual — our guide to code signing in CI/CD covers connecting a build to certified hardware safely. Second, always timestamp every signature: with a shorter certificate life, the gap between "still trusted" and "expired" comes around far more often, and a timestamp is what keeps already-shipped builds trusted long after the certificate behind them lapses.

What to do now

The change doesn't demand a fire drill, but it does reward a little planning. A short checklist covers most teams:

• Note your real expiry. If your certificate was issued before March 1, 2026, it's unaffected — mark the actual date and carry on; the new cap only applies at your next issuance.
• Put renewals on a calendar. Plan to reissue while the current certificate is still valid — for a multi-year plan, inside the reissue window rather than after expiry — so coverage overlaps and you never lose the ability to sign a build.
• Reconsider where your key lives. If you're renewing annually, a cloud signing service usually beats a shipped token on effort, and it's the practical answer for teams and automated pipelines.
• Timestamp everything. A shorter certificate life makes RFC 3161 timestamping non-negotiable, so your released software stays trusted after the certificate expires.
• Keep your details current. Because revalidation windows are shrinking too, up-to-date organization records stop a reissue from stalling on paperwork.