Code signing is the foundational trust mechanism enterprises rely on to verify that software is legitimate and has not been tampered with. However, that trust is only as strong as the governance behind it. Attackers in high-profile incidents such as SolarWinds and 3CX did not break the signing mechanism, they targeted the private key infrastructure behind it. Though the signature remained valid and the software appeared trusted, the compromise was successful.

This is the core challenge. Code signing does not make software safe by default. It makes software traceable and tamper-evident, but only when the signing keys are properly protected, the issuance process is governed, and the certificate lifecycle is actively managed. When those conditions are not met, a valid signature becomes a liability rather than a control.

The CA/Browser Forum’s Code Signing Certificate Working Group (CSCWG) has responded with successive updates to the Code Signing Baseline Requirements (CSBRs), now at version 3.10. The most recent change reduces the maximum validity period of code signing certificates issued on or after March 1st, 2026 to 460 days. The significant reduction from 39 months or 1185 days means that  manual, ad hoc approaches to code signing that worked in the past are no longer viable at enterprise scale.

This article covers where the Baseline Requirements stand in 2026 and what security architects and CISOs must put in place to build a defensible code signing program.

What Is Code Signing (And Why It Is No Longer Optional)

Code signing is the practice of applying a cryptographic digital signature to software to attest two things: that the software originates from a known, legitimate publisher, and that it has not been modified since it was signed. It operates on the same public key infrastructure principles as TLS certificates, but the use case is software integrity rather than encrypted communication.

The mechanics are straightforward. A Certificate Authority issues a code signing certificate to a verified organization. The software publisher uses the associated private key to sign a cryptographic hash of the software. When a user or system receives that software, it verifies the signature against the publisher’s public key, confirming both identity and integrity.

EV vs. OV Code Signing Certificates

There are two primary certificate types enterprises work with. Extended Validation (EV) certificates require rigorous identity verification of the subscribing organization and have historically demanded hardware-based key storage. Organization Validation (OV) certificates require a lower verification threshold and, until June 2023, permitted software-based key storage.

Public and Private Signing Programs

The Code Signing Baseline Requirements govern publicly trusted certificates issued by commercial Certificate Authorities. Organizations operating private PKI hierarchies for internal software distribution are not directly subject to these requirements. However, the governance principles the CSBRs encode apply with equal force to private signing programs. In practice, internally-operated signing infrastructure tends to be the less mature of the two: private signing keys are more likely to be software-stored, less likely to be inventoried, and rarely included in CLM programs. If your organization runs both public and private signing operations, treat the requirements that follow as the floor for both.

Why It Is No Longer Optional

Operating system vendors have made code signing enforcement progressively stricter. Microsoft’s Windows SmartScreen and Apple’s macOS Gatekeeper will warn users or block execution outright for unsigned or improperly signed software. Major application distribution platforms enforce signing requirements at the point of submission. For enterprise software teams distributing internally or commercially, an unsigned binary is increasingly a non-starter operationally.

The more pressing concern for security architects is what happens when signing is treated as a procedural checkbox rather than a governed security control. A code signing private key that is not hardware-protected and properly access-controlled can be exfiltrated and used to sign malicious code, producing output that every downstream security control treats as legitimate.

CA/B Forum Code Signing Baseline Requirements: Where Things Stand in 2026

It is worth noting that while the CSBRs cite FIPS 140-2 Level 2 as the stated minimum, FIPS 140-3 is the current active standard for new hardware crypto module certifications as NIST stopped accepting new FIPS 140-2 submissions in 2021. Organizations procuring new HSMs or hardware tokens should target FIPS 140-3 validated modules rather than treating 140-2 as the procurement benchmark.

What Has Changed Since 2023

The CSBR updates since the hardware mandate aimed for tighter governance at every layer of the signing chain.

• April 2024 (CSC-22): Revocation requirements were strengthened. CAs must now revoke certificates associated with Suspect Code, malicious or unauthorized signing activity, not only in cases of confirmed key compromise. This closes a gap that previously allowed certificates used in attacks to remain valid.
• June 2024: Signing Services, third parties that manage signing keys on behalf of subscribers, must now undergo formal conformity assessment audits against standards such as WebTrust for CAs and ETSI EN 319 401. Organizations relying on cloud-based signing services should verify their provider’s audit status.
• April 2025: Timestamp Authority private keys must now be protected in offline Hardware Crypto Modules. This tightens the integrity of timestamp tokens, which are used to validate signatures after certificate expiry.

March 1, 2026: The 460-Day Certificate Validity Cap Is Now in Effect

Ballot CSC-31 introduced a maximum validity period of 460 days for all code signing certificates issued on or after March 1, 2026. This is in effect now. Certificates issued before this date may still carry a longer validity period, but anything newly issued is subject to the cap.

