Code Signing Best Practices for Secure Software Releases

Which Code Signing Controls Matter Most?

The most important code signing controls protect the private key and prevent unapproved software from being signed. Hardware-based key protection reduces the risk of key extraction, but it cannot decide whether a signing request is legitimate.

An attacker who cannot export a private key may still misuse an authorized signing service. A properly reviewed artifact can still fail validation if it is modified after signing.

Protect the Private Key

A code signing private key should be generated, stored and used inside approved cryptographic hardware or a compliant remote signing service. It should not be exportable to a developer laptop, shared folder, source repository, build directory or ordinary backup system.

For publicly trusted certificates, hardware protection applies to both OV and EV code signing. Since June 1, 2023, the CA/Browser Forum Code Signing Baseline Requirements have required subscriber private keys to be generated, stored and used in a suitable hardware cryptographic module, such as a qualified hardware token or hardware security module (HSM).

Only approved build agents, release services, and administrative systems should be able to reach the signing environment. Hardware protection prevents key extraction; approving each signing request is a separate step that determines whether the file itself should be trusted.

Control Who Can Sign Software

Only approved people and systems should be able to request a production signature. Access should follow the principle of least privilege, with each identity receiving only the permissions needed for its role.

• Developers produce release candidates.
• Reviewers approve the software.
• Release managers authorize production signing.
• Service identities submit approved artifacts.
• Security administrators manage the signing environment.

Small teams may combine some responsibilities. Production signing, however, should not depend on a shared account that cannot be traced to a specific person or service.

Use multi-factor authentication where supported. Automated pipelines should use dedicated workload or managed identities rather than credentials assigned to an individual developer.

Where the platform permits it, restrict identities by repository, pipeline, file type, product, environment, certificate or release window. High-impact releases may also require approval from a second authorized person.

Verify Every Artifact Before Signing

Every artifact should be scanned, reviewed, and matched to the approved release before it is signed. A valid signature cannot distinguish reviewed software from malicious code submitted through a compromised build process.

Create a cryptographic hash when the release candidate is approved. Compare it with the hash received by the signing workflow. A mismatch should stop the process.

Security checks may include malware scanning, vulnerability testing, dependency analysis, secret detection, and package validation. The exact combination depend on the software and its risk level. Do not treat a single antivirus scan as sufficient evidence that an software is safe.

The release record should identify the repository and approved revision, build job, artifact name and hash, results of required security checks, release approver, and signing policy.

For high-assurance releases, compare hashes from builds produced on independent, isolated systems from the same source revision – an unexplained mismatch is a strong signal of tampering somewhere in the pipeline.

Build Signing into a Controlled Release Workflow

Code signing should be part of a repeatable workflow with defined checks before and after the signature is applied. Automation can reduce manual handling, but it should not allow every build or pull request to reach the production key.

Keep unsigned release candidates separate from completed signed packages. Verification must be performed on the version users will download because packaging, compression or later modification can invalidate an earlier signature.

Keep Test and Production Signing Separate

Test and production builds should use different certificates, keys and access policies. A test certificate should never be used for a public release, and the production key should not be available to routine development workflows.

A development identity may be self-signed, issued by an internal CA, trusted only on managed test devices or restricted to staging. Do not distribute that trust broadly.

Production signing should have stricter controls. It may require an approved pipeline, protected build agent, release authorization or additional reviewer. Local builds and pull-request workflows should not have access to the production identity.

Before publication, confirm that the final artifact carries the expected production signature. An unsigned or test-signed build should fail the release check.

Timestamp and Verify Every Release

Every production signature should receive a trusted timestamp and then be verified on the final distributed file. Timestamping records that the signature was created while the code signing certificate was valid.

With an accepted timestamp, a signature may continue to validate after ordinary certificate expiration because the verifier can establish when it was applied. Timestamping does not repair an invalid signature or guarantee continued trust after every revocation or compromise event.

Treat timestamp failure as a release failure

A signing tool may apply a signature even when it cannot reach the timestamp server. Require the workflow to confirm that a timestamp was added. If timestamping fails, stop the release, record the error and retry through the approved process.

Verify after signing and packaging

• The signature is cryptographically valid.
• The expected publisher identity appears.
• The certificate chains to the expected trusted root.
• The file digest matches the signed content.
• A valid timestamp is present.
• The expected certificate and digest algorithm were used.
• Every component requiring a signature has been signed.

Manage Certificates and Keys Throughout Their Lifecycle

Code signing certificates and keys should be inventoried, monitored, renewed, replaced, and retired through a documented lifecycle. Waiting for a signing command to fail is not an acceptable way to discover an expired certificate.

Record the certificate serial number, associated key or service, CA, responsible owner, authorized products, environments, dates, renewal status and incident contacts.

Publicly trusted code signing certificates issued on or after March 1, 2026, have a maximum validity period of 460 days. Start renewal early enough to complete validation, issuance, key setup, workflow configuration, and release testing.

A renewal is not complete merely because the new certificate has been issued. Test signing, timestamping, certificate-chain validation and access from approved workflows before relying on it in production.

Teams should also monitor changes to digest algorithms, key lengths, cryptographic module standards, CA policies, signing tools, and platform rules. Replace a key when compromise, infrastructure changes, policy or cryptographic requirements demand. When a key is retired, disable it from new signing but retain the records needed to verify historical releases.

Log and Monitor Signing Activity

Every production signing event should record what was signed, when it was signed, which certificate was used and who or what authorized the request.

A signing record may include the artifact name, version and hash; signing time; certificate or key identifier; requesting identity; release approval; timestamp status; and signing and verification results.

Protect logs from unauthorized deletion or alteration. Monitor unusual signing volume, unexpected times, unfamiliar systems, failed authentication, incorrect certificates and requests without a matching release record.

Not every unusual event indicates compromise. It should still be investigated before the related software is published.

Prepare for Signing Key Compromise

A suspected signing-key compromise requires an immediate pause in signing, preservation of relevant records, contact with the issuing CA and identification of affected software.

1. Pause signing. Disable the affected key, token, account, or service.
2. Preserve evidence. Retain signing, authentication, build and approval records.
3. Contact the CA. Follow its compromise-reporting and revocation process.
4. Identify affected releases. Separate legitimate and potentially unauthorized signatures.
5. Assess distribution. Determine whether affected software reached users or third parties.
6. Replace and recover. Create a new key in a clean environment and correct the cause before restoring signing.

Code Signing Best Practices Checklist

Use this checklist before granting production signing access, approving a new integration or publishing signed software.

• The private key remains inside approved cryptographic hardware or a compliant signing service.
• Signing access is limited to authorized identities and workflows.
• Test and production signing are separated.
• The artifact matches the approved build and recorded hash.
• Required malware, vulnerability, and dependency checks have passed.
• The release has the required approval.
• A trusted timestamp was added.
• The final downloadable package passed signature verification.
• Certificate expiration and renewal are being monitored.
• The signing event was recorded.
• A key-compromise response plan is available.

Questions About Secure Code Signing