Compromised Code Signing Certificate Playbook

A stolen code signing key lets an attacker ship malware that carries your name, and the decision that fixes it, revocation, can also break every legitimate release you have shipped. Few teams have rehearsed the choices: which revocation date to give the certificate authority, which releases to re-sign, what to tell customers and how to stop the same key being stolen again. This template gives [Organisation] a ready-to-adopt playbook for a suspected or confirmed compromise of a code signing private key or signing service. It is for product security, release engineering, PKI owners and incident responders. It complements the Supply Chain Compromise Response Playbook, which covers tampered builds more broadly, and the Code Signing Security Guide, which covers prevention.

How to use this template

Replace placeholders in square brackets, such as [Organisation], [Product security lead] and [CA name], before adoption.
Prepare the inputs now: the playbook depends on an inventory of signing certificates, their CAs, where keys live, and a log of what each key signed. Without that log, section 4 cannot set a safe revocation date.
Scope: publicly trusted code signing certificates (Authenticode, EV code signing), platform developer certificates, package and container signing keys, and internal signing CAs. Where a rule differs by type, the section says so.
Source of CA obligations: statements about what a public CA must do come from the CA/Browser Forum Baseline Requirements for Code Signing Certificates, version 3.11.0 (16 June 2026). Check your CA's own practice statement as well.

1. Scope and triggers

1.1 Triggers that open this playbook:

Trigger	Typical source	Severity
Malware found signed with an [Organisation] certificate	Anti-malware vendor, threat intelligence, customer report, CA notice	Critical
Private key file, PFX or HSM credentials exposed (repository, leak site, infostealer log)	Secret scanning, leak monitoring	Critical
Compromise of a build server, signing service or developer machine with signing access	EDR, SOC investigation	High until key use is ruled out
Signing log shows signatures that no release explains	HSM or signing service audit log	Critical
CA notifies [Organisation] of a certificate problem report	CA	High

1.2 Attackers both steal and buy signing certificates (MITRE ATT&CK T1588.003 Code Signing Certificates, T1552.004 Private Keys) to sign malicious code (T1553.002 Code Signing) or tampered updates (T1195.002 Compromise Software Supply Chain).

2. Roles and contacts

Role	Responsibility	Contact
Incident lead	Decisions, timeline, coordination	[Product security lead]
PKI or certificate owner	CA communication, revocation request, new certificate	[Name]
Release engineering	Signing logs, re-signing, rebuilding from clean source	[Name]
Security operations and forensics	How the key was obtained, other access	[SOC on-call]
Legal and communications	Customer advisory, regulator and contract notices	[Names]
Customer support	Scripted answers, upgrade help	[Name]
Certificate authority	Revocation and reissue; CAs must keep a 24x7 route for high-priority problem reports	[CA name, problem report address]
Platform vendors and anti-malware organisations	Blocklists, reputation, driver block rules	[Contacts, where agreements exist]

3. Detection and triage

Identify the certificate: subject, serial number, thumbprint, issuing CA, validity period, key storage (HSM, cloud KMS, signing service or file) and every product it signs.
Establish the exposure path: was the key itself copied, or was the signing service or HSM credential abused while the key stayed inside? A key held in a hardware crypto module, which the Baseline Requirements have required for publicly trusted code signing keys since 1 June 2023, is rarely exported; the signing interface and its credentials are the usual target.
Find the first bad signature. Compare signing logs against the release record. Every signature without a matching release is suspect. The earliest suspect signature, or the earliest moment the key or interface could have been accessed, becomes your proposed compromise date.
Collect samples: obtain hashes of malicious signed files from the reporter and search threat intelligence for the certificate serial and thumbprint.
Decide severity: confirmed malicious signatures or confirmed key copy is Critical; possible access without evidence of use is High with a 24-hour decision deadline.

4. Containment

4.1 Stop further signing

Disable the key in the HSM or KMS, or suspend the signing service, and revoke the credentials that could call it (CI secrets, service accounts, API tokens, operator accounts).
Freeze releases signed with that certificate until a new certificate is in place.

4.2 Request revocation and choose the revocation date

The Baseline Requirements oblige a subscriber to stop using the certificate and promptly request revocation once the key is compromised or misused, and oblige the CA to revoke within 24 hours of a written request, of evidence of key compromise, or of reasonable assurance the certificate signed suspect code. For key compromise and suspect code, the CA decides the revocationDate from its own investigation and may set a historic date. Timestamped code signed before that date should continue to validate, so the date you evidence decides which releases survive.

Revocation date option	Effect	When to choose it
Backdated to the first suspect signature or earliest possible access	Malicious files signed after that date fail; legitimate timestamped releases before it keep working	Default, when signing logs give a reliable compromise date
Backdated to certificate issuance	Every signature with the certificate fails, including all legitimate releases	No reliable logs, or malicious signatures timestamped early; plan mass re-signing first
Date of revocation (now)	Malicious files already signed and timestamped remain valid	Rarely appropriate for key compromise; only if no malicious signatures exist

