Code Signing – A Manager’s Guide

Published: May 2024 | Updated: August 2026

Code signing is the practice of attaching a cryptographic digital signature to software, verifying who published it and confirming it hasn’t been tampered with since. It works by hashing the code, encrypting that hash with a private key tied to a code signing certificate, and letting anyone with the public key verify both the publisher’s identity and the code’s integrity before installation.

How Did Code Signing Become Important?

Let’s look at three interesting trends that have emerged in software development over the last decade.

One is that the number of companies that develop and release software has increased enormously. A key trigger for this has been the smartphone revolution and the associated need for companies to have their own mobile apps for their customers, as well as employees.

The second trend is that the primary means to distribute software, as well as the related patches and upgrades, has now ubiquitously become the internet. The advantages of using online software distribution, versus traditional methods such as CDs (Compact Discs), are significant: large-scale, near-instant software distribution at extremely low costs.

https://www.youtube.com/embed/ZE_fPKtallY?si=-CCE3gNYSFyY0ONB

The third trend is that the number of Independent Software Vendors (ISVs) who are primarily in the business of building software applications has grown steadily over the years, with some research reports indicating a tenfold growth over the last decade.

These trends explain how online software distribution has become the preferred method for companies developing and selling software. But does this method and its convenience-benefit also introduce business risk?

How does a user know whether the software being downloaded is from the original author (and not an impersonator)? How does the user know that the software has not been tampered with, and some malicious code has been inserted into the software? Code Signing provides the answer to these questions by helping companies secure the software they release.

Apart from software developers and enterprise security specialists, it is critical for project managers, product managers, engineering managers, and even senior management to be familiar with code signing. The reason is simple. Code Signing is an excellent safeguard against malware and supply chain attacks, and those attacks are getting more expensive every year: the global average cost of a data breach reached a record $4.99 million in 2026, a 12% increase year over year, according to IBM’s 2026 Cost of a Data Breach Report, published July 29, 2026 (based on 602 breached organizations studied by the Ponemon Institute).

How Code Signing Works?

The “code” in code signing can mean executables, archives, drivers, firmware, libraries, packages, and essentially any software that is intended for release and distribution to another party or user.

To understand how code signing works, it is important to have a basic understanding of Public Key Infrastructure (PKI). PKI is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. It is also important to understand the two primary objectives of code signing:

1. Code Ownership: Proving that the software code being downloaded and installed is from the original, authentic owner.
2. Code Integrity: Proving that the code has not been tampered with or changed in any way, e.g., with some malicious code (malware) being inserted in it.

The process of code signing involves four main steps, which are described below.

1. Key Generation: The basic requirement for code signing is to have a private key and the corresponding public key available. The public and private key pair can be generated using a (trusted) third-party tool or software.
2. Code Signing Certificate: You then need to apply for a code signing certificate with a Certificate Authority (CA), which is a trusted entity that issues digital certificates. The application needs to include your public key along with other organization identity details. The certificate that the CA issues includes information such as your organization identity, your public key, the certificate validity period, and the digital signature of the CA.
3. Hashing: The next step is hashing your code. Hashing is a one-way process where data of any size and type can be converted, through a mathematical algorithm, to fixed size data. The algorithm is called a hash function, and its output, i.e., the fixed-size data, is called a hash value or hash. The hash value is totally different from the original data, and the original data cannot be deduced from the hash.
4. Signing: The hash value of the software is then encrypted or “signed” using the private key. The encrypted hash, along with the code signing certificate, is added to the software package that is now ready to be shipped or distributed. The reason why the hash value is signed, and not the original software, is that the hash is a small amount of data, which can be encrypted very quickly, whereas the original software might be very large and take a long time to encrypt. Also, if the original software code is modified even by a single bit, the hash value produced by the hash function is totally different, which is what makes tampering detectable.

Best Practices for Code Signing

We suggest the following practices for a secure Code Signing process:

1. Storing the private keys in HSM: The Hardware Security Module (HSM) doesn’t allow the export of private cryptographic keys to software, as that will make these keys vulnerable to attacks. Following the CA/Browser Forum’s June 2023 requirement, a FIPS 140-2 Level 2 (or higher) certified HSM is now mandatory, not just recommended, for every publicly trusted code signing certificate.
2. Limiting private Key access: We highly suggest allowing only minimal connections to client systems with the private keys. Limiting key access to limited users will resolve a lot of inconspicuous user activity.
3. Code should always be Time-Stamped: Time stamping is a good way to track when code has been signed and helps check the validity period of the signature. It also allows the code to be verified after the certificate used for signing has expired or been revoked.
4. Avoid overusing one key: Organizations sometimes use the same key to sign code across multiple product lines and businesses. This isn’t a good approach. If that key gets compromised, all the releases signed by that key will be at risk. A good practice would be to rotate your keys as frequently as possible.
5. Create transparency and centralize the management: Generally, organizations manage certificates and keys manually. But this isn’t a good approach, as manual processes provide neither complete visibility nor centralized control over keys.

