Code Signing: Definition & How It Works

Code signing uses a digital signature to verify software integrity (the code hasn’t been altered) and to identify the publisher. In practice, code signing is one of the most important supply chain security controls you can deploy because it helps users, operating systems, and security tools decide what code is safe to run.

How code signing works#

At a high level, code signing combines hashing, public-key cryptography, and trust chains.

1) The signer generates a digest of the code

When a developer (or a build pipeline) signs an artifact—an EXE, MSI, DLL, package, script, container image manifest, etc.—the signing tool computes a cryptographic hash (digest) of the relevant bytes. The hash uniquely represents the content; any change to the code changes the hash.

2) The hash is signed with a private key

The signer uses a private key to sign the hash. The result is the signature. The private key must be protected; if it’s stolen, attackers can sign malware that looks legitimate.

3) A certificate binds identity to the public key

To let others validate the signature, the signer provides a certificate containing the corresponding public key and identity attributes (organization, sometimes individual, and other metadata). Most ecosystems rely on a Certificate Authority (CA) to vouch for the identity in that certificate.

4) Verifiers validate three things

When a user’s system, a security tool, or an application validates a signature, it generally checks:

• Integrity: Does the signature match the file’s current hash?
• Authenticity / identity: Does the certificate chain to a trusted CA (or a trusted internal CA), and is the certificate intended for code signing?
• Validity (time and revocation): Was the certificate valid at signing time, and has it been revoked?

5) Timestamping prevents “expired cert = broken software”

Code-signing certificates expire. Without timestamping, signatures can appear invalid once the cert expires—even if the code was legitimately signed while the cert was valid.

A timestamp authority (TSA) signs a statement that the signature existed at a specific time. Verifiers then accept the signature as long as the cert was valid at that timestamp, even after expiration (revocation rules can still invalidate it, depending on policy).

Practitioner takeaways (what to do with this)

• Always verify the signer identity, not just “Signed.” Attackers can obtain certificates (including via fraudulent registration) or steal keys.
• Ensure build systems sign in a controlled environment (HSM-backed keys, least privilege, audit logs).
• Make timestamping mandatory in release pipelines to avoid operational failures when certs renew.

Technical notes: common verification commands

# Windows: inspect Authenticode signature
signtool verify /pa /v "C:\Path\app.exe"

# Windows PowerShell: check signature status for scripts/binaries
Get-AuthenticodeSignature "C:\Path\script.ps1" | Format-List *

# macOS: verify code signature
codesign -dv --verbose=4 /Applications/App.app
codesign --verify --deep --strict --verbose=2 /Applications/App.app

# macOS: check Gatekeeper assessment (policy acceptance)
spctl --assess --type execute --verbose=4 /Applications/App.app

# Linux (packages): verify a package signature (examples vary by distro)
rpm -Kv package.rpm
dpkg-sig --verify package.deb

When you’ll encounter code signing#

Code signing shows up wherever systems need to decide whether to trust and run code—especially in environments trying to reduce malware risk and supply-chain exposure.

OS installation and launch warnings

• Windows SmartScreen / Defender warnings: Signed binaries from known publishers reduce prompts; unsigned or rare binaries trigger stronger warnings.
• macOS Gatekeeper: Apps distributed outside the App Store often need a valid Developer ID signature; some workflows also require notarization.
• Mobile platforms: iOS and Android app ecosystems use signing as a core security control (app store and enterprise distribution models differ, but signatures are foundational).

What next (admin checklist): - If a prompt appears for a tool your org uses, verify the publisher name, certificate chain, and download source before allowing. - If a previously signed app becomes unsigned after an update, treat it as potential tampering.

Enterprise application control and allowlisting

Controls such as AppLocker, Windows Defender Application Control (WDAC), and third-party allowlisting commonly rely on signer rules:

• Allow “signed by Publisher X”
• Block “unsigned”
• Allow only signed scripts/modules

What next: - Prefer publisher-based rules over hash-based rules when possible (hash rules break on every update). - Maintain an exception process for urgent tooling—but require provenance and quick review.

Drivers, kernel modules, and boot chains

Many platforms require kernel-mode components and drivers to be signed, because unsigned kernel code can bypass security boundaries.

What next: - Treat unsigned driver installation attempts as critical events. - Monitor for driver load failures that could indicate tampering or policy misconfiguration.

Scripts and automation in IT environments

PowerShell, VBScript, and other scripting environments can enforce signatures (e.g., PowerShell execution policies combined with enterprise controls).

What next: - In managed environments, require signing for internal scripts and modules. - Store signing keys separately from developer workstations; avoid “signing on the desktop.”

CI/CD, software updates, and supply chain security

Modern software delivery often includes signing at build/release time:

• Release artifacts (installers, archives)
• Update manifests
• Container images (signing the image or its manifest)
• Infrastructure-as-code modules

What next: - Add signature verification to deployment steps (fail closed where appropriate). - Log and alert on signature validation failures, unexpected signers, or missing timestamps. - For a broader grounding in why this matters, see our explainer on supply-chain incidents: what is a supply chain attack.

Technical notes: what “bad signing” looks like in practice

Common failure modes you’ll see during validation:

• “Signature is invalid”: file was modified after signing (tampering, corruption, or repackaging).
• “Unknown publisher”: certificate chain doesn’t reach a trusted root (missing root, private CA not deployed, or malicious cert).
• “Certificate expired” without timestamp: build/release process didn’t timestamp.
• Revocation failures / offline revocation checking: systems can’t reach CRL/OCSP endpoints; depending on policy, this may soft-fail or hard-fail.

Operational guidance for small teams (practical baseline)#

If you’re implementing code signing internally, the practical baseline is:

1. Protect private keys (prefer HSM-backed or dedicated signing services; limit who can sign).
2. Mandate timestamping on every release.
3. Automate verification in CI/CD and deployment (and alert on failures).
4. Investigate “unexpectedly signed” code just as aggressively as unsigned code (stolen certs happen).

If you’re strengthening the broader endpoint side of the house (beyond signing), you may also want to compare endpoint protection options for business fleets: best antivirus for windows business endpoints 2026.

Tools you might use alongside code signing (optional, defense-in-depth)#

Code signing helps establish trust, but it doesn’t replace endpoint and account hygiene. Depending on your environment:

• A reputable VPN can reduce exposure on untrusted networks for admins and developers (for example, NordVPN: Check NordVPN pricing →).
• A business password manager can reduce the odds that signing portals, developer accounts, or build systems get compromised (for example, 1Password: Try 1Password →). If you’re evaluating options, see password manager for small business 2026.