How should security teams treat code signing as a trust signal when malware can use stolen certificates?

Why code signing is only a trust signal, not proof of safety

Code signing answers a narrow question: did this file come from a key that was trusted to sign it? That is useful, but it is not the same as proving the file is benign. Attackers can steal signing keys or abuse compromised certificates, so a signed binary can still be malicious, backdoored, or repackaged for a specific target.

The practical mistake is treating a valid signature as an allow-by-default decision. Signature status tells you something about origin and tamper detection, not intent, safety, or current trustworthiness. For that reason, code signing should sit alongside CA/Browser Forum revocation expectations and not replace file reputation, publisher history, and content inspection.

When defenders understand code signing as one input, they can separate provenance from trust. A signed file may still deserve blocking if its behavior is unexpected, its distribution path is suspicious, or the certificate is associated with recent compromise indicators. That is why the relevant control question is not “is it signed?” but “does everything else about this file still support execution?”

What changes when attackers use stolen certificates

Stolen certificates change the threat model because they let malware borrow the appearance of legitimacy. That can improve social engineering, reduce user suspicion, and sometimes weaken automated allowlisting decisions that rely too heavily on publisher identity. In practice, a trusted signature can become part of the evasion technique rather than a defense.

Code signing abuse is especially dangerous when defenders assume certificate trust is durable. A certificate can be revoked, but revocation is only useful if the environment checks it reliably and in time. Teams should therefore understand the lifecycle of signing credentials, not just the signature result on the endpoint. Cryptographic Key Management Guide is a useful reference for the key lifecycle discipline that underpins trustworthy signing.

The strongest practical lesson from breach patterns is that compromised signing material can turn a normal software delivery or release path into a malware distribution path. That is why a signed artifact from a known publisher still requires scrutiny if there is evidence of key theft, unusual release timing, abnormal binary lineage, or a certificate that appears across unrelated malware samples.

How defenders should evaluate signed code before allowing execution

Security teams should use a layered decision model: verify the signature, then evaluate the publisher and certificate reputation, then inspect the file’s behavior and payload characteristics. This is most effective when combined with revocation checks, malware scanning, sandboxing, and basic content validation such as hash comparison, installer structure review, and expected parent-child process behavior.

For certificate-heavy environments, the key management perspective matters as much as the endpoint perspective. NIST SP 800-57 Key Management is directly relevant because signing trust depends on how keys are generated, protected, rotated, and retired after compromise. If a signing key can be reused indefinitely, the signature becomes a weaker control over time.

Teams should also distinguish between content trust and transport trust. A file signed by a legitimate certificate authority path can still be unsafe if the binary has been modified earlier in the release chain or if a legitimate signer was coerced, compromised, or abused. CIS Controls v8 supports this layered approach through controls for malware defense, access management, and audit logging.

Risk and Threat Considerations

Stolen certificates create a trust inversion problem: the very mechanism intended to reassure defenders can be turned into an evasion channel. That increases the odds of malicious code bypassing simple allowlisting, especially in environments that overweight publisher trust and underweight behavioral signals.

Failure mechanism: Attackers obtain signing keys or certificates, sign malicious code with apparently valid provenance, and rely on defenders to stop at the signature check instead of validating revocation, lineage, and runtime behavior.

Impact: Malware can look legitimate long enough to reach execution, expand blast radius, and erode confidence in publisher-based trust controls. In the worst case, a single compromised signing identity can affect multiple products or release channels before the abuse is detected.

Practitioner Guidance

What to prioritize: Treat revocation checking and publisher reputation review as mandatory for any trust decision that uses code signing. If a signed file comes from a publisher with poor release hygiene, recent compromise history, or an unexpected certificate chain, escalate the review rather than relying on the signature alone.

What to verify: Confirm that your execution policy actually evaluates revocation status, certificate age, and certificate lineage, not just whether a signature is present. Also verify that detections can distinguish a genuine publisher release from a newly signed payload that behaves unlike the publisher’s normal software.

Decision rule: If the signature is valid but the binary is unfamiliar, newly observed, or behaviorally inconsistent, treat it as a risk investigation, not an approval. The safer default is to require a second trust signal, such as reputation, provenance, or sandbox verdict, before execution is allowed.

Practitioner takeaway: Code signing should narrow uncertainty, not end it; when attackers can steal signing material, trust must be earned from the whole artifact and its behavior, not from the certificate alone.

Related resources from NHI Mgmt Group

• How should security teams implement a chain of trust for certificates and code signing?
• How do teams decide whether SSL certificates are enough for trust, or whether code signing is also needed?
• How can security teams reduce the impact of compromised code-signing certificates?
• How should security teams manage code signing as a program instead of just protecting certificates?