Publicly trusted code signing certificates issued on or after 1 March 2026 can last no more than 460 days, so the old habit of buying a three-year certificate and forgetting about it no longer works. The change sits on top of the hardware key rule that took effect on 1 June 2023 and stricter timestamping and revocation rules, all set by the CA/Browser Forum Code Signing Baseline Requirements (CSBR). This guide covers what changed and when, which signing set-ups break, how to find every signing key and certificate you own, and how to move to a renewal model that copes with yearly replacement. It is written for release engineers, PKI owners and security architects. For the wider controls around signing keys, see the Code Signing Security Guide.
Key takeaways
- 460 days is the new ceiling. CSBR section 6.3.2 limits certificates issued on or after 1 March 2026 to 460 days; certificates issued before that date keep their original term of up to 39 months until they expire.
- Keys must live in certified hardware. Since 1 June 2023 the subscriber key must be generated, stored and used in a hardware crypto module certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, a cloud HSM meeting the same bar, or a compliant signing service.
- Timestamping decides whether old releases survive. A signature with an RFC 3161 timestamp stays verifiable after the certificate expires; without one, Windows treats the file as unsigned once the certificate lapses.
- Renewal becomes a yearly engineering event. Plan for at least one certificate replacement a year per signing identity, with identity revalidation, new key attestation and pipeline changes each time.
- Treat signing keys as non-human identities. Every key, certificate and service account that can request a signature needs an owner, an inventory entry and monitored use.
What is changing and why
The CSBR is the rulebook that publicly trusted certificate authorities (CAs) must follow when issuing code signing and timestamp certificates. Root programmes such as Microsoft's rely on it, so a CA that ignores it risks distrust. The current version is 3.11.0, dated 16 June 2026. Three groups of change matter to software publishers:
- Validity reduction: Ballot CSC-31 (Maximum Validity Reduction) produced version 3.10, effective 7 November 2025. It amended section 6.3.2 so that code signing certificates issued on or after 1 March 2026 must not exceed 460 days. Certificates issued before that date were capped at 39 months.
- Hardware key custody: From 1 June 2023 the CA must ensure the subscriber's private key is generated, stored and used in a suitable hardware crypto module, and must verify this using one of the methods listed in section 6.2.7.4.2. The older options of software keys and uncertified USB tokens for non-EV certificates ended with that date.
- Timestamping and revocation tightening: Ballot CSC-26 (effective 1 August 2024) strengthened protection of timestamping keys, and the 15 April 2024 revocation change aligned the CSBR with the TLS and S/MIME rules, with stricter handling of key compromise and suspect code.
The reasoning is the same as for shorter TLS certificates: a shorter life limits how long a stolen or mis-issued certificate stays useful and forces publishers to revalidate their identity more often. The CSBR also states that signatures may be verified at any time, including during installation, execution or a forensic investigation, which is why timestamping and revocation dates carry so much weight. The TLS side of the same trend is covered in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Official timeline and current status
Dates below are taken from the CSBR version 3.11.0 "Relevant Dates" and revision tables on the CA/Browser Forum site and its official GitHub repository, checked on 8 November 2026. The Forum can change the rules by ballot, so confirm against the current CSBR before committing a plan.
| Effective date | CSBR section | Requirement | Status at 8 Nov 2026 |
|---|---|---|---|
| 1 June 2021 | 6.1.5 | Minimum RSA 3072 for code signing certificates; no SHA-1 for code signing certificates | In force |
| 1 June 2021 | 6.2.7.4 | Signing services protect keys in a FIPS 140-2 Level 2 (or equivalent) module, for EV and non-EV | In force |
| 30 April 2022 | 7.1.3.2.1 | No SHA-1 for timestamp tokens | In force |
| 1 June 2023 | 6.2.7.4.1, 6.2.7.4.2 | Subscriber keys generated, stored and used in certified hardware, verified by an approved method | In force |
| 15 April 2024 | 4.9.1 | Stricter revocation for key compromise and suspect code | In force |
| 1 August 2024 | Various (CSC-25, CSC-26) | EV Guidelines imported into the CSBR; timestamping private key protection | In force |
| 15 April 2025 | 6.2.7.2, 6.3.2 | Timestamp Authority root and issuing keys held offline in hardware; removal of long-lived timestamp keys from HSMs within 18 months | In force |
| 1 March 2026 | 6.3.2 | Code signing certificates issued on or after this date limited to 460 days | In force |
| 15 September 2026 | 7.1.6.4 (CSC-32) | Each subscriber certificate must contain exactly one reserved CA/Browser Forum policy OID | In force |
For context, the reserved policy OIDs are 2.23.140.1.4.1 for non-EV code signing, 2.23.140.1.3 for EV code signing and 2.23.140.1.4.2 for timestamp certificates. Timestamp certificates themselves may be valid for up to 135 months, but the CA or Timestamp Authority must stop using the associated key 15 months after the certificate's notBefore date.
Who and what is affected
Anyone who signs software with a publicly trusted certificate is affected: Windows Authenticode (executables, drivers submitted through partner programmes, MSI and MSIX packages, PowerShell scripts, Office macros), Java JAR signing, and other ecosystems that chain to public code signing roots. Internal certificates issued from a private CA, such as AD CS templates used for internal scripts, are not bound by the CSBR, though many organisations choose to follow it. Apple Developer ID and mobile app store signing use their own vendor programmes and are out of scope here.
| Set-up | What breaks or changes | Typical fix |
|---|---|---|
| Multi-year certificate bought before March 2026 | Nothing yet; the next renewal is capped at 460 days | Record the expiry date now and plan the first short-lived renewal |
| PFX file on a build server or laptop (pre-2023 certificate) | Cannot be renewed in that form; new keys must be in certified hardware | Move to a network HSM, cloud HSM or signing service |
| USB token plugged into a build agent | Yearly token reissue and re-attestation; physical handling slows releases | Consider a cloud HSM or signing service for automated pipelines |
| Signing without timestamps | Every release goes unsigned in the eyes of Windows when the certificate expires, now within about 15 months | Add RFC 3161 timestamping to every signing call and re-sign current releases |
| Certificate pinned by thumbprint in allowlists or update checks | Pins break at each renewal because the certificate, and often the key, change | Pin publisher name and issuing CA or use signer rules that survive renewal |
| Procurement on a three-year budget cycle | One purchase no longer covers three years of signing | Move to multi-year subscriptions that include reissue, or budget annually |
Finding affected systems and identities
Most organisations do not know how many code signing certificates they hold, because teams buy them separately and store them where the build happens. Build the inventory from four directions, and record each key as a non-human identity with an accountable human owner, as described in the Machine Identity, PKI and Certificate Lifecycle Guide.
- Start from what you shipped. Extract signer details from released binaries, installers and packages: subject, issuer, serial number, validity dates, and whether a timestamp countersignature is present. Group by certificate to see which identities are actually in use.
- Ask the CAs. Pull order histories from every public CA account the organisation holds, including accounts opened by individual teams on corporate cards. Finance records for certificate purchases often reveal forgotten accounts.
- Search where keys hide. Scan build agents, CI secret stores, artefact repositories and shared drives for .pfx, .p12 and .jks files and for pipeline variables that hold certificate passwords. Any software key found is a finding in its own right; the Certificate and Key File Formats guide helps identify what each file contains.
- Map who can request a signature. For HSMs, cloud key services and signing services, list every principal (service account, workload identity, pipeline role, human user) allowed to use each signing key. These are the identities an attacker would target, as the CI/CD Pipeline Identity Security Guide explains.
For each certificate record: owner, products signed, issuing CA, EV or non-EV, key location and attestation method, expiry date, timestamp authority used, and every system that pins or trusts it. Add the expiry to the same alerting that covers TLS certificates, with warnings at 90, 60 and 30 days.
Migration options
The CSBR allows three ways to hold a subscriber key from 1 June 2023 (section 6.2.7.4.1, options 7 to 9). Choose based on release frequency, the number of teams that sign, and how much hardware you want to run.
| Option | How the CA verifies it | Fits best | Watch for |
|---|---|---|---|
| Hardware crypto module you operate (USB token, smart card or network HSM) | CA-shipped token with pre-generated key, key attestation from the module manufacturer, a CA-prescribed library, or an IT audit | Low release volume, or organisations that already run HSMs | Token loss, manual steps in pipelines, yearly re-attestation |
| Cloud-based key generation and protection | A report from the cloud subscription showing the key sits in a conforming HSM, or an approved auditor witnessing key creation | Automated pipelines on one cloud platform | The CSBR requires logging of all access, operations and configuration changes on the resources protecting the key |
| Signing service meeting section 6.2.7.3 | An agreement that the subscriber uses a compliant signing service | Many teams, many products, frequent releases | Service authentication becomes the key; since mid-2024 signing services need a conformity assessment audit |
Decision guidance: a small publisher signing a few releases a year can live with a CA-issued token and a documented manual ceremony. A team with daily builds should not have a person plugging in tokens; a cloud HSM or signing service with workload identity authentication removes stored secrets from the pipeline. Large organisations with several product lines usually centralise on one signing service so that approval rules, logging and renewal happen once. The Code Signing Buyer's Guide covers evaluation criteria, and the HSM Deployment and Operations Guide covers running your own modules.
Building a renewal process that survives 460 days
- Decide key rotation policy. The CSBR caps certificate validity, not key age, but a CA may require a new key or new attestation at renewal. Generating a fresh key in the HSM at each renewal is the cleaner default and limits the impact of an undetected compromise.
- Start renewal at least 60 days before expiry. Organisation validation, and especially EV validation, can stall on paperwork. Short validity means there is less slack if it does.
- Make the certificate a configuration value. Pipelines should look up the current signing key by alias or key ID, not by thumbprint baked into scripts, so a renewal is a configuration change rather than a code change.
- Overlap old and new. Issue the new certificate before the old one expires and switch signing on a planned date, keeping the old key available only until the switch is confirmed.
- Timestamp every signature. Use an RFC 3161 timestamp with a SHA-256 digest on every signing call, from a timestamp authority your verifiers trust, and fail the build if the timestamp step fails.
- Update downstream trust. Tell customers and internal teams who allowlist your software about the new certificate ahead of the switch, and change any internal application control rules that reference the old one.
Testing and rollback
- Test in a staging pipeline first: sign a test build with the new certificate and verify the signature, chain and timestamp on clean machines for each supported operating system version.
- Check application control: run signed test builds against App Control for Business or other allowlisting policies in audit mode and confirm no new blocks before enforcing. See the Application Allowlisting Guide.
- Check reputation effects: a new certificate can start with less download reputation in browser and operating system protection features. Release first to a small ring and watch support tickets for unsigned or unknown publisher warnings.
- Prove timestamps work after expiry: on a test machine with the clock moved past the certificate expiry, confirm that timestamped files still verify. Never do this on production systems.
- Rollback: until the old certificate expires, rollback means switching the signing alias back to the old key. After expiry there is no rollback, so finish testing well before the old certificate's end date. If the new key is suspected compromised, follow the Compromised Code Signing Certificate Playbook rather than reverting.
Risks of doing nothing
- Release outage: the certificate expires on a date nobody tracked and the next release cannot be signed, or customers see unsigned warnings on new downloads.
- Silent breakage of old releases: signatures made without timestamps become invalid at expiry, which now arrives within 460 days of issue.
- Revocation exposure: under CSBR section 4.9.1.1 the CA must revoke within 24 hours when it has evidence of key compromise or reasonable assurance the certificate signed suspect code. Untimestamped software or software timestamped after the revocation date then fails verification.
- Stolen keys signing malware: keys left in files or on shared build hosts are a standing target. The NVIDIA code-signing certificates stolen in 2022 were used to sign malware, and the AnyDesk breach in 2024 forced a certificate revocation and replacement across its user base.
- Audit findings: signing keys without an inventory, owner or access log fail common control expectations for key management and software integrity.
Where the change sits in common frameworks
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-12 Cryptographic Key Establishment and Management | Key generation in hardware, rotation and ownership |
| NIST SP 800-53 Rev. 5 | CM-14 Signed Components; SI-7 Software, Firmware, and Information Integrity | Signing and verifying what you ship and install |
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management | Credentials that let pipelines request signatures |
| NIST CSF 2.0 | ID.AM-02; PR.DS-01 | Inventory of signing assets; protection of key material at rest |
| MITRE ATT&CK v20 | T1553.002 Code Signing | Adversary use of stolen or fraudulently obtained signing certificates |
Measuring progress
- Percentage of code signing certificates in the inventory with a named owner and expiry alerting (target 100%).
- Number of signing keys stored outside certified hardware (target zero).
- Percentage of shipped artefacts carrying a valid RFC 3161 timestamp (target 100%).
- Lead time between renewal start and certificate issue, tracked per renewal.
- Number of principals able to request signatures per key, reviewed quarterly.
Practitioner checklist
- Build an inventory of every publicly trusted code signing certificate, its key location, owner and expiry date.
- Flag any certificate whose key is not in a FIPS 140-2 Level 2, Common Criteria EAL 4+ or equivalent module and plan its replacement.
- Choose a target model (own HSM, cloud HSM or signing service) per signing team and record the reason.
- Enforce RFC 3161 timestamping with SHA-256 on every signing call and fail builds when it is missing.
- Replace thumbprint references in pipelines and allowlists with key aliases or publisher rules that survive renewal.
- Set renewal reminders at 90, 60 and 30 days and start validation at least 60 days before expiry.
- Enable and review access logs on every key, as the CSBR requires for cloud key protection.
- Rehearse revocation and re-signing using the compromise playbook at least once a year.
Standards and references
- CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates
- CA/Browser Forum: Code Signing Baseline Requirements source (GitHub)
- Microsoft Learn: Time Stamping Authenticode Signatures
- IETF: RFC 3161 Time-Stamp Protocol (TSP)
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Code Signing
Related NHI Mgmt Group resources: Code Signing Security Guide · Code Signing Policy Template · HSM Deployment and Operations Guide · Machine Identity, PKI and Certificate Lifecycle Guide