Two caveats apply. Signatures without a timestamp become invalid when the certificate expires anyway, according to Microsoft's Authenticode documentation, and an attacker with the key may also have used a timestamp authority, so the timestamp alone does not prove a file is legitimate. Revocation checking also varies by platform and by whether clients are online. Do not rely on revocation alone to stop malicious files.

4.3 Block what revocation does not

Submit malicious hashes and the certificate to anti-malware vendors; the CA may also notify platform vendors, which the Baseline Requirements require when an application software supplier asks.
Inside [Organisation], deploy application control rules (for example Windows App Control for Business deny rules on the certificate or file hashes) and EDR blocks.
For kernel drivers, check whether Microsoft's vulnerable driver blocklist, which covers drivers with malware-signing certificates, has added the certificate, and push your own block rule meanwhile. The NVIDIA code-signing certificates stolen in 2022 had expired yet were still accepted for driver signing, which is why Microsoft pointed defenders to App Control policies rather than revocation.

5. Eradication

Close the access path: rebuild compromised build agents and developer machines, rotate every credential they held, and review who could call the signing service.
Verify source and pipeline integrity: confirm no malicious changes to source, build scripts or dependencies before anything is re-signed. Rebuild from verified source rather than re-signing existing binaries where integrity is in doubt.
Issue a new certificate on a new key generated in an HSM or managed signing service. Do not re-key in place under the same subscriber account until the account's own credentials have been reset.
Treat the signing identity as a non-human identity: restrict which pipeline identities can request signatures, require approval for release signing, and log every signing request with the requesting identity and artefact hash. See the Cryptographic Key Management Guide.

6. Recovery

Decide what to re-sign: every supported release whose signature will fail under the chosen revocation date, plus installers and updaters that check signatures on download.
Re-sign with the new certificate and an RFC 3161 timestamp, and publish new versions. AnyDesk shipped a release under a new certificate and told users that earlier builds were signed with the revoked one. See the AnyDesk Breach 2024.
Update pinned trust: auto-updaters, configuration management and customer allow-lists that pin the old certificate or thumbprint need the new one before the old one fails.
Expect reputation effects: a new certificate may initially trigger reputation warnings on some platforms. Warn support teams and customers.
Rollback: if a re-signed release fails, roll back to the previous re-signed version, never to binaries signed only with the revoked certificate.

7. Communication and notification

Customer advisory: what happened, the certificate serial and thumbprint, the cut-off date, which versions to upgrade from and to, how to verify a genuine file, and the hashes of known malicious files.
Enterprise customers: direct notice to administrators who maintain allow-lists or application control rules based on the old certificate.
Regulators and contracts: legal assesses obligations under contracts, sector rules and, if personal data or customer systems were affected, breach notification law.
Portal and account hygiene: if customer-facing systems were also reached, reset customer credentials as AnyDesk did for its portal.
Industry: the Baseline Requirements allow a CA to share information about certificates revoked for key compromise with other CAs and industry groups; expect this and keep statements consistent.

8. Post-incident review

Record time from first suspect signature to detection, detection to revocation request, request to CA revocation, and revocation to re-signed releases. Review whether signing logs were complete enough to backdate safely, whether signing could be requested by too many identities, and whether short-lived or keyless signing (see the Sigstore Guide) would have reduced impact.

Implementation guidance

Preparation that decides the outcome

Keep an inventory of every signing certificate: CA, serial, key location, products, owners and expiry.
Keep tamper-evident signing logs (artefact hash, requester identity, time, timestamp authority) for the life of the certificate.
Use separate certificates for separate product lines or driver and application signing, so one revocation does not break everything.
Rehearse the revocation date decision once a year with real logs.

Evidence to preserve

HSM, KMS or signing service audit logs for the whole certificate lifetime, exported before any key is disabled or deleted.
Copies and hashes of every malicious signed file, with the reporter and date received.
All correspondence with the CA, including the revocation request, proposed compromise date and the evidence supplied.
Build server, CI and developer machine images or forensic copies from the systems that could reach the key.

Small and large organisations

Small vendors: one certificate, often in a cloud signing service. Priorities: protect the service account, log every signature, and have the CA's problem report address in this playbook.
Large vendors: multiple certificates, internal signing CAs and platform-specific keys. Priorities: per-product certificates, approval workflows, and pre-agreed contacts at platform vendors.

Metrics

Percentage of signing certificates with complete signing logs.
Number of identities able to request a production signature, per certificate.
Time from compromise detection to revocation request (target under [4 hours]).
Time from revocation to re-signed releases for all supported versions.

Framework mapping

Framework	Reference
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management, SC-17 Public Key Infrastructure Certificates, CM-14 Signed Components, SI-7, IR-4
NIST CSF 2.0	RS.MI-01, RS.MI-02, RS.CO-02, RS.CO-03
MITRE ATT&CK v20	T1588.003, T1552.004, T1553.002, T1195.002

Compromised Code Signing Certificate Playbook: Revoke, Re-sign and Notify Without Breaking Customers