What is Code Signing? How does Code Signing work?

Code signing is the practice of using a digital signature to prove that a piece of software, firmware, script, or executable came from a specific publisher and has not been altered since it was signed.

Code signing uses a private key and a code-signing certificate to attach a digital signature to software before it is distributed. When a user installs the code, their operating system verifies the signature to confirm the publisher’s identity and that the code has not been tampered with. It is the primary mechanism of trust in modern software distribution. 

Key Takeaways 

• Code signing proves software authorship and integrity using a private key held by the publisher and a code-signing certificate issued by a trusted Certificate Authority. 
• The CA/Browser Forum requires code signing private keys to be stored on hardware meeting FIPS 140-2 Level 2 (or FIPS 140-3 Level 2) or Common Criteria EAL 4+, effective June 1, 2023. 
• Timestamping (RFC 3161) keeps a signature valid after the signing certificate expires, by proving when the code was signed. 
• SHA-256 is the current baseline hash algorithm; SHA-1 is deprecated and rejected by modern platforms. 
• Post-quantum code signing uses ML-DSA (FIPS 204) or SLH-DSA (FIPS 205); CNSA 2.0 targets exclusive quantum-resistant signing for US national security systems from 2027. 

How Code Signing Works 

Code signing follows the same public-key cryptography pattern as any digital signature, applied specifically to software artifacts. 

• Generate a key pair: The publisher generates a public and private key pair, then a Certificate Signing Request (CSR). 
• Obtain a certificate: A trusted Certificate Authority validates the publisher’s identity and issues a code-signing certificate bound to the public key. 
• Hash the code: A cryptographic hash function (typically SHA-256) produces a fixed-length digest of the software artifact. 
• Sign the hash: The publisher’s private key encrypts the hash to produce a digital signature. The private key must be stored in a FIPS 140-2 Level 2 (or FIPS 140-3 Level 2) hardware module, per CA/B Forum rules. 
• Bundle for distribution: The original code, the signature, and the code-signing certificate (containing the public key) are packaged together and distributed. 
• Verify on install: The recipient’s operating system re-hashes the code, decrypts the signature with the public key, and compares the two hashes. A match confirms authenticity and integrity. 

If the code is modified after signing, the recalculated hash will not match, the signature will fail verification, and the operating system will warn the user or block the installation. 

Code Signing Certificates: Publicly Trusted vs Self-Signed 

Code signing certificates fall into two categories with very different trust characteristics. 

Attribute	Self-Signed Certificate	Publicly Trusted Certificate
Issued by	The publisher, internally	A trusted Certificate Authority (DigiCert, Sectigo, GlobalSign, etc.)
Trust in OS/browser	Not trusted by default; triggers security warnings	Trusted by default; no warnings
Cost	Free	Paid; varies by validation level
Validation levels	None	Standard (OV), Organization Validation, Extended Validation (EV)
Best for	Internal testing, development, private distribution	Public software distribution to end users
Private key storage requirement	Recommended on HSM	Required on FIPS 140-2 Level 2+ hardware since June 1, 2023

Extended Validation (EV) certificates carry the strictest identity checks and give signed software an immediate reputation boost with Microsoft SmartScreen and other application reputation systems. 

Why Timestamping Matters 

Timestamping attaches a trusted time record to the signature at the moment of signing, so verification remains valid even after the code-signing certificate expires.

Code-signing certificates typically have validity of one to three years. Without a timestamp, once the certificate expires the signature is treated as invalid and users see security warnings, even though the code was legitimately signed while the certificate was active. A timestamp from a trusted Timestamp Authority (TSA) fixes this by cryptographically proving the signing date. The relevant standard is RFC 3161.

Always timestamp production code signatures. This is a low-cost, high-value operation and is standard practice.

CA/B Forum Baseline Requirements: The Hardware Storage Rule 

Since June 1, 2023, the CA/Browser Forum Code Signing Baseline Requirements have required all code-signing private keys, for both Organization Validation (OV) and Extended Validation (EV) certificates, to be stored on hardware that meets FIPS 140-2 Level 2 (or FIPS 140-3 Level 2) or Common Criteria EAL 4+. Software-only key storage is no longer permitted for publicly trusted code signing.

Acceptable storage options include: 

• Hardware Security Modules (HSMs) 
• Cloud-based HSM services 
• USB-based hardware tokens meeting the required certifications 

This rule directly addressed high-profile supply-chain attacks such as SolarWinds (2020), where compromised signing keys were used to distribute trojanized Orion updates to thousands of organizations. Storing keys in tamper-resistant hardware makes key theft substantially harder. 

Code Signing and Post-Quantum Cryptography 

Signed code often needs to remain verifiable for years or decades, firmware in an industrial device, an operating system release, a signed driver, which makes code signing one of the most urgent post-quantum migration priorities.

RSA and ECDSA signatures, which underpin nearly all code signing today, can be forged by a sufficiently large quantum computer running Shor’s algorithm. NIST standardized two quantum-resistant signature algorithms in August 2024: 

