What evidence do auditors need for code signing controls?

What auditors are really checking in code signing controls

Auditors are not just asking whether code is signed. They want evidence that the private signing key is controlled, that only approved people or systems can use it, and that released artefacts can be tied back to a legitimate process. That means proving custody, traceability, change control, and response actions if the key or certificate is suspected to be exposed.

For the audit trail itself, the strongest evidence is usually procedural plus technical. A good pack shows who owns the key, where it is held, how signing requests are approved, and which build or release jobs are allowed to invoke signing. If the control is mature, the artefact trace should line up with release approvals rather than ad hoc signing by individuals.

Auditors also care about lifecycle management. If certificates expire, are renewed, are replaced, or are revoked, those actions should be visible in logs or records. The point is not to prove that nothing ever went wrong, but to show that the organisation can detect misuse, constrain signing authority, and retire compromised material quickly enough to reduce trust abuse.

Evidence that demonstrates key custody and restricted usage

The first evidence bucket is custody and access restriction. Auditors typically look for records that show the private key is protected in a controlled store or hardware-backed system, that access is limited to named roles or automated release services, and that the signing path is not available to general developers. This is where a clear custody chain matters more than a policy statement alone.

Useful artefacts include key ownership records, HSM or vault administration logs, access grant and revocation records, and a current list of who or what can sign. If signing is performed by a build service, the evidence should also show which pipeline identity or release system has authority to invoke signing and how that authority is reviewed. NHI-focused evidence becomes especially useful when the signing action is performed by a non-human release identity, because the auditor needs to see that the machine pathway is as tightly governed as a human one. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful background when you need to explain that lifecycle and custody controls are part of the trust model, not just certificate administration.

Auditors may also ask for evidence that keys are not broadly exportable. In practice, that means records showing hardware protection, export restrictions, dual control where relevant, and change approval for any administrative action that could weaken custody. If the control design allows the key to leave protected storage, expect more scrutiny and a higher bar for compensating controls.

Evidence for release approval, signing traceability, and incident response

The second bucket is traceability from release request to signed artefact. Auditors usually want to see that every signed binary, package, or update can be matched to an authorised build or release event. That means signing logs, build job records, release approvals, timestamps, and a versioned chain of custody for the artefact.

Change-management evidence matters here because code signing is only meaningful when it is tied to a controlled release process. A clean audit trail should show who approved the release, what was signed, when the signature was applied, and how the signed artefact was promoted. Where teams sign from CI/CD, auditors often expect the process to be repeatable rather than manually triggered from a workstation. NHIMG’s Secure SDLC Policy Template is a practical reference point for the kind of release governance evidence that makes signing controls easier to defend.

When misuse is detected, evidence of response matters just as much as evidence of prevention. Auditors may ask for certificate revocation or rotation records, key replacement actions, and proof that any affected releases were reviewed. If a compromised signing key could have been used to sign malware or altered builds, the organisation should be able to show how it identified the exposure, revoked trust, and prevented further use.

Risk and Threat Considerations

Code signing failures are high impact because they can turn a trust control into an attacker delivery path. If a private key is stolen, misused, or loosely governed, signed malicious artefacts may appear legitimate to endpoint controls, update mechanisms, or customers that trust the certificate chain.

Failure mechanism: Weak custody, overbroad signing permissions, or missing release traceability lets unauthorised code acquire a trusted signature, or lets a compromised key remain usable long enough to sign malicious or altered artefacts.

Impact: The result can be trusted malware, failed revocation response, broken software integrity, and a much harder incident investigation because the signature itself no longer proves legitimacy.

Practitioner Guidance

What to verify: Ask whether an auditor can follow one signed artefact back to a specific approved release, a specific signing event, and a specific key custodian or release identity. If that chain breaks at any point, the control is not yet audit-ready.

Decision rule: If the signing key is exportable, shared broadly, or usable outside a controlled release path, treat the finding as a design weakness, not just an evidence gap. Tighten custody first, then improve the logging and approval trail.

What practitioners underestimate: The auditor is usually testing whether trust is enforceable over time, not whether the current certificate is valid today. Rotation, revocation, and exception handling are part of the control, so they need evidence too.

Practitioner takeaway: The best audit evidence for code signing is a complete trust chain, from protected key custody through approved release to signed artefact traceability, with clear proof that misuse would trigger rotation or revocation.

Related resources from NHI Mgmt Group

• How should teams defend Oracle ERP controls when auditors question evidence independence?
• How do you know if code signing controls are actually working?
• What evidence should auditors expect from privileged access controls?
• Why do code-signing certificates need stricter lifecycle controls than ordinary certificates?