Code Signing – A Manager’s Guide

Code signing attaches a cryptographic digital signature to software, verifying who published it and confirming it has not been tampered with since. It matters because online software distribution, from mobile apps to enterprise updates to open-source packages, provides no inherent authentication: without signing, a user cannot distinguish legitimate software from a tampered copy. The recommended action: store signing keys in a FIPS 140-2 Level 2 or higher HSM (mandatory since June 2023 per CA/Browser Forum), timestamp every signature, and manage the signing process centrally rather than leaving it to individual developers.

Quick Answer: What Is Code Signing and Why Do Managers Need to Understand It?

Code signing uses public-key cryptography to bind a software artifact to the identity of its publisher and to create a tamper-evident seal that detects any modification after signing. It answers two questions that users and operating systems cannot otherwise answer: did this software come from who it claims, and has it been changed since it was released? Managers need to understand it because the consequences of getting it wrong are organizational: a compromised signing key invalidates every release the organization has ever signed, a failure to revoke a compromised certificate means attackers can continue signing malware in the organization’s name, and the IBM 2026 Cost of a Data Breach Report found that the global average breach cost reached $4.99 million in 2026. Code signing is one of the direct technical controls that prevents the specific class of breach caused by tampered or impersonated software.

How Did Code Signing Become Important?

Three converging trends in software distribution created the environment where code signing became essential.

First, the number of companies developing and releasing software grew enormously, accelerated by the smartphone revolution and the need for every organization to have its own applications. Second, internet distribution replaced physical media (CDs, DVDs) as the primary software delivery mechanism, enabling large-scale near-instant distribution at negligible cost but eliminating the physical chain-of-custody that gave users some confidence in software authenticity. Third, the number of Independent Software Vendors (ISVs) building software applications grew steadily, with some research reports indicating tenfold growth over the past decade.

The result is that software now travels from publisher to user through channels where anyone can intercept, modify, and redistribute it. Code signing addresses this by providing cryptographic proof of both the publisher’s identity and the software’s integrity, at the point of download and installation, without requiring users to trust the distribution channel itself.

The supply chain dimension has made this more urgent: Sonatype’s 2026 State of the Software Supply Chain Report identified more than 454,600 new malicious open-source packages in 2025, a 75% year-over-year increase. Third-party involvement in breaches doubled from 15% to 30% in a single year per the Verizon 2025 Data Breach Investigations Report. Code signing is the control that lets downstream consumers verify that a package actually came from its claimed publisher unmodified, which is precisely the trust relationship supply chain attackers exploit.

How Code Signing Works

The code in code signing can mean executables, archives, drivers, firmware, libraries, packages, and essentially any software intended for release and distribution. To understand how code signing works, it helps to have a basic understanding of Public Key Infrastructure (PKI), which is the set of roles, policies, hardware, software, and procedures used to create, manage, distribute, use, store, and revoke digital certificates.

Code signing has two primary objectives: code ownership (proving the software came from its authentic publisher) and code integrity (proving the code has not been tampered with). The four-step process that achieves both:

1. Key generation: a private key and corresponding public key pair are generated. The private key must be stored in an HSM (see key management section below) and never exported in usable form.
2. Code signing certificate: apply for a code signing certificate from a trusted Certificate Authority (CA). The certificate includes the organization’s identity, the public key, the validity period, and the CA’s digital signature. Since June 2023, publicly trusted code signing certificates require the private key to be stored in FIPS 140-2 Level 2 or higher hardware.
3. Hashing: the software artifact is passed through a hash function that produces a fixed-length hash value representing the artifact’s content. Any change to the artifact, even a single bit, produces a completely different hash value. SHA-256 is the current standard minimum; SHA-1 and MD5 are deprecated and must not be used.
4. Signing: the hash value is encrypted with the private key, producing the digital signature. The signature, along with the code signing certificate, is bundled with the software package for distribution. The original software is not encrypted; only the small hash is signed, which makes the process fast and efficient.

Algorithm and Protocol Selection Guide