The Enterprise Code Signing Challenge: Why HSMs Alone Are Not Enough

Storing private keys in an HSM or hardware token addresses key protection. However, it does not address how signing operations are authorized, who has access, how certificates are tracked, or how signing activity is audited. In most enterprise environments, these questions do not have clear answers.

The operational gaps that persist after hardware compliance:

• Signing key sprawl: Enterprises rarely have a single signing environment. Multiple teams, product lines, and CI/CD pipelines each accumulate their own signing credentials over time, often with no centralized inventory, no ownership documentation, and no consistent access controls.
• Ungoverned key generation: Hardware storage addresses where a private key lives after creation, not how it came into existence — and for organizations where a CA or signing service generates and holds keys on their behalf, that distinction matters: without a formal key ceremony establishing who was present, what roles were segregated, and how the event was recorded, an organization has compliant custody of a key whose provenance cannot be verified. In a forensic or audit context, that gap is difficult to close retroactively.
• Developer workflow friction: Direct HSM access is operationally cumbersome for development teams working at deployment velocity. When the compliant path creates friction, developers find workarounds. The result is shadow signing practices that undermine the controls the hardware mandate was designed to enforce.
• Certificate lifecycle blind spots. Code signing certificates expire, renew, and occasionally need emergency revocation, facing the same lifecycle management challenge that applies to TLS certificates. However, they are routinely excluded from CLM programs, which means renewals are missed, expired certificates cause pipeline failures, and revoked certificates go untracked.
• Least-privilege failures. Signing keys are frequently accessible to entire engineering teams rather than gated behind role-based approval workflows. Broad access increases the blast radius of any insider threat or credential compromise event.

Best Practices for Enterprise Code Signing Governance

The following practices form the operational foundation of a defensible enterprise code signing program. They address both the CSBR compliance requirements and the broader governance gaps.

1. Centralize all signing keys in hardware: Enforce FIPS 140-2 Level 2 or higher for every code signing private key across development, staging, and production environments. Conduct an inventory of existing signing credentials and eliminate any software-stored keys. This is the compliance baseline and the prerequisite for every control that follows.
2. Implement approval workflows for every signing operation: No developer or pipeline should have direct, ungated access to a signing key. Mandate explicit authorization, individual or role-based, before any signing operation executes. This creates accountability and prevents unauthorized or accidental signing events.
3. Include signing certificates in your CLM program: Code signing certificates must be managed with the same rigor as TLS certificates. Enroll them in your certificate lifecycle management platform, automate renewal tracking, and configure revocation monitoring. The 460-day validity cap makes this non-negotiable for newly issued certificates.
4. Build a complete signing audit trail: Every signing event should generate a log entry capturing the requestor, approver, artifact signed, certificate used, and timestamp. This record is essential for incident response, compliance attestation, and forensic investigation. If a signing certificate is ever implicated in a security event, this trail is what enables rapid scoping and remediation.
5. Integrate signing securely into CI/CD pipelines: Pipelines should invoke signing through service APIs that interface with HSM-backed infrastructure, without exposing private keys to the pipeline environment. Eliminate any manual signing steps in automated workflows.
6. Monitor for anomalous signing activity: Establish baselines for normal signing volume, timing, and pipeline origin. Alert on deviations such as unusual signing volumes, off-hours activity, signing requests from unexpected pipeline stages, or repeated failures indicating credential probing.
7. Assign ownership of CSBR compliance monitoring: Assign explicit ownership of tracking CSBR revisions, mapping changes to internal compliance requirements, and maintaining a calendar of upcoming effective dates. Compliance with a living standard requires a process, not a one-time review.

How Accutive Security Helps

Building a defensible code signing program requires more than selecting the right tools. Building a robust code signing program begins with a clear assessment of the current environment, a vendor selection process grounded in technical fit, and leveraging implementation expertise to make the chosen platform operational in complex enterprise architectures.

Accutive Security’s Center of Excellence in Cryptography, Identity Security, and Data Protection covers the full lifecycle of a code signing governance program, from initial assessment and solution selection through implementation, integration, and ongoing managed services. The Center of Excellence enables organizations at all levels of maturity from starting from scratch to hardening an existing mature program against current CSBR requirements.

Accutive Security holds certified service delivery status across platforms most relevant to enterprise code signing governance including Keyfactor, CyberArk and Venafi, DigiCert, and Thales. That breadth is intentional. No single platform is the right answer for every environment, and vendor-agnostic guidance is only credible when it is backed by certified implementation experience across the field.

If your organization is working to align with the current CA/Browser Forum Baseline Requirements or build a more mature signing governance program, Accutive Security can help.