What Happens When the Software Is Downloaded?

At the receiver side, the browser being used to download the software first checks that the certificate in the code being downloaded is authentic and from a trustworthy CA. This is possible since the public keys of most well-known CAs are already pre-installed with most browsers and operating systems.

If the certificate is not authenticated, the browser will alert you, and depending on browser security settings, may or may not allow the download. If the user ignores this warning and attempts to install the software, the operating system will issue an alert indicating that the software publisher could not be verified, effectively discouraging the user from installing the software. This addresses the first objective of code signing, i.e., establishing code ownership.

If the certificate is authenticated, the public key is extracted from the certificate and used to decrypt the encrypted hash available in the package. Next, the actual downloaded software (minus the certificate and hash) is hashed again using the same hash function. This hash value is compared with the decrypted hash value. If they match, the software has not been altered. If an attacker has changed the software, then the hashes will not match, the operating system will throw an alert, and refuse to install the software. This addresses the second objective, i.e., ensuring code integrity.

Code Signing for Software Supply Chain Security

When a private key is compromised, the certificate loses its trust, destroying the authenticity and integrity of the software signed by this code-signing certificate. That risk is growing fast: 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 (press release published January 28, 2026), and third-party involvement in breaches doubled from 15% to 30% in a single year, per the Verizon 2025 Data Breach Investigations Report. Code-signing practices ensure secure product development, production, and deployment. The best practices for protecting the software supply chain with secure code-signing are:

1. Authenticate code before signing, and releasing: Organizations should use streamlined code signing processes, such as CI/CD pipelines and approval processes, to prevent malicious code from being signed. After signing, the code or artifact should be authenticated and verified before being released to users. Organizations should also maintain logs of all code-signing processes for auditing later.
2. Revoke compromised certificates: To ensure code safety, revocation should be followed. Certificates that have been compromised should be revoked by the CA; this way, the corrupted or compromised certificates cannot be used for code-signing activities.

Code Signing in Cloud-Native Environments

Code Signing is very important in deployments of cloud-native applications or DevOps. Before distributing software to users, organizations can sign and verify software types such as container images and application binaries. In cloud-native environments, code signing is integrated with CI/CD pipelines to maintain the trust and authenticity of the software, preventing the risk of tampering with code that makes it malicious for distribution.

A newer pattern worth knowing about 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 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 of it are logged to a transparency ledger instead of relying on a certificate that has to be tracked, renewed, and revoked over months or years.

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

Both approaches solve code ownership and code integrity; they differ in how the signing key is provisioned and how long it lives.

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 side by side rather than replacing one with the other: traditional certificates for shipped, long-lived binaries, and keyless or short-lived signing for the high-frequency artifacts moving through a CI/CD pipeline.

How CodeSign Secure Helps Managers Control This Risk

Managers don’t 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 #5 above calls for.

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 exact “software expires when the certificate does” problem described earlier in this guide. For teams managing both shipped binaries and CI/CD pipelines, that means one centralized platform covering both signing models in the comparison table above, rather than a separate manual process for each.

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 hasn’t 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, not optional, 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 today, and why does that matter for code signing?

The global average cost of a data breach reached a record $4.99 million in 2026, a 12% increase year over year, according to IBM’s 2026 Cost of a Data Breach Report. Code signing is one of the direct controls available for 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 involvement in breaches doubled to 30% per the Verizon 2025 DBIR. Code signing lets downstream users verify that a package or update actually came from its claimed publisher unmodified, which is exactly the trust supply chain attackers try to exploit.

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

Traditional signing uses a long-lived certificate and private key that must be provisioned, stored in an HSM, and eventually renewed or revoked. Keyless signing, popularized by Sigstore, issues an ephemeral certificate tied to a workload identity at the moment of signing and discards the key immediately afterward, trading long-term key management for per-event issuance.

Does timestamping really matter if my code signing certificate expires?

Yes. Without a timestamp, a signature’s validity is tied to the certificate’s validity period, so once the certificate expires, the signature effectively expires with it. A timestamp lets the signed code continue to be recognized as authentic even after the original certificate is no longer valid.

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

Code signing gets built directly into the pipeline rather than applied as a manual final step, signing container images and binaries automatically as they’re built. Many cloud-native teams pair this with keyless or short-lived signing to avoid managing long-term certificates for high-frequency, automated builds.

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 rather than something each developer has to remember.

Conclusion

Today, code signing is an essential part of the software development lifecycle. Without code signing, enterprises risk losing users and face enormous financial and reputational risk in case of malware or supply chain attacks. It is therefore critical for software line managers as well as senior management to understand code signing, the hardware key requirements now mandatory across the industry, and where the practice is heading next with keyless and cloud-native signing models.