Component	Recommended	Minimum acceptable	Deprecated/avoid	Notes
Hash algorithm	SHA-256 or SHA-384	SHA-256	SHA-1, MD5	SHA-1 is deprecated by NIST and rejected by most platforms; MD5 has known collision attacks
Signing algorithm	RSA-3072 or ECDSA P-256	RSA-2048 (expiring per NIST IR 8547 after 2030)	RSA-1024, DSA-1024	ECDSA P-256 provides equivalent security to RSA-3072 with smaller key and signature sizes
Key storage	FIPS 140-2 Level 2 or Level 3 HSM	FIPS 140-2 Level 2 (mandatory per CA/B Forum since June 2023)	Software key stores, file-system private keys	CA/Browser Forum mandates hardware storage for all publicly trusted code signing certificates
Timestamp	RFC 3161 timestamp from a trusted TSA	RFC 3161 timestamp	No timestamp	Without timestamp, signature validity expires when the certificate expires
Post-quantum (planning horizon)	ML-DSA (FIPS 204) for new long-lived signing infrastructure	Current ECDSA/RSA pending PQC transition	RSA-2048 alone for new infrastructure (quantum-vulnerable after 2030)	NIST IR 8547 proposes deprecating classical asymmetric algorithms after 2030

What Happens When the Software Is Downloaded

When a user downloads signed software, the verification process occurs automatically in the browser or operating system:

1. The browser or OS checks that the code signing certificate is from a trusted CA (CA root certificates are pre-installed in browsers and operating systems). If the certificate is not from a trusted CA, the OS displays an alert and may block installation.
2. The public key is extracted from the certificate and used to decrypt the digital signature, recovering the original hash value.
3. The downloaded software (excluding the certificate and signature) is hashed again using the same algorithm.
4. The two hash values are compared. If they match, the software is authentic and unmodified. If they do not match (because an attacker modified the software after signing), the OS alerts the user and refuses installation.

Best Practices for Code Signing

1. Store private keys in an HSM: the HSM does not allow export of private cryptographic keys. Per the CA/Browser Forum’s June 2023 requirement, a FIPS 140-2 Level 2 (or higher) certified HSM is now mandatory for every publicly trusted code signing certificate.
2. Limit private key access: only personnel or automated systems with a specific, documented need should be able to trigger a signing operation. Every signing event should generate an audit log entry including who or what triggered it, when, and what artifact was signed.
3. Always timestamp signed code: an RFC 3161 timestamp from a trusted Timestamping Authority (TSA) binds the signing event to a point in time. This allows the signature to remain verifiable after the signing certificate expires or is revoked, as long as the certificate was valid at the time of signing.
4. Use separate keys per product line: using one key across all products means a compromise of that key invalidates the signing trust of every product the organization has ever released. Separate keys per product line, and ideally per major release, limit the blast radius of a key compromise.
5. Centralize signing management: ad-hoc signing by individual developers using locally-stored keys provides no visibility, auditability, or policy enforcement. A centralized signing platform enforces consistent policy across all products and teams and provides the audit trail required for compliance and incident investigation.

Code Signing for Software Supply Chain Security

When a private key is compromised, the certificate loses its trust, destroying the authenticity and integrity of all software signed with that key. The supply chain risk this addresses is significant: Sonatype’s 2026 State of the Software Supply Chain Report identified more than 454,600 new malicious open-source packages in 2025 (a 75% year-over-year increase), and third-party involvement in breaches doubled from 15% to 30% per the Verizon 2025 DBIR.

For supply chain security, two controls beyond basic signing are essential:

1. Authenticate code before signing: organizations should integrate signing into CI/CD pipelines with approval gates that prevent malicious or unapproved code from reaching the signing step. After signing, artifacts should be verified against the signature before distribution. All signing events must be logged for later audit.
2. Revoke compromised certificates promptly: if a private key is suspected to be compromised, the issuing CA must revoke the certificate immediately. Revocation communicates to all relying parties that the certificate should no longer be trusted. Delayed revocation means attackers can continue signing malware in the organization’s name while the certificate remains valid.

Code Signing in Cloud-Native and CI/CD Environments

Code signing is critical in cloud-native deployments. Container images, application binaries, and Kubernetes deployment manifests all require signing to establish a trusted artifact chain from build to deployment. In cloud-native environments, signing is integrated with CI/CD pipelines so that every artifact produced by the pipeline is signed automatically at the build stage, not as a manual post-build step.

