Under the CA/Browser Forum code signing requirements, a code signing certificate issued on or after 1 March 2026 must not be valid for more than 460 days. That means shorter renewal cycles. Plan them, automate what you can, and keep timestamping on so old releases keep verifying.
What the rule says
The current Code Signing Baseline Requirements say the validity period must not exceed 460 days for certificates issued on or after 2026-03-01. The reduction was introduced in version 3.10 of the document. Check the live document before you rely on exact dates, since the requirements get revised.
Why renewals now deserve a calendar
A yearly renewal used to be a task people remembered once in a while. With a cap of 460 days, certificates issued under the new rule will expire sooner than older ones, and any process that depends on one person's memory will fail eventually. A missed expiry means the next release cannot be signed, and it often happens right when a hotfix is due.
What expiry does and does not break
Expiry of the certificate does not make already shipped software suddenly unverifiable, if the signature was timestamped. Timestamping records that the signature existed while the certificate was valid. Without it, a signature can stop validating once the certificate expires. We cover this for Windows in why you should always timestamp releases.
Also check that your timestamp requirements are met. The same CA/Browser Forum document states that SHA-1 is not supported for timestamp tokens, so use SHA-256 for both the file digest and the timestamp digest.
A renewal runbook
- Record the expiry date of every signing certificate in a shared calendar with alerts at 60, 30 and 7 days.
- Name an owner and a backup owner.
- Note which CI jobs, secrets or HSM profiles reference the certificate.
- Renew early, then sign a test build with the new certificate before cutting over.
- Keep the same publisher identity where the CA allows it, because reputation is tied to the identity.
- Keep old certificates archived for verification of old releases, but remove their signing access.
What to automate
Alert on expiry. Run a scheduled pipeline job that signs a dummy file and verifies it. If that job fails, you find out before a release does. Our certificate expiry prevention checklist applies the same thinking to TLS.
Who should own this
Assign renewal to a role, not a person, and put the task in the same system that tracks other operational chores. When the owner leaves, the handover list should include the signing identity, the CA account, the validation contact and the pipeline settings. Many renewals fail because the CA's reminder emails go to a mailbox nobody reads. Use a shared address that several people can see.
Quick check
Do older certificates have to be replaced right now?
The 460 day limit applies to certificates issued on or after 1 March 2026. Older ones keep their original validity, but check your CA for its own terms.
Will expired certificates break installed apps?
Timestamped signatures can still validate after the certificate expires. Unstamped ones may not.
Sources
Last reviewed: 19 October 2026.
