How to Renew a Code Signing Certificate in 2026

What renewing actually replaces

Renewal produces a new certificate. Validity dates are covered by the CA's signature, so they cannot be edited after issuance without destroying the thing that makes the certificate trustworthy. When a CA offers renewal, what it is offering is a shorter path through validation and a continuing commercial relationship. The certificate you hold is still going to lapse on the date printed inside it.

That distinction matters because three separate things get filed under the same word, and they behave very differently. The binaries you already published are one thing. The certificate in your token or cloud account is another. The reputation Microsoft has built up against that certificate is a third, and it is the only one that cannot be re-purchased.

Teams that treat renewal as a procurement task — buy the SKU, install it, done — tend to discover the third item after cutover, usually through a support ticket from a customer who has just been told the installer is not commonly downloaded. Teams that treat it as a migration schedule the overlap and never hear about it.

Do already-signed builds stop working when the certificate expires?

Timestamped builds keep validating indefinitely. An RFC 3161 timestamp is a countersignature from an independent authority recording that your signature existed at a specific moment, and verifiers check the certificate's validity against that moment rather than against today's date. Expiry does not reach backwards into files that were signed while the certificate was live.

Builds signed without a timestamp behave in the opposite way, and the failure is abrupt: they verify normally right up to the expiry date and then stop, everywhere at once, on software that may have shipped years earlier. There is no repair short of re-signing each affected artifact with the new certificate and redistributing it, which for a desktop installer with an existing install base is considerably more work than it sounds.

This is why timestamping every signature is worth treating as non-negotiable rather than as a flag you sometimes remember to pass. The cost is one extra argument to signtool. The cost of skipping it is discovered on the day your certificate lapses, by your users.

Why renewal now lands every 15 months

As of March 1, 2026, publicly trusted code signing certificates max out at 460 days — roughly fifteen months — down from the previous 39-month ceiling. The change came from CA/Browser Forum Ballot CSC-31, adopted on November 17, 2025 as version 3.10.0 of the Code Signing Baseline Requirements, and it applies to OV and EV alike.

Certificates issued before that cutoff are not affected retroactively; they run out whatever term they were issued with. So the shift arrives unevenly. A team whose three-year certificate was issued in early 2025 still has a long runway, then hits a permanently shorter cycle at its next renewal, with no transition period in between.

The budget conversation is the easy part of this. The part worth planning is that everything renewal drags along with it — the revalidation paperwork, the CI credential rotation, the reputation restart — now recurs annually instead of once every three years. The full breakdown of the 460-day limit covers the rule itself and how CAs are handling multi-year subscriptions underneath it.

Does SmartScreen reputation carry over to the renewed certificate?

No, and Microsoft documents no supported way to transfer it. SmartScreen accumulates reputation against the signing certificate, and a renewed certificate has a different thumbprint, so it arrives with no download history behind it. The only path Microsoft describes is to keep signing with the new certificate and let reputation rebuild from real traffic.

How much this hurts scales inversely with your download volume. A widely distributed installer can accumulate enough clean downloads to clear warnings fairly quickly. A specialist tool with a few hundred users a month can sit in warning territory long enough for it to show up in your support queue. The users who see it are disproportionately the ones evaluating your software for the first time.

It is worth being precise about EV here, because the expectation gap is common. EV code signing is the stronger identity check and is still required for kernel-mode driver signing through the Windows Hardware Program. What it does not do in 2026 is exempt a brand-new certificate from the reputation-building process; Microsoft no longer documents an automatic SmartScreen bypass for EV. If you are renewing an EV certificate specifically to avoid warnings, plan the overlap anyway. Our walkthrough of how SmartScreen publisher reputation works goes through the signals in detail.

Planning the overlap

The overlap is the stretch where both certificates are valid and you sign releases with both. It exists only if you order the new certificate well before the old one expires, and it is the one mechanism that lets a new certificate accumulate download history while the old one is still carrying your users. Sixty days of overlap is a reasonable target.

Dual-signing is supported by the Authenticode format: a file can carry more than one signature, and Windows evaluates them together. In practice you run your normal signing step twice, appending the second signature rather than replacing the first, and timestamp both. Installers built by tooling that assumes a single signature are the usual snag, so test the dual-signed artifact on a clean machine before it goes into a release.

If dual-signing is genuinely impractical for your build, the fallback is to cut over early rather than late: switch to the new certificate as soon as it is issued, while the old one is still valid as a rollback option. You lose the reputation-bridging effect, but you find any pipeline problem with weeks of slack left instead of hours.

New token, or the same key?

Since June 1, 2023, the private key for any publicly trusted code signing certificate — OV and EV both — must be generated and held in hardware certified to FIPS 140-2 Level 2 or Common Criteria EAL 4+, and it must be non-exportable. That rules out the software PFX files that used to make renewal a file swap, and it is why renewal now involves provisioning as well as purchasing.

An existing physical token can often be reused if it still meets those requirements and your CA supports loading a new certificate onto it. Reusing the key pair, where the CA permits it, keeps previously signed artifacts chaining to the same key. It does not preserve reputation, though, because the thumbprint is derived from the whole certificate rather than the key alone. Generating a fresh key pair at renewal is the more common recommendation on security grounds.

Renewal is also the natural moment to reconsider where the key lives. A physical token means someone has to be holding it to cut a release, which quietly caps how automated your pipeline can be; a cloud signing service removes both the shipping wait and the single-holder problem. The tradeoffs are laid out in cloud code signing versus USB tokens, and if you are moving from a token, My-SSL's cloud-delivered code signing certificates skip the hardware step entirely.

A renewal timeline you can copy

Working backwards from the expiry date beats working forwards from whenever the renewal notice lands. The schedule below assumes an established organization renewing with the same CA; a first EV issuance or a company whose registered details have changed should add two to three weeks to the validation stage.

One practical note on multi-year purchases: a three-year plan no longer buys a three-year certificate, because no CA can issue one. It buys the right to a reissue at each 460-day boundary at a locked price. That is a real saving, and it is worth knowing it does not remove a single step from the schedule above: you still revalidate, reprovision, and restart reputation each time. If you want the price side of that comparison, our code signing plans list the reissue terms alongside each option.

The mistakes that cost the most

Renewal problems that reach a reseller support queue are remarkably consistent, and almost none of them are technical. They cluster into four patterns, in rough order of how expensive they turn out to be.

• Starting at the expiry notice. A renewal begun the week the certificate lapses cannot have an overlap, so the reputation restart happens on a live release with no cover. Ordering ninety days out costs nothing extra.
• Assuming EV skips the queue. Buying EV at renewal specifically to avoid warnings tends to produce a second surprise on top of the first, because the new EV certificate builds reputation from zero like any other.
• Stale company details. A registered address, legal name or phone listing that has changed since the last issuance turns a routine revalidation into a multi-week exchange. Checking the registry entry before ordering is a five-minute job.
• Untimestamped history. Renewal is when teams find out which past builds were signed without a timestamp, because those are the ones that break at expiry. Auditing before the date is far cheaper than after.

None of these need a bigger budget. They need the renewal to be on someone's calendar as a project with a start date, rather than as an invoice that shows up.

Frequently asked questions