A newer pattern is keyless signing, popularized by the open-source Sigstore project. Instead of a manager provisioning and rotating long-lived certificates for every pipeline, keyless signing issues a short-lived certificate tied to an OIDC (OpenID Connect) identity, such as a CI/CD workload identity, at the moment of signing, then discards the private key entirely. The signature and a public record are logged to a transparency ledger instead of relying on a certificate that must be tracked, renewed, and revoked over months or years.

Traditional PKI-Based Signing vs. Keyless (Sigstore-Style) Signing

Aspect	Traditional PKI-Based Signing	Keyless (Sigstore-Style) Signing
Key lifetime	Long-lived (typically 1-3 years), must be actively managed	Ephemeral; issued per signing event, then discarded
Key storage	HSM or hardware token (mandatory since June 2023)	No persistent private key to store
Identity binding	Organization identity verified by a CA at issuance	Workload/OIDC identity verified at signing time
Revocation	Manual CA revocation process if compromised	Not applicable; a compromised ephemeral key expires almost immediately
Best for	Shipped desktop software, drivers, installers requiring long-term signature validity	CI/CD pipelines, container images, cloud-native artifacts signed frequently

Most enterprises run both models: traditional certificates for shipped, long-lived binaries, and keyless or short-lived signing for high-frequency artifacts moving through CI/CD pipelines.

Deployment Examples

Windows desktop application release: the developer submits a build to the signing pipeline. CodeSign Secure hashes the executable, sends the hash to the HSM for RSA-3072 signing, retrieves the signed hash, applies an RFC 3161 timestamp from the TSA, and bundles the certificate, signature, and timestamp with the distributable. The entire process occurs inside the pipeline without the private key ever leaving the HSM. When users download the installer, Windows SmartScreen verifies the certificate chain against trusted roots and confirms the hash matches before allowing installation.

Container image signing in a Kubernetes environment: after a container image is built and pushed to the registry, the CI/CD pipeline invokes CodeSign Secure to sign the image digest using the organization’s ECDSA P-256 key stored in the HSM. The signed image digest and the certificate are stored in the registry alongside the image. Kubernetes admission controllers (such as OPA Gatekeeper or Kyverno) are configured to verify the signature before allowing any container to be deployed in production, rejecting images that were not signed by the organization’s key.

Open-source package release with keyless signing (Sigstore): the package maintainer’s GitHub Actions release workflow triggers Sigstore’s cosign tool, which requests a short-lived certificate from Sigstore’s Fulcio CA tied to the GitHub Actions OIDC identity of the release workflow. The package is signed with the ephemeral key, the private key is immediately discarded, and the signature is recorded in Sigstore’s Rekor transparency log. Downstream consumers use cosign verify to check the signature against the Rekor log, confirming the package was signed by the legitimate release workflow at the specific commit.

How CodeSign Secure Helps Managers Control This Risk

Managers do not need to operate the cryptography themselves, but they do need a platform that enforces the best practices above without relying on individual developers to remember them. Encryption Consulting’s CodeSign Secure does this by signing every artifact inside an HSM so private keys never leave hardware, applying role-based access control so only authorized users can trigger a signing event, and logging every signing action for the audit trail that best practice above requires.

CodeSign Secure also uses client-side hashing, so the file being signed never leaves the customer’s environment in an unprotected state, and it timestamps every signature to prevent the problem of software signatures expiring when the certificate does. For teams managing both shipped binaries and CI/CD pipelines, CodeSign Secure provides one centralized platform covering both traditional HSM-backed signing and integration with modern pipeline signing workflows, rather than requiring a separate manual process for each artifact type.

Limitations of Code Signing

