Signing keys and certificates in breaches: What eleven incidents teach about protecting trust keys

A stolen signing key does not open one door, it lets an attacker manufacture trust that every downstream system accepts without question. Code signing certificates, SAML token-signing certificates, cloud token-signing keys, firmware keys, GPG release keys, ASP.NET machine keys and GitHub App private keys all behave the same way in a breach: whoever holds the private key can make forged software, tokens or tickets look genuine. NHI Mgmt Group's breach analysis counts signing keys or certificates among the identities abused in 31 breaches. This guide pulls the cross-breach lessons from eleven of those incidents and turns them into controls, a rollout order and the measures that show the risk is falling. It is written for PKI owners, platform and release engineers, identity architects and incident responders.

Key takeaways

• Signing keys are tier-zero non-human identities. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) lists signing key or certificate as an abused identity type in 31 of more than 200 breaches, and says of SolarWinds that build systems, signing keys and federation certificates each need an owner, tight scope and monitoring.
• Where the key lives decides the outcome. Keys in CI environment variables, on developer laptops, in repositories or in crash-dump-reachable memory were the root of HashiCorp, Coupang, GitHub and Storm-0558. Non-exportable keys in an HSM or managed signing service remove most of these paths.
• Validation failures matter as much as theft. Storm-0558 worked because Exchange Online accepted a consumer key for enterprise tokens, and Coupang's forged tokens were never checked against issuance events. Verifiers need scope, issuer and lifetime checks.
• Revocation is expensive, so plan it before you need it. AnyDesk, GitHub and NVIDIA show that revoking a long-lived certificate breaks legitimate releases or is not done at all. Per-product keys, timestamping and a release-to-key map make revocation survivable.
• Patching does not revoke a stolen key. ToolShell attackers kept access after SharePoint was patched because machine keys had been taken. Every host compromise needs a key rotation step.

What the breach data shows

The report classifies each breach by attack route and identity type. Signing key or certificate appears 31 times as an identity type, behind secrets, cloud credentials, API keys, source control tokens and CI/CD tokens, but the blast radius per incident is larger: one key can vouch for software on thousands of customer machines or mint tokens for any mailbox. The report also finds that 56% of breaches involved more than one kind of non-human identity, and signing keys are usually the second or third credential in a chain, reached after a token, a vault or a build account fell first. The report's SolarWinds entry is the clearest example: up to 18,000 customers received the backdoor, 9 federal agencies and about 100 companies were compromised, and the identities abused were build and code-signing trust, SAML token-signing certificates and service principal credentials.

Eleven incidents, grouped by key type

For the federation side of SolarWinds, the Mimecast certificate compromise shows the same pattern from a vendor: a certificate used to authenticate to customers' Microsoft 365 Exchange Web Services was stolen, and every affected customer had to delete the connection and re-create it with a replacement certificate.

Five cross-breach lessons

1. Storage location is the real control

In HashiCorp the key was an environment variable in a pipeline that ran a third-party script. In Coupang it sat on developer computers. In GitHub it was in cloned repositories, protected only by a password. Microsoft's post-incident review for Storm-0558 says key material should not leave the production environment and describes fixes to crash dump handling and credential scanning. The common fix is a non-exportable key in hardware: the CA/Browser Forum Baseline Requirements for Code Signing Certificates (v3.11.0) have required subscriber code signing keys to be generated, stored and used in a suitable hardware crypto module since 1 June 2023. Apply the same standard to keys no CA polices: token-signing, GPG, firmware and App keys.

2. Lifetime without rotation turns a leak into a permanent door

The Storm-0558 key was created in 2016 and should have been retired in March 2021; consumer key rotation was manual and stopped after an outage, with no alert for old active keys. Coupang's keys reportedly had validity periods of 5 to 10 years. GitHub App private keys never expire. Set a cryptoperiod for every key type (NIST SP 800-57 Part 1 Rev. 5 is the reference for doing this), automate rotation and alert when a key outlives it.

3. Verifiers must check more than the signature

Storm-0558 succeeded because libraries did not validate key scope and the mail system's developers assumed they did. Microsoft has since shipped libraries that automate key scope validation. Coupang's systems did not verify that tokens mapped to real issuance events. A relying party should check issuer, audience, key identifier, key scope and token lifetime, and high-value services should reconcile tokens against issuance logs.

4. Revocation needs a plan before the incident

AnyDesk's revoked certificate covered every release before 7.0.15 and 8.0.8. GitHub's revocation broke specific Desktop and Atom versions. NVIDIA's certificates were not revoked because that would have blocked legitimate drivers, so Microsoft advised Windows Defender Application Control policies instead. MSI's Boot Guard keys are built into devices in the field. Keep a map of which releases each key signed, timestamp signatures so revocation can be dated, and split keys by product and environment so one revocation does not break everything. The Compromised Code Signing Certificate Playbook covers the response steps.

5. Key theft is a post-compromise step, so rotation belongs in every response

