Code Signing Certificates: How They Work and Why They Matter

Code signing certificates are cryptographic credentials issued by trusted Certificate Authorities (CAs) that bind a software publisher's verified identity to an executable, script, or software package. This page covers the mechanics of how code signing works, the certificate types available, the regulatory and trust frameworks that govern their issuance, and the decision criteria practitioners and procurement officers use to select appropriate certificate classes. The scope spans desktop applications, drivers, firmware, mobile code, and enterprise software distribution pipelines.

Definition and scope

Code signing is a form of applied public-key cryptography in which a software publisher uses a private key to generate a digital signature over a hash of a software artifact. The corresponding public key — embedded in a certificate issued by a trusted CA — allows any relying party to verify that the software originated from the claimed publisher and has not been altered since it was signed. The Encryption Authority providers index the broader service landscape for cryptographic credential providers, including those offering code signing certificate services.

The trust model depends entirely on the CA hierarchy. Code signing certificates are issued under the CA/Browser Forum's baseline requirements, which as of CA/Browser Forum Baseline Requirements for Code Signing Certificates v3.3 establish minimum vetting, key protection, and lifecycle standards that all publicly trusted CAs must follow. The CA/Browser Forum is the primary standards body governing publicly trusted certificate issuance globally.

Certificate scope covers four principal software artifact categories:

1. Executable files — .exe, .msi, .dll, and similar compiled binaries for Windows, macOS, and Linux environments
2. Scripts and interpreted code — PowerShell scripts, macros, and JavaScript packages distributed via registries such as npm
3. Kernel-mode drivers — Windows kernel drivers require Extended Validation (EV) certificates and Microsoft's Hardware Dev Center attestation, per Microsoft's Kernel-Mode Code Signing Requirements
4. Firmware and embedded code — device firmware images signed to support secure boot and supply chain integrity verification

How it works

The code signing process follows a discrete cryptographic workflow:

1. Key generation — The publisher generates an asymmetric key pair, typically RSA 3072-bit or ECDSA P-256, both of which are approved under NIST SP 800-57 Part 1 Rev 5 for code signing applications.
2. Certificate request — A Certificate Signing Request (CSR) is submitted to the CA along with identity documentation required by the applicable validation tier.
3. CA vetting — The CA performs identity verification commensurate with the certificate class (Organization Validation or Extended Validation), then issues a signed certificate binding the public key to the verified publisher name.
4. Signing operation — A signing tool (e.g., Microsoft's signtool.exe, Apple's codesign, or jarsigner for Java) hashes the artifact using SHA-256 or SHA-384, then signs the hash with the publisher's private key. The certificate and signature are embedded in or appended to the artifact.
5. Timestamping — A Time Stamp Authority (TSA) countersigns the signature with an authenticated timestamp. Timestamping is operationally critical: it preserves signature validity after the signing certificate expires, a requirement recognized in the CA/Browser Forum baseline requirements.
6. Verification by relying party — The operating system or browser retrieves the embedded certificate chain, validates it against the trusted root store (e.g., Microsoft Root Program, Apple Root Program, or Mozilla Root Store), confirms the hash matches the artifact, and checks revocation status via OCSP or CRL.

The private key must be protected at a hardware security level for EV certificates. The CA/Browser Forum requires that EV code signing private keys be stored on a hardware cryptographic module meeting FIPS 140-2 Level 2 or equivalent, such as a hardware security module (HSM) or a qualified USB token.

Common scenarios

Windows SmartScreen reputation building — Microsoft's SmartScreen filter assigns reputation scores to signed binaries based on the publisher's certificate and download volume. Software signed with an OV (Organization Validation) certificate starts with no established reputation and may trigger warnings until sufficient download volume accumulates. Software signed with an EV certificate receives immediate reputation, which is the primary operational reason independent software vendors choose EV over OV for new releases. The distinction is not theoretical: unsigned executables on Windows 10 and 11 trigger a full block warning by default under SmartScreen.

Kernel driver signing (Windows) — Since Windows 10 version 1607, Microsoft requires all kernel-mode drivers loaded on 64-bit Windows systems to carry a valid EV code signing certificate and pass Microsoft's Hardware Dev Center (WHCP) attestation. Drivers failing this requirement cannot load under Secure Boot with default policy, even if otherwise signed. This requirement is enforced at the OS level, not by the CA ecosystem alone.

macOS notarization — Apple requires all software distributed outside the Mac App Store to be both developer-signed with an Apple-issued Developer ID certificate and submitted for automated notarization through Apple's notary service. Notarization is distinct from code signing: it involves Apple scanning the artifact for malware and returning a notarization ticket that must be stapled to the bundle. Software lacking notarization will be blocked by macOS Gatekeeper.

Enterprise internal code signing — Organizations distributing internally developed software through enterprise deployment tools (SCCM, Intune, Jamf) may use a private CA rooted in Microsoft Active Provider Network Certificate Services or a comparable internal PKI. These certificates are trusted only within the enterprise trust store and carry no public CA/Browser Forum obligations. The page situates this practice within the broader PKI services landscape.

Decision boundaries

Selecting the appropriate code signing certificate class requires mapping the distribution channel, platform requirements, and risk tolerance against the validation and storage requirements of each tier.

OV (Organization Validation) vs. EV (Extended Validation)

The CA/Browser Forum updated its baseline requirements effective June 1, 2023, to mandate that all new OV code signing private keys also be generated and stored in hardware, eliminating the prior distinction in key storage practices between OV and EV (CA/Browser Forum Baseline Requirements for Code Signing v3.1 change log).

Timestamp authority selection — The TSA must itself be operated by a publicly trusted provider. IETF RFC 3161 defines the Time-Stamp Protocol (TSP) that governs TSA operation. Signatures lacking a valid RFC 3161 timestamp become unverifiable once the signing certificate expires, creating silent trust failures in long-lived software distributions.

Certificate validity periods — The CA/Browser Forum caps code signing certificate validity at 39 months as of its current baseline requirements. Shorter validity periods reduce the exposure window if a private key is compromised, but increase the operational burden of certificate renewal and re-signing workflows for software vendors managing large artifact catalogs. The how to use this encryption resource page describes how related PKI topics are organized across this reference network.

Revocation response — When a private key is compromised, the CA revokes the certificate and publishes the revocation through CRL and OCSP. Relying parties that do not enforce real-time revocation checking — a common configuration in offline or airgapped environments — will continue to trust signatures made under a revoked certificate unless the software distribution system enforces its own revocation check. This is a known structural gap in the code signing trust model and is addressed in part by Microsoft's Disallowed Certificate Trust List (CTL), which distributes revocation information via Windows Update.