Understanding the New Code-Signing Certificate Validity Change

Code signing is the trust mechanism that lets an operating system confirm who published a piece of software and whether it has been altered since signing. In public-key cryptography, a certificate contains the public key, while the publisher keeps the corresponding private key secret. A code-signing certificate binds a publisher’s identity to a public key, and the matching private key produces the signature that Windows SmartScreen, OS loaders, and installers check before they trust an executable, driver, or installer.

The validity change, introduced by CA/Browser Forum, Ballot CSC-31: Maximum Validity Reduction, took effect on March 1, 2026. This article focuses on that validity change: what the new limit is, the cryptographic reasoning behind it, how it interacts with timestamping and revocation, who it affects, and the concrete steps required to adapt.

What the New Validity Change Says

The CA/Browser Forum (CA/B Forum) is the body of certificate authorities and certificate consumers, such as browser and operating-system vendors, that define the baseline requirements for publicly trusted certificates. On October 13, 2025, voting concluded on Ballot CSC-31, which amends the Code Signing Baseline Requirements to set the maximum validity of a code-signing certificate at 460 days, down from the previous ceiling of 39 months. The change was proposed by Microsoft and endorsed by Sectigo and eMudhra, and it was adopted on November 17, 2025, as Code Signing Baseline Requirements version 3.10.0.

The limit applies to both Organization Validation (OV) and Extended Validation (EV) code-signing certificates. It governs the validity field set at issuance, so it applies to any certificate issued or renewed on or after March 1, 2026. Certificates issued before that date with a longer validity remain trusted until their stated expiry.

The numbers

Attribute	Previous requirement	Under CSC-31
Maximum validity	39 months	460 days
Effective date	Not applicable	March 1, 2026
Baseline Requirements version	v3.9	v3.10.0
Certificate types affected	OV and EV	OV and EV

Although the ballot fixes the ceiling at 460 days, in practice some CAs issue at 459 days to leave headroom for clock skew and issuance latency. DigiCert, for instance, describes its rollout as a 459-day validity, and SSL.com issues at 458 days for the same headroom reason. Several CAs stopped selling two-year and three-year certificates in late 2025 ahead of the change, and one-year (366-day) products are now the default offering.

The Reasoning Behind a Shorter Validity Period

The validity reduction is an application of a well-established key management principle rather than a reaction to any single incident. A code-signing certificate binds a long-lived private signing key to an identity. The longer that binding is valid, the longer a stolen or misused key keeps producing trusted signatures, and the larger the volume of signed artifacts an attacker can mint before anyone intervenes.

Cryptoperiods in NIST key management guidance

This maps directly to the concept of a cryptoperiod defined in NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management. A cryptoperiod is the time span during which a key is authorized for use. NIST recommends bounding it so that risk does not accumulate indefinitely, and the publication models each key as moving through pre-activation, active, deactivated, compromised, and destroyed states. Capping certificate validity at 460 days enforces a ceiling on the active period of the associated signing key, which guarantees that identity bindings are revalidated at least every fifteen months; rotating the signing key itself requires generating a new key pair at renewal, which is the recommended practice.

Code-signing-specific recommendations

NIST also published guidance dedicated to this use case. The NIST Cybersecurity White Paper, Security Considerations for Code Signing, explains how code signing delivers integrity and source authentication, and it recommends isolating signing keys, storing them in a hardware security module restricted to signing functions, separating development and production signing systems, and requiring multiple approvers before a signing operation. A shorter mandatory validity period reinforces these controls by forcing periodic re-issuance, which revalidates the publisher’s identity and rotates the key binding on a fixed schedule.

How Validity Interacts With Signing, Timestamping, and Revocation

To evaluate the operational impact of a shorter validity period, the relationship between the certificate, the timestamp, and revocation has to be precise. The certificate defines the window during which a signing key is trusted, the timestamp records when a signature was produced, and revocation withdraws trust before a certificate would otherwise expire.

The signing operation

1. The publisher computes a cryptographic digest of the artifact using an approved hash function such as SHA-256.
2. The digest is signed with the private key, producing the signature, which is embedded with the artifact together with the publisher’s certificate and its chain to a trusted root.
3. At verification time, the loader recomputes the digest, verifies the signature against the public key in the certificate, and validates the chain and the certificate’s validity status.

Why a shorter validity period does not break already-signed software

A frequent concern is that shorter-lived certificates will cause previously released software to stop validating. They will not, as long as the signature is timestamped. A timestamp from a trusted Timestamp Authority records the instant of signing. Provided the certificate was valid at that instant, the signature stays valid for the life of the timestamp, which is typically much longer than the certificate. This is why a driver signed years ago still installs even though its signing certificate expired long before.

