In June 2023, the CA/Browser Forum rolled out a significant update to their code signing requirements, directly impacting developers, DevOps teams, and businesses that rely on publicly trusted Certificate Authorities (CAs) to sign and secure their software. These updates, which came into effect on June 1, 2023, mandate that code signing private keys be securely stored and protected in a certified Hardware Security Module (HSM). This change affects both Extended Validation (EV) and non-EV certificates.
A second binding requirement followed: Ballot SC-081 caps code signing certificate validity at 460 days, effective March 1, 2026, replacing the previous multi-year issuance windows some CAs offered. Together, these two mandates, the HSM requirement and the validity cap, are the current binding CA/B Forum baseline for publicly trusted code signing certificates.
In short: as of June 1, 2023, code signing private keys must be generated and stored in a FIPS 140-2 Level 2 (or Common Criteria EAL 4+) HSM; as of March 1, 2026, certificate validity is capped at 460 days. Both are requirements, not recommendations, and non-compliant issuance requests are rejected by CAs enforcing the baseline.
Key Takeaways
- The HSM mandate (June 1, 2023) and the 460-day validity cap (March 1, 2026) are both hard requirements enforced by CAs at issuance, not internal best-practice guidance an organization can choose to skip.
- The 460-day cap means renewal now happens roughly annually rather than every 1-3 years, which raises the operational stakes of the HSM integration and CI/CD automation challenges covered below, since renewal friction now recurs far more often.
Compliance Audit Checklist
- Confirm the signing key was generated inside, and never exported from, an HSM certified to FIPS 140-2 Level 2 or Common Criteria EAL 4+.
- Confirm certificate validity at issuance or renewal does not exceed 460 days.
- Confirm every signature includes a trusted timestamp, so the signature remains valid after the certificate itself expires.
- Confirm a documented revocation procedure exists and has been tested, not just written down.
- Confirm renewal is tracked against the 460-day window specifically, not against a legacy multi-year assumption left over from before Ballot SC-081.
Why the HSM Requirement?
The new requirements stem from the need for stronger security practices in software development. With cyberattacks becoming increasingly sophisticated, it is crucial to ensure the integrity of software from the moment it is signed. Protecting the code signing private keys in an HSM drastically reduces the risk of key compromise, as HSMs are designed to be tamper-resistant and provide a secure environment for cryptographic operations.
Effective June 1, 2023, all certificate requesters must use an HSM that meets the following standards:
- FIPS 140-2 Level 2
- Common Criteria EAL 4+
These certifications are widely recognized as industry standards for secure cryptographic modules, ensuring that private keys are protected in a hardware environment that cannot be bypassed or tampered with.
Key Challenges Under the New Code Signing Requirements
While the shift to using HSMs for code signing is a positive move for security, it introduces several technical challenges that need to be addressed:
- Proving Compliance with the HSM Requirement
The first hurdle for organizations is proving that their private keys are securely stored within an HSM. This proof is necessary for obtaining code signing certificates from CAs. While many CAs offer USB-based HSMs as a solution, this can be cumbersome for businesses operating in the cloud or with large-scale code signing requirements. USB HSMs are not ideal for teams spread across different regions or those who require rapid, large-scale signing operations.
A more scalable option is to use network-based HSMs, which can either be on-premises or rented from cloud providers. Solutions like AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM, and nShield as a Service are all viable options. However, it’s essential to ensure that the HSM you choose supports the verification methods required by your CA, such as key attestation (i.e., confirming that the private key resides within the HSM).
- Managing Key and Certificate Operations
Once your private keys are secured in an HSM, managing them becomes more complex. HSMs are designed to keep private keys within their secure environment, meaning that you cannot directly export keys for use in software. Instead, you need to interact with the HSM through an intermediary layer, such as:
- Key generation
- Certificate signing request (CSR) creation
- Certificate import/export
These operations require specialized software and cryptographic tools. Additionally, you need to ensure that access permissions for the keys are tightly controlled. Each action performed on the HSM (e.g., key usage, certificate issuance) must be logged and audited to comply with security best practices.
- Integrating Code Signing with HSMs
One of the most technical challenges is integrating HSMs with the various code signing tools used across platforms. Most organizations use third-party tools for code signing, such as:
- signtool (Windows)
- jarsigner (Java)
- Codesign and productsign (macOS)
- rpmsign and debsign (Linux)
- cosign (containers)
When using an HSM, integrating these tools requires the use of platform-specific cryptographic service providers (CSPs). For example:
- Windows: Uses KSP (Key Storage Providers) or CSP (Cryptographic Service Providers).
- Java: Uses JCE (Java Cryptography Extension) providers.
- Linux: Relies on PKCS#11 libraries for hardware-based cryptography.
- macOS: Uses CTK (Cryptographic Toolkit).
These integrations can be tricky, as the signing tools need to be configured to interact with the HSM via the appropriate service provider. This often requires custom configuration and testing to ensure seamless operation.
- Optimizing Performance in CI/CD Pipelines
For modern DevOps environments, speed and efficiency are paramount. Introducing an HSM into your code signing process can slow down the pipeline if not properly configured. A common approach many teams initially adopt is to upload the data to be signed, perform the signing operation, and then download the signed result. However, this method can be inefficient, consuming considerable bandwidth and causing delays.
To optimize this process, many organizations switch to client-side hashing. With client-side hashing, the code is hashed on the client side before being sent to the HSM for signing, reducing the amount of data transferred and speeding up the signing process. However, this method requires that both your cryptographic service provider and signing infrastructure support this feature.
How Encryption Consulting Can Support Your Compliance Journey?
At Encryption Consulting, we specialize in helping organizations meet the CA/Browser Forum code signing requirements. Here’s how we can support you through this transition:
- HSM Integration: Whether you opt for USB-based or network-based HSMs, we can assist in selecting the best solution for your needs and guide you through the integration process.
- Key Management Solutions: We offer expertise in managing your private keys securely within HSMs, ensuring that all key and certificate operations are carried out securely and in compliance with industry standards.
- Code Signing Optimization: Our team can help integrate your code signing process with the necessary cryptographic service providers, ensuring that the process is smooth and secure across all platforms.
- CI/CD Pipeline Optimization: We can assist you in implementing efficient code signing strategies within your CI/CD pipeline to minimize any performance hits.
Introducing CodeSign Secure: The Solution You Need
To make your code signing process even more secure and efficient, we recommend CodeSign Secure. Our solution offers a seamless and automated approach to code signing that fully integrates with HSMs, helping you meet the latest CA/Browser Forum requirements without the complexity. CodeSign Secure simplifies key management, improves compliance, and ensures that your signing operations remain fast and efficient, even in large-scale DevOps environments.
With CodeSign Secure, you get:
- Secure integration with hardware security modules
- Streamlined management of code signing certificates
- Enhanced performance for CI/CD pipelines
- Full compliance with the CA/Browser Forum code signing requirements
Let us help you keep your software secure, compliant, and fast with CodeSign Secure. Reach out to Encryption Consulting today to learn how we can optimize your code signing process.
Renewal, Timestamping, and Revocation Under the New Baseline
The 460-day cap changes the operational rhythm of code signing more than it changes any single technical step. Three implications follow directly from it:
- Renewal: a certificate issued under a legacy multi-year window will still expire on schedule, but any renewal or re-issuance after March 1, 2026 is capped at 460 days regardless of what the CA previously offered. Renewal cadence should be tracked against this cap specifically, not assumed from historical certificate lifespans.
- Timestamping: a trusted timestamp on a signature records that the certificate was valid at the moment of signing. With certificates now expiring roughly annually, timestamping every signature matters more, not less: without it, a signed artifact’s trust becomes tied to the certificate’s now-shorter validity window, and the signature effectively expires with the certificate even if nothing else about it changed.
- Revocation: the HSM requirement limits how a key can be compromised, but it doesn’t eliminate the need for a tested revocation procedure. A documented plan that has never been rehearsed is a gap an audit should catch; more frequent renewal cycles are also more frequent opportunities to verify the revocation process still works end to end.
Frequently Asked Questions
Is the 460-day validity cap a recommendation or a hard requirement?
A hard requirement. Ballot SC-081 makes 460 days the maximum validity period for publicly trusted code signing certificates issued or renewed on or after March 1, 2026. CAs enforcing the CA/B Forum baseline will not issue longer-lived certificates.
Does the HSM requirement apply to internal, non-publicly-trusted certificates too?
The CA/B Forum baseline governs publicly trusted CAs and the certificates they issue. Internally issued certificates aren’t bound by CA/B Forum ballots directly, though many organizations apply the same HSM-backed key protection as an internal policy regardless, since the underlying security rationale doesn’t change based on who issued the certificate.
Conclusion
The updated CA/Browser Forum code signing requirements mark a crucial shift towards stronger security practices within the software development lifecycle. While transitioning to HSM-based code signing comes with technical challenges, the benefits in terms of improved security and integrity are undeniable. By effectively managing HSM integration, optimizing key management workflows, and ensuring streamlined performance in your CI/CD pipeline, you can meet the new standards while maintaining development efficiency.
Encryption Consulting is here to guide you through every step of the process, ensuring your code signing practices are secure and fully compliant with the latest industry standards.
