Code signing is the practice of attaching a cryptographic digital signature to executable files, installers, scripts, packages or updates so that a computer can verify who published the software and that it has not been modified since it was signed. In software distribution, code signing is the trust mechanism that connects a downloaded file to an identifiable publisher.
Operating systems, app stores, package managers and update systems all rely on it. Windows checks Authenticode signatures, macOS checks Developer ID signatures and notarization, mobile platforms accept only signed apps, and Linux package managers verify signed repository metadata. A valid signature does not prove that software is safe, but it makes tampering detectable and publishers accountable.
How code signing works
Code signing uses public-key cryptography. The publisher holds a private key and a matching public key. During signing, a tool computes a cryptographic hash of the file, typically with SHA-256, and transforms that hash with the private key using an algorithm such as RSA or ECDSA. The result, the signature, is embedded in the file or stored alongside it.
To verify, the operating system recomputes the hash of the file it received, and uses the publisher’s public key to check that the signature matches this hash. If even one byte of the file has changed, the hashes differ and the signature is reported as invalid.
The public key alone says nothing about identity. It is therefore delivered inside a code signing certificate issued by a certificate authority, which has checked the publisher’s identity and signed the certificate with its own key. Verification follows this chain of trust up to a root certificate already trusted by the operating system.
A trusted timestamp completes the process. A timestamping authority countersigns the signature with the time it was made. Software signed while the certificate was valid then remains verifiable after the certificate expires, which is essential because certificates are typically valid for one to three years while software stays in use much longer.
Code signing across platforms
Each major platform has its own signing format and policy, and publishers distributing to several platforms must handle each scheme separately.
| Platform | Signing technology | Additional requirement | Effect of a missing signature |
|---|---|---|---|
| Windows | Authenticode with an X.509 certificate | Reputation building for SmartScreen | Warning screens, blocked in managed setups |
| macOS | Developer ID signature | Notarization by the platform vendor | Gatekeeper blocks normal opening |
| iOS and Android | Platform-specific app signing | Store review or signing key registration | App cannot be installed normally |
| Linux distributions | GPG-signed repositories and packages | Trusted repository keys | Package manager refuses installation |
| Containers | Signatures on image digests, for example Sigstore | Policy enforcement at deployment | Image rejected where policy applies |
In addition to signing, macOS notarization submits the software to an automated malware scan by the platform vendor, and the resulting ticket is checked at launch. On Windows, a new certificate may initially trigger warnings until the publisher builds reputation through downloads without incidents.
Certificate types and key protection
Code signing certificates differ in how thoroughly the publisher is verified and how the private key must be stored. Since 2023, industry rules for publicly trusted certificates require that private keys be kept on hardware security modules or certified tokens, not in ordinary files.
| Option | Identity check | Key storage | Typical use |
|---|---|---|---|
| Organization validation | Company existence and contact verified | Hardware token or HSM | Most commercial software |
| Extended validation | Stricter legal and operational checks | Hardware token or HSM | Drivers, high-trust software |
| Individual validation | Personal identity verified | Hardware token or HSM | Independent developers |
| Cloud signing service | Depends on provider | Managed HSM in the cloud | Automated build pipelines |
| Self-signed certificate | None by a third party | Any | Internal testing, private networks |
Keyless signing, as used by Sigstore in open source ecosystems, takes a different approach: short-lived certificates are tied to an identity from an existing login provider, and every signature is recorded in a public transparency log that anyone can audit.
What code signing does and does not guarantee
A frequent misconception is that signed software is safe software. Code signing provides integrity and attribution, not a verdict on behavior.
| Question | Answered by code signing | Explanation |
|---|---|---|
| Was the file altered after signing | Yes | Any change breaks the hash |
| Who signed the file | Yes, within certificate checks | Identity verified by the authority |
| Is the software free of malware | No | Signed malware exists |
| Was the build process secure | No | Compromised builds are signed normally |
| Is the signer still trustworthy | Partly | Revocation can withdraw trust |
Attacks therefore target the steps before signing. Stolen signing keys let attackers sign malware under a legitimate name, and compromised build systems inject malicious code that is then signed by the genuine process. Supply-chain frameworks add build provenance records to address this gap.
Good practice and common mistakes
Reliable code signing is mostly a matter of operational discipline in the release process.
- Sign every distributed binary, including helper executables, libraries and installers, not only the main program.
- Always add a trusted timestamp, or signatures will become invalid when the certificate expires.
- Restrict access to signing keys to the build system and a few people, with audit logs.
- Sign in the release pipeline, after automated tests, so that only reviewed builds receive a signature.
- Plan for revocation: know how to revoke a compromised certificate and re-sign affected releases quickly.
The simple explanation
Code signing is a digital seal on software. When a company releases a program, it stamps the file with a seal that only it can make. Your computer checks the seal before running the program.
If the seal is intact, you know who made the program and that nobody changed it on the way. It works like the tamper-evident seal on a medicine bottle. The seal does not prove the medicine is right for you. It does prove that nobody opened the bottle.
How it is used in practice
A small company develops a desktop tool for photographers and distributes it from its website for Windows and macOS. Early unsigned builds triggered security warnings, and many customers abandoned the installation. The company buys an organization-validated certificate stored on a cloud signing service and joins the macOS developer program.
Its build pipeline now compiles the software, runs the automated tests, signs every executable with a SHA-256 signature and a trusted timestamp, and submits the macOS build for notarization. Only then are the installers uploaded. The update mechanism inside the application also checks the signature of every downloaded update before installing it. The outcome is installations without security warnings after the reputation period, and updates that cannot be replaced by tampered files on the download server.