That same property is the core of the security problem that the validity change addresses. Because a timestamped signature outlives the certificate, a compromised certificate keeps generating trusted signatures well past the moment of compromise. Shortening validity narrows that exposure window, and revocation closes it. Revocation status is published through Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), and a CA can revoke a compromised certificate so that verifiers reject signatures that rely on it. Because a timestamped signature made before the revocation date generally remains valid, the CA must set the revocation date back to the suspected time of compromise to invalidate signatures produced earlier.

Recent Incidents That Illustrate the Risk

The exposure created by long-lived, poorly governed signing credentials is not hypothetical. Several recent campaigns show why the ecosystem is contracting certificate lifetimes and tightening surrounding controls.

AnyDesk production breach (2024)

In early 2024, remote-access vendor AnyDesk confirmed that attackers reached its production systems and that source code and private code-signing keys were stolen, according to reporting from BleepingComputer. The company responded by revoking the affected certificates and rotating its signing material. Incidents like this demonstrate why limited certificate lifetimes are important, as they reduce the period during which a stolen certificate can be exploited.

Hijack Loader and GHOSTPULSE signed campaigns (late 2024)

In October 2024, researchers documented Hijack Loader (also tracked as GHOSTPULSE and IDAT Loader) samples signed with legitimate code-signing certificates, delivered through the ClickFix social-engineering technique that tricks users into running PowerShell. Investigators found multiple abused certificates tied to the same command-and-control infrastructure, and the issuing authorities cancelled them within hours to a day once notified. The episode shows both the value attackers place on valid signatures and the role fast revocation plays in containing abuse.

Abuse of Microsoft Trusted Signing short-lived certificates (2025)

In March 2025, attackers were observed signing malware through Microsoft’s Trusted Signing service using three-day certificates. This case illustrates two distinct dynamics. It shows determined actors will still seek valid signatures, but it also demonstrates the defensive value of short-lived, centrally issued certificates: the credentials are never handed to the developer, so they cannot be stolen from an endpoint, and they expire and can be revoked almost immediately. That model is precisely the direction the validity reduction encourages.

Industrial-scale signed driver abuse (2020 to 2025)

A 2025 investigation by Group-IB tracked a long-running operation that amassed more than 80 certificates and over 60 Windows Hardware Compatibility Program accounts and signed more than 620 malicious Windows kernel drivers between 2020 and the first quarter of 2025, often using stolen certificates or certificates obtained through newly created shell companies. Kernel drivers run at the most privileged level of the operating system, so a valid signature on a malicious driver is extremely powerful. Shorter validity does not stop fraudulent issuance on its own, but combined with hardware key storage and rapid revocation it reduces the useful lifespan of each abused credential.

Who Is Affected and to What Degree

Any organization that signs software with a publicly trusted certificate is subject to the 460-day limit. The amount of operational change depends mainly on how signing keys are stored and how renewal is handled.

Highest impact: physical hardware token workflows

Since June 1, 2023, the CA/B Forum has required code-signing private keys to be generated and held on hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, typically a USB token or an HSM. Teams that depend on physical USB tokens mailed by the CA feel this change most, because each renewal can involve provisioning and shipping a new token. At a fifteen-month cadence rather than a three-year one, that logistical work occurs far more often.

Lowest impact: cloud and HSM-based signing

Organizations that sign through a cloud signing service or a networked HSM, where keys are provisioned and rotated over an API, absorb the change with little friction. For them a renewal is largely a software event that can be automated end to end. The asymmetry is intentional, since the broader policy direction favors automated, centrally managed signing over manual token handling.

Operational Impact

Renewal frequency

Moving the ceiling from 39 months to 460 days means certificates must be replaced at least every fifteen months. Over a fixed window, that is more than twice as many renewal events. For a publisher running multiple signing certificates across products and build systems, each renewal must be scheduled and executed without stalling release pipelines.

Automation requirement

Manual tracking through spreadsheets and calendar reminders scales poorly as renewals become more frequent. A missed renewal can block a release or ship binaries that trigger SmartScreen warnings. Certificate Lifecycle Management tooling that discovers signing certificates, monitors expiry, and orchestrates renewal through CA APIs is the practical control. This is the same automation pressure driving the parallel reduction of TLS certificate lifetimes toward 47 days by 2029 under CA/Browser Forum Ballot SC-081v3.

Continuity through timestamping

Because timestamped signatures remain valid after the signing certificate expires, every signing operation should include a timestamp from a reliable Timestamp Authority. This separates the longevity of released software from the shorter lifetime of the certificate and prevents the validity change from affecting code already in the field.

Complying Now That the Requirement Is in Effect