• ML-DSA (FIPS 204), based on CRYSTALS-Dilithium 
• SLH-DSA (FIPS 205), based on SPHINCS+ 

The US NSA’s CNSA 2.0 guidance requires quantum-resistant algorithms for signing software and firmware in national security systems, with exclusive use targeted from 2027. Organizations with long-lived signed artifacts should begin planning the transition now, often via hybrid certificates that carry both a classical and a post-quantum signature during the migration. 

Common Use Cases 

Code signing is required or expected across most software distribution paths. 

• Application distribution: Windows SmartScreen and macOS Gatekeeper block or warn on unsigned executables. Apple’s App Store and Google Play require signed submissions. 
• Software updates and patches: Signed updates prove the patch came from the vendor and has not been modified in transit. 
• Device drivers: Windows requires signed kernel-mode drivers; unsigned drivers are blocked outright on 64-bit Windows. 
• Firmware: IoT, industrial, and automotive firmware is signed to prevent malicious replacement. 
• Scripts and macros: PowerShell, Microsoft Office VBA macros, and similar can be signed to satisfy execution policies. 
• CI/CD artifacts: Container images, packages, and build outputs are increasingly signed as part of software supply-chain security (SLSA, Sigstore). 

Code Signing Best Practices 

Six practices separate a resilient code-signing program from one that becomes a supply-chain incident. 

• Store private keys in an HSM: This is required for publicly trusted code signing since June 1, 2023, and it is the single most effective control against key theft. 
• Timestamp every production signature: Use a trusted TSA (RFC 3161) so signatures survive certificate expiry. 
• Use SHA-256 or stronger: SHA-1 is deprecated. Do not sign new artifacts with SHA-1. 
• Restrict signing access: Require multi-factor authentication for every signing operation. Log who signed what, when, and from where. 
• Rotate keys and monitor for misuse: Track certificate expiry, watch for anomalous signing activity, and revoke immediately on any compromise. 
• Plan the PQC transition: Begin evaluating ML-DSA and hybrid signing for long-lived firmware and system software now. 

How Encryption Consulting Helps 

CodeSign Secure is Encryption Consulting’s enterprise code-signing platform. It centralizes signing operations behind a FIPS 140-2 Level 2 HSM, integrates with Microsoft SignTool, jarsigner, and CI/CD pipelines including Jenkins, Azure DevOps, and GitLab, and supports timestamping and post-quantum signature algorithms as they roll out. It gives security teams full audit trails of every signing operation and enforces the CA/B Forum hardware storage rule by default. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices. 

Frequently Asked Questions 

What is code signing in simple terms? 

Code signing is a way for a software publisher to attach a cryptographic seal to their software. When a user installs the software, their operating system checks the seal to confirm two things: that the software really came from that publisher, and that nobody has modified it since it was signed. If the seal is broken or missing, the OS warns the user or blocks the installation. 

What is the difference between a self-signed and a publicly trusted code signing certificate? 

A self-signed certificate is created by the publisher without external validation and is not trusted by operating systems or browsers by default, so users see security warnings on install. A publicly trusted certificate is issued by a Certificate Authority after identity validation and is trusted by default across platforms. Publicly trusted certificates are required for distributing software to external users; self-signed is fine for internal testing. 

Why do I need to timestamp signed code? 

A code-signing certificate typically expires after one to three years. Without a timestamp, the signature is treated as invalid once the certificate expires, even if the code was signed while the certificate was still valid. A timestamp from a trusted RFC 3161 Timestamp Authority proves when the code was signed, so verification continues to succeed after the certificate expires. Always timestamp production signatures. 

What hash algorithm does code signing use? 

SHA-256 is the current baseline for code signing. SHA-384 and SHA-512 are also acceptable where stronger hashing is preferred. SHA-1 is deprecated and rejected by modern operating systems and CA/B Forum requirements. Post-quantum considerations do not require replacing SHA-256, because Grover’s algorithm only halves the effective security level, leaving SHA-256 with roughly 128-bit post-quantum security. 

What happens to code signing under post-quantum cryptography? 

RSA and ECDSA code signing become vulnerable once a sufficiently large quantum computer exists, because Shor’s algorithm can forge signatures. NIST standardized quantum-resistant signature algorithms in August 2024: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). CNSA 2.0 requires quantum-resistant signing for US national security systems from 2027. Organizations should plan hybrid signing (classical plus post-quantum) for long-lived signed artifacts. 

How do I store a code signing private key safely? 

Store the private key in a Hardware Security Module or hardware token that meets FIPS 140-2 Level 2 (or FIPS 140-3 Level 2) or Common Criteria EAL 4+. This is required by the CA/Browser Forum for all publicly trusted code signing since June 1, 2023. Restrict access with multi-factor authentication, log every signing operation, and never export the private key to disk or transmit it in software. 

Sign With Confidence 

Ready to secure your code-signing operations end to end? Explore CodeSign Secure, or talk to an Encryption Consulting advisor.