How the CA/B Forum Keeps Code Signing Secure?

The CA/Browser Forum (CA/B Forum) is a voluntary group of certificate authorities and browser and OS vendors that sets the Baseline Requirements governing how code signing certificates are issued and managed. Its rules, including mandatory hardware key storage, are what keep code signing trustworthy across the software industry.

The CA/Browser Forum keeps code signing secure by publishing and enforcing the Code Signing Baseline Requirements, the industry rules that certificate authorities must follow. These rules mandate strong identity verification, secure hardware storage of private keys, and fast revocation of compromised certificates. Since June 1, 2023, they require all code signing private keys to be generated and stored in certified hardware, which is the single most important safeguard.

Key Takeaways

• The CA/Browser Forum (CA/B Forum) is a voluntary body of certificate authorities, browser vendors, and OS vendors that sets standards for digital certificates, including code signing.
• Its Code Signing Baseline Requirements (CSBR) define how CAs must issue and manage code signing certificates, creating a consistent global standard.
• Since June 1, 2023, private keys for both EV and non-EV code signing certificates must be generated and stored in a hardware crypto module (FIPS 140-2 Level 2 or Common Criteria EAL 4+), and must be non-exportable.
• CAs must verify the identity of certificate applicants, revoke compromised certificates within 24 hours, and undergo annual independent audits (WebTrust or ETSI).
• The requirements continue to evolve, and code signing is beginning to move toward post-quantum algorithms such as ML-DSA and the hash-based LMS and XMSS.

What Is the CA/B Forum?

The CA/Browser Forum (CA/B Forum) is a voluntary consortium of the organizations that make digital trust work: certificate authorities such as DigiCert, Sectigo, GlobalSign, and Entrust; browser vendors such as Google and Mozilla; and operating system vendors such as Microsoft and Apple. Founded in 2005, it originally focused on Extended Validation (EV) certificates for websites, then expanded to cover the full range of digital certificate management, including code signing. Together these organizations define the standards and best practices that govern how certificates are issued and managed, so that users can trust the software and websites they interact with.

Membership is voluntary and carries no legal force on its own, but the Forum’s rules have enormous practical weight: browsers and operating systems require the certificate authorities in their trust stores to comply, so in effect the Forum’s requirements become the price of being trusted.

The Baseline Requirements: How the Forum Sets the Rules

The Forum’s core output is its Baseline Requirements (BRs), the detailed rules certificate authorities must follow. For code signing specifically, these are the Code Signing Baseline Requirements (CSBR). They set out how certificates are issued, how identities are verified, how private keys must be protected, and how compromised certificates must be revoked. Because the major browsers and operating systems require compliance, the CSBR effectively function as a single global standard, and they are referenced by other frameworks such as NIST guidance, ETSI EN 319 411, WebTrust audits, and ISO 21188.

How the CSBR Has Evolved

The Forum continuously revises the Code Signing Baseline Requirements to counter emerging threats. The major milestones:

When	Change
August 2019 (v1.2)	Initial adoption of the Code Signing Baseline Requirements.
2020 (v2.x)	Move to RSA-3072 and SHA-2 timestamp tokens for stronger cryptographic security, as RSA-2048 aged.
June 2022 (v3.0)	Adoption of the RFC 3647 framework, standardizing certificate policy structure and clarifying compliance.
June 1, 2023	The pivotal change: private keys for both EV and non-EV certificates must be generated and stored in certified hardware (ballots CSC-13 and CSC-17).
2023 to 2024	Further enhancements to private key protection and signing-service requirements.

The June 1, 2023 Hardware Key-Storage Mandate
This is the most consequential code signing rule the Forum has made. Before it, non-EV (OV) code signing keys could be generated in software, which made them easy to copy, leak, or steal, and stolen keys were behind major malware incidents such as the ASUS Live Update attack. Since June 1, 2023, the key pair for both EV and non-EV code signing certificates must be generated and stored in a hardware crypto module that meets or exceeds FIPS 140-2 Level 2 or Common Criteria EAL 4+, and the private key must be non-exportable. In practice this means an HSM or a certified hardware token, and CAs must verify this before issuing. Organizations that bought multi-year certificates before that date must comply on their next renewal or reissue.

The Three Pillars of CA/B Forum Code Signing Security

1. Protecting private keys

The signing key is the crown jewel: anyone who holds it can sign software that the world will trust. The Forum therefore mandates that private keys live in hardware (an HSM or certified token), non-exportable, so a compromised computer cannot leak the key. This single requirement removes the most common cause of code signing compromise.

2. Verifying identity before issuance

Before issuing a code signing certificate, a CA must verify the applicant. For Organization Validation (OV), that means confirming the organization’s legal existence, physical address, and phone number, and that the applicant is authorized. Extended Validation (EV) adds stricter checks, including operational history and a face-to-face or equivalent identity verification. This ensures a signature traces back to a real, vetted organization.

3. Fast revocation of compromised certificates

If a key is compromised or a certificate mis-issued, it must be revoked quickly. The CSBR require CAs to revoke a code signing certificate within 24 hours of confirming unauthorized use or key compromise. CAs publish revocation status through Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), so that operating systems can refuse software signed with a revoked certificate.

How the Forum Enforces Compliance