With the 460-day limit now in force, every new and renewed certificate must comply. The following steps keep an organization compliant and move it from manual, reactive handling to a controlled lifecycle.

1. Inventory every code-signing certificate across teams, build servers, and products, recording the owner and where each private key is stored.
2. Classify key storage by type, separating physical USB token workflows from cloud or HSM-backed keys, and prioritize the token-based ones for modernization.
3. Adopt Certificate Lifecycle Management automation to monitor expiry, alert owners ahead of deadlines, and renew through CA APIs where supported.
4. Enforce timestamping on every signing operation so released software stays valid after certificate expiry.
5. Harden the signing environment per NIST guidance: HSM-stored keys, separation of development and production signing, multi-party approval, and isolated signing systems.
6. Run a full renewal cycle on the new schedule so that each renewal under the 460-day rule is routine rather than disruptive.
7. Maintain revocation readiness, with a defined process to revoke and re-sign quickly if a key is suspected of compromise, since expiry alone is not sufficient protection.

Meeting the New Requirement With Encryption Consulting’s CodeSign Secure

A shorter validity period turns code signing into a recurring lifecycle problem rather than a once-every-few-years task, which is exactly where a centralized signing platform earns its place. CodeSign Secure is a centralized, secure, and scalable code signing platform built to help organizations sign code confidently without sacrificing security or speed. It is designed for modern DevOps environments, integrating with CI/CD pipelines such as Azure DevOps, Jenkins, and GitLab, while enforcing strict access controls and approval workflows that keep the signing process clean and compliant as renewals become more frequent.

Capabilities aligned to the validity change

Several CodeSign Secure capabilities map directly to the controls that the new 460-day ceiling pushes organizations toward:

• HSM-backed key security. Private keys are stored in FIPS 140-2 Level 3 HSMs, exceeding the CA/Browser Forum hardware storage requirement, with support for Entrust nCipher, Thales Luna, Utimaco, and Securosys across on-premises and cloud HSMs.
• Policy-driven access control. Integration with Active Directory and Keycloak, granular Role-Based Access Control, and multi-step approval workflows enforce separation of duties, so no artifact is signed unless it meets the required certificate type, signing stage, and approvals. This directly implements the multi-party approval and key isolation that NIST recommends for code signing.
• Seamless CI/CD integration. Release security checks and integrity validation prevent unsigned artifacts from reaching production, with centralized tracking and instant alerts on unauthorized signing attempts, keeping high-velocity pipelines compliant through more frequent renewal cycles.
• Broad format and platform support. Signing covers .exe, .dll, .jar, .apk, .dmg, Docker containers, and firmware binaries across Windows, Linux, and macOS, and integrates with a custom PKCS11 wrapper and tools such as Signtool, Jarsigner, and JSign.
• Client-side hashing and secure timestamping. Hashes are generated on the client through a custom Key Storage Provider for Microsoft’s CNG framework, and secure timestamps preserve signature validity after certificate expiry, which is essential under shorter validity periods.
• Comprehensive audit trails. Detailed event logs record every approval, denial, and signing event for compliance and incident investigation, with SIEM integration for Grafana, Loki, and Splunk via OpenTelemetry.
• Flexible deployment models. Organizations can run a fully managed cloud-hosted service with built-in HSM security and full API access or deploy on-premises while managing keys in cloud HSMs, on-prem HSMs, or both.
• Post-Quantum Cryptography support. CodeSign Secure supports the NIST-recognized ML-DSA and LMS quantum-resistant signature schemes directly on the HSM, along with dual signing that pairs a classical RSA or ECDSA signature with a post-quantum signature for a gradual transition.

Whether you manage dozens of signing identities across distributed teams, run high-velocity CI/CD pipelines, or operate under strict compliance mandates in sectors such as automotive, healthcare, or fintech, CodeSign Secure absorbs the added renewal overhead the 460-day limit introduces and turns code signing into a governed, automated lifecycle.

Conclusion

Reducing code-signing certificate validity to 460 days enforces a shorter cryptoperiod for signing keys, narrows the window in which a compromised certificate can be abused, and aligns code signing with the automation-driven model already reshaping TLS. Recent incidents involving AnyDesk, Hijack Loader, Microsoft Trusted Signing, and large-scale signed driver abuse all point to the same conclusion: long-lived, loosely governed signing credentials are a liability, and bounding their lifetime is a sensible mitigation.

For organizations that still track certificates manually and rely on physical tokens, the main consequence is more frequent renewals. For those who treat code signing as an automated lifecycle with discovery, monitoring, timestamping, and hardware-backed keys, the change is a minor adjustment. With the March 1, 2026, effective date now passed, completing that shift is no longer optional but a current operational requirement.