If you suspect a code signing key is stolen, stop all signing, tell the certificate issuer so they can revoke it, work out what was signed with it, and prepare a clean release under a new identity. Tell users early and plainly. Speed matters because signed malware looks legitimate until the certificate is revoked.
Hour one: contain
- Disable access to the key or signing service. Pause pipelines that can request signatures.
- Preserve logs, including signing request logs, access logs and the machine images involved.
- Name an incident lead and open a private channel.
- Contact the issuing CA to report a compromised key and ask for revocation. Follow their process, and keep the confirmation.
Hours two to eight: scope
Answer these questions.
- When could the key have been taken? Use the earliest plausible date.
- What did you legitimately sign since then? List every release and hash.
- Is there any signature you do not recognise? Search public malware sources and your own telemetry for files signed with your identity that you did not publish.
- How did the key leak: a build server, a laptop, a token left in a drawer, an insider? Fix the cause or the next key goes the same way.
Why timestamps matter here
A timestamped signature records that the file existed at a given time. That helps separate releases signed before the compromise from files signed after it. Windows verification via SignTool also considers whether the certificate has been revoked. This is why you want timestamps on every release, and why your records of what you signed matter.
Day one: recover
- Obtain a new certificate and store the key properly. See where to keep signing keys.
- Rebuild from a clean environment and sign the next release with the new identity.
- Update your download page, hashes and verification steps.
- If you use apps that update themselves, plan how clients learn to trust the new identity. Your updater design decides how hard this is.
- For Android, a signing key tied to an app identity is harder to replace. Read about key rotation in APK signature schemes.
Tell people
Publish a short notice: what happened, what you know, which versions are affected, what users should do and where to get the clean build. Avoid guessing. Say what you do not yet know and when you will update. The general checklist in what a key compromise plan should include pairs well with this runbook.
Afterwards
Hold a blameless review. Add the missing control, usually restricted signing access, logging, or hardware storage, and test the runbook on a calm day.
Practise it
Run a tabletop exercise once a year. Give the team a scenario: a build agent image was copied, and a signed file you did not build appears on a malware feed. Time how long it takes to reach the CA, list what you signed, and publish a notice. Gaps found in a rehearsal cost nothing compared to gaps found during a real theft.
Quick check
Should we keep signing with the old key while the CA processes revocation?
No. Stop signing at once. Any new signature widens the set of files you must vouch for.
Do old timestamped releases become untrusted?
That depends on the platform and the revocation date. Keep records, and re-sign if you can.
Sources
Last reviewed: 19 October 2026.