Rules only matter if they are enforced, and the Forum relies on independent auditing. Certificate authorities must undergo annual audits under frameworks such as WebTrust for CAs (common in North America) or ETSI EN 319 411 (in Europe), conducted by independent third parties. These audits check that a CA issues certificates correctly, protects keys, and handles revocation properly. A CA that fails to comply risks the ultimate penalty: removal from the trust stores of Microsoft, Apple, Mozilla, and others, which renders all its certificates untrusted. That threat is what gives the Forum’s voluntary standards real force.

Why This Matters to You

Every time you install software without a security warning, the CA/B Forum’s rules are working in the background. The chain of trust runs from a root CA (trusted by your operating system and browser) through intermediate CAs to the certificate that signed the software. Because each link is bound by the Forum’s requirements, verified and hardware-protected, you can trust that software signed with a valid certificate genuinely comes from the publisher it claims, and has not been tampered with. When software is unsigned or its certificate is revoked, Windows SmartScreen or macOS Gatekeeper warns you or blocks it outright.

Code Signing and the Post-Quantum Transition
The CA/B Forum requirements focus today on RSA and ECDSA signing, but code signing is beginning to move toward post-quantum algorithms. The signatures that protect software could eventually be forged by a quantum computer, so the industry is preparing to adopt the NIST post-quantum signature standards, principally ML-DSA (FIPS 204), along with the stateful hash-based schemes LMS and XMSS (NIST SP 800-208) that NSA CNSA 2.0 recommends for software and firmware signing today. HSM and tooling support for these algorithms is maturing, and the same hardware-key-protection principle the Forum already mandates will carry directly into post-quantum code signing. Organizations that follow the current rules, keeping keys in an HSM with strong governance, are already well positioned for the transition.

A Note on FIPS 140-3

The CSBR text specifies hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+. Note that FIPS 140-3 has since replaced FIPS 140-2 as the current validation standard: the CMVP stopped accepting new FIPS 140-2 submissions in 2022, and all FIPS 140-2 certificates move to Historical status on September 21, 2026. When choosing an HSM or token to meet the CA/B Forum requirement, look for FIPS 140-3 validation for new deployments, which satisfies and exceeds the letter of the requirement.

How Encryption Consulting Helps

Meeting the CA/B Forum requirements, above all the hardware key-storage mandate, is exactly what CodeSign Secure is built for. It keeps code signing private keys in a FIPS-validated HSM so they are non-exportable and compliant by design, signs against those hardware-held keys, adds compliant timestamping for long-term validity, and automates certificate lifecycle and revocation handling so you stay aligned as the requirements evolve. Because it centralizes signing across artifact types, the same governed process covers your application, container, and firmware signing, and it is ready to adopt post-quantum algorithms as support matures. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is the CA/B Forum?

The CA/Browser Forum (CA/B Forum) is a voluntary group of certificate authorities, web browser vendors, and operating system vendors that sets standards for how digital certificates are issued and managed. Founded in 2005, it publishes the Baseline Requirements that certificate authorities must follow. For code signing, it maintains the Code Signing Baseline Requirements. Although membership is voluntary, browsers and operating systems require CAs in their trust stores to comply, giving the standards real force.

How does the CA/B Forum keep code signing secure?

The CA/B Forum publishes the Code Signing Baseline Requirements, which mandate three main safeguards: private keys must be generated and stored in certified hardware so they cannot be stolen; certificate authorities must verify the identity of applicants before issuing certificates; and compromised certificates must be revoked within 24 hours. Independent annual audits enforce compliance, and non-compliant CAs can be removed from browser and OS trust stores, which makes their certificates untrusted.

What changed for code signing on June 1, 2023?

On June 1, 2023, the CA/B Forum’s updated Code Signing Baseline Requirements took effect, requiring that private keys for both EV and non-EV (OV) code signing certificates be generated and stored in a hardware crypto module meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, with the key non-exportable. Previously, non-EV keys could be generated in software, making them easy to steal. Now an HSM or certified hardware token is mandatory, and CAs must verify it before issuing.

What are the CA/B Forum Code Signing Baseline Requirements?

The Code Signing Baseline Requirements (CSBR) are the CA/B Forum’s detailed rules for how certificate authorities issue and manage code signing certificates. They cover identity verification of applicants, mandatory hardware protection of private keys, certificate revocation timelines, and audit obligations. First adopted in 2019 and revised repeatedly since, they create a consistent global standard and are referenced by NIST, ETSI, WebTrust, and ISO frameworks.

How quickly must a compromised code signing certificate be revoked?

Under the CA/B Forum’s Code Signing Baseline Requirements, a certificate authority must revoke a code signing certificate within 24 hours of confirming that the private key has been compromised or the certificate is being used for unauthorized purposes. Revocation status is published through Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), so operating systems and security tools can block software signed with a revoked certificate.

Is code signing moving to post-quantum algorithms?

It is beginning to. Code signing today relies mostly on RSA and ECDSA, which a future quantum computer could break, so the industry is preparing to adopt NIST’s post-quantum signature standards, principally ML-DSA (FIPS 204), along with the hash-based LMS and XMSS schemes that NSA CNSA 2.0 recommends for software and firmware signing. HSM and tooling support is maturing. Organizations already keeping signing keys in an HSM, as the CA/B Forum requires, are well positioned for the transition.

Stay Compliant with CA/B Forum Code Signing Rules

The hardware key-storage mandate is not optional, and the requirements keep evolving. Explore Encryption Consulting’s CodeSign Secure to sign against HSM-protected, non-exportable keys that meet the CA/B Forum Baseline Requirements by design, with automated lifecycle and post-quantum readiness.