ToolShell attackers took machine keys after the initial exploit; SolarWinds attackers took the token-signing certificate after gaining on-premises admin; Mimecast's certificate was reached through the SUNBURST backdoor. Microsoft's guidance for systemic identity compromise is to replace the AD FS token-signing certificate fully, including updating the cloud side so the old certificate can no longer authenticate users, and to review audit logs for added service principal credentials. If a host that could read a key was compromised, treat the key as stolen.

Controls by key type

For the underlying disciplines see the Code Signing Security Guide, the Golden SAML and Federation Trust Abuse Defence Guide, the HSM Deployment and Operations Guide and the Firmware and Boot Security Guide.

Implementation: a phased approach

1. Inventory (weeks 1 to 2): list every private key that signs something others trust: code signing, federation, JWKS, GPG, firmware, machine keys, GitHub Apps, SSH host keys. Record owner, location, creation date, algorithm, what it signs and which systems verify it. The Machine Identity, PKI and Certificate Lifecycle Guide describes the fields.
2. Find exposed copies (weeks 1 to 3): scan repositories, CI variables, container images, file shares and developer endpoints for key files and PFX or PEM material. Treat any copy outside the approved store as compromised and schedule its rotation.
3. Move to non-exportable storage (weeks 3 to 8): start with keys whose compromise affects customers (code signing, federation, release keys). Pilot one product's signing through a managed signing service before moving the rest.
4. Rehearse rotation (weeks 6 to 10): run a test rollover for each key type in a staging environment, including relying parties and clients that pin the key. Keep the old key available for rollback until verifiers confirm the new one, then remove it completely, as Microsoft's AD FS guidance stresses.
5. Harden verifiers (weeks 8 to 12): confirm issuer, audience and key scope checks in token validation libraries; enable signature verification in consumers of your releases.
6. Wire into incident response and offboarding: add "rotate reachable signing keys" to host compromise playbooks and to leaver processes for engineers with signing access. See the NHI Offboarding and Decommissioning Guide.

Decision guidance

• HSM versus managed cloud signing: on-premises HSMs suit firmware and offline root keys that need ceremonies and dual control; cloud KMS or managed signing suits high-volume code and token signing. Small teams rarely need their own HSM for code signing.
• Keyless or identity-bound signing: short-lived certificates bound to a workload identity remove the long-lived key altogether for open source and internal artefacts. Keep a conventional key where platforms require it, such as Windows Authenticode and secure boot.
• Revoke or block: revoke when the CA and platform support dated revocation and you can re-sign affected releases; block by certificate or hash with application control when revocation would break widely deployed legitimate software, as in the NVIDIA case.
• Large organisations: run a central signing service with approval workflows and per-team keys. Smaller teams should at least remove keys from CI variables and repositories and assign a named owner.

Detection and measurement

Log every signing operation with requester, artefact hash and pipeline run; alert on signing outside tagged releases or approved pipelines. In Entra ID and other IdPs, alert on new credentials added to applications and service principals (the SolarWinds pattern). Monitor mail and data access logs where available: the State Department caught Storm-0558 through a custom alert on MailItemsAccessed events.

Common failure patterns

• Rotation stopped after an outage: Storm-0558's manual rotation lapsed in 2021 and nobody was alerted. Automate it and alert on overdue keys.
• Keys in CI variables next to third-party tools: HashiCorp's GPG key was harvested by a tampered uploader script.
• Leavers keep keys: Coupang's former engineer used a key that was never rotated after departure.
• Treating expiry as safety: NVIDIA's expired certificates still signed accepted drivers.
• Patching without rotating: ToolShell persistence survived the patch because machine keys were already stolen.
• Forgotten keys that never expire: the 474 working GitHub App keys included some leaked in 2020.

Framework mapping

Practitioner checklist

• Inventory every signing key and certificate with owner, location, age, what it signs and who verifies it.
• Remove key material from repositories, CI variables, images, shares and laptops; rotate anything found.
• Move customer-facing signing keys into an HSM or managed signing service as non-exportable keys.
• Define a cryptoperiod per key type, automate rotation and alert on keys that outlive it.
• Keep a release-to-key map, timestamp signatures and split keys by product line.
• Check issuer, audience and key scope in every token validation path.
• Alert on new credentials added to applications and on signing outside approved pipelines.
• Add signing key rotation to host compromise playbooks and engineer offboarding.
• Rehearse a full rollover for each key type at least yearly.

Standards and references

• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1, General
• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Code Signing Certificates
• Microsoft MSRC: Results of Major Technical Investigations for Storm-0558 Key Acquisition
• Microsoft Security: Advice for incident responders on recovery from systemic identity compromises
• MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates
• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)

Related NHI Mgmt Group resources: Code Signing Security Guide · Golden SAML and Federation Trust Abuse Defence Guide · Cryptographic Key Management Guide · Non-Human Identity (NHI) Guide