• Code signing verifies integrity and identity, not correctness: a signed artifact proves it came from its claimed publisher unmodified. It does not prove the code is free of vulnerabilities, backdoors, or malicious logic that was present before signing. A developer can sign malicious code they wrote themselves. Code signing and application security testing address different threat categories.
• Key compromise is catastrophic and difficult to contain: if a signing private key is compromised, every artifact ever signed with that key is suspect. Revocation communicates distrust to relying parties, but artifacts already installed on user systems remain signed. The consequence is why key management, HSM storage, and least-privilege access to signing operations matter so much.
• Revocation checking has gaps: certificate revocation works only if relying parties actually check revocation status. OCSP stapling and CRL distribution improve coverage, but some platforms and environments do not perform revocation checks reliably. This means a revoked certificate may continue to be accepted in environments that do not check revocation.
• Keyless signing depends on the transparency log infrastructure: keyless signing with Sigstore moves trust to the Rekor transparency log and Fulcio CA. These are new infrastructure components with their own availability and trust requirements. Organizations adopting keyless signing for critical artifacts should understand these dependencies.

Conclusion

Code signing is an essential part of the software development lifecycle, and the landscape around it has changed significantly in recent years. HSM storage is now mandatory, not optional, for publicly trusted certificates. The supply chain attack surface has expanded dramatically. And new signing models including keyless signing and pipeline-integrated signing are changing how organizations approach artifact trust at scale.

For managers, the key decisions are organizational: who controls signing keys, what access controls gate signing events, how signing is audited, and how the organization responds when a key is compromised. These are governance decisions as much as technical ones, and they require the same rigor applied to any other privileged system in the organization. If you want to assess your current code signing posture or integrate signing into your CI/CD pipelines with HSM-backed key protection, contact Encryption Consulting to discuss where to start.

Frequently Asked Questions

What are the two main objectives of code signing?

Code ownership, proving software comes from its claimed publisher, and code integrity, proving it has not been altered since it was signed. Everything else in a code signing process exists to support one of these two objectives.

What are the four steps in the code signing process?

Key generation, obtaining a code signing certificate from a Certificate Authority, hashing the code, and signing that hash with the private key. The signed hash and certificate then travel with the software package.

Why must code signing private keys be stored in an HSM?

A hardware security module prevents the private key from ever being exported in a usable form, which is exactly what an attacker needs to sign malicious code convincingly. Since June 1, 2023, the CA/Browser Forum has made hardware key storage mandatory for every publicly trusted code signing certificate.

What happens if a code signing certificate’s private key is compromised?

The certificate loses its trust entirely. Every piece of software ever signed with that key becomes suspect, which is why the CA must revoke the compromised certificate immediately and why security teams recommend rotating signing keys rather than reusing one key across many product lines.

How much does the average data breach cost, and why does that matter for code signing?

The global average cost of a data breach reached $4.99 million in 2026, a 12% increase year over year, per IBM’s 2026 Cost of a Data Breach Report. Code signing is one of the direct controls preventing the specific class of breach caused by tampered or impersonated software.

Why is code signing especially important for software supply chain security?

Sonatype identified over 454,600 new malicious open-source packages in 2025, a 75% year-over-year increase, and third-party breach involvement doubled to 30% per the Verizon 2025 DBIR. Code signing lets downstream users verify that a package came from its claimed publisher unmodified, which is exactly the trust supply chain attackers exploit.

What is the difference between traditional PKI-based code signing and keyless signing?

Traditional signing uses a long-lived certificate stored in an HSM, renewed and revoked through the CA. Keyless signing issues an ephemeral certificate tied to a workload identity at the moment of signing and discards the key immediately, trading long-term key management for per-event issuance via a transparency log.

Does timestamping matter if my code signing certificate expires?

Yes. Without a timestamp, a signature’s validity expires with the certificate. An RFC 3161 timestamp lets signed code continue to be verified as authentic even after the original certificate is no longer valid, as long as the certificate was valid at the time of signing.

How does code signing fit into CI/CD and cloud-native environments?

Code signing is built directly into the pipeline rather than applied as a manual final step, signing container images and binaries automatically as they are built. Many cloud-native teams pair traditional HSM-backed signing for long-lived binaries with keyless or short-lived signing for high-frequency pipeline artifacts.

How does CodeSign Secure help managers control code signing risk?

It signs every artifact inside an HSM so keys never leave hardware, enforces role-based access control over who can trigger a signing event, timestamps every signature, and logs every action for audit purposes, turning the best practices in this guide into enforced platform behavior.