MSI breach exposes why leaked code signing keys break trust

At a glance

What this is: This is an analysis of the MSI ransomware breach and the exposure of private code signing keys that could undermine firmware trust across hundreds of products.

Why it matters: It matters because firmware signing keys are privileged non-human identities in practice, and their leakage turns a single compromise into a broad integrity and supply-chain problem for IAM, PAM, and lifecycle governance teams.

By the numbers:

• 57 products and Intel Boot Guard keys for

👉 Read Entro Security's analysis of the MSI breach and leaked signing keys

Context

Leaked signing keys are not just stolen secrets. They are trust credentials that let software or firmware present itself as genuine, which makes them a direct identity governance issue for machine identities and software supply chains. When those keys escape, the control problem is no longer limited to containment of a ransomware event; it becomes a question of whether signed code can still be trusted at all.

In MSI’s case, the breach sits at the intersection of secret management, firmware integrity, and downstream device trust. That is typical of modern NHI risk: one compromised secret can alter the security posture of many systems at once, especially when the secret cannot be revoked cleanly.

For identity and security teams, the useful lesson is that secrets embedded in build, signing, or update workflows behave like privileged identities even when no person is directly involved. The governance model has to account for issuance, storage, use, and retirement, not just for authentication at the perimeter.

Key questions

Q: How should security teams protect code signing keys used for firmware and software updates?

A: Treat code signing keys as tier-0 secrets with tightly scoped access, strong segregation of duties, and continuous monitoring of signing events. Store them in hardened vaults or HSM-backed workflows, and keep issuance, use, and retirement under separate governance so compromise does not translate into broad trust abuse.

Q: Why do leaked signing keys create a bigger problem than ordinary secret exposure?

A: Leaked signing keys can let malicious code appear legitimate to devices, update tools, and boot chains. That means the attacker is not just stealing access. They are inheriting trust. The result is a supply-chain integrity problem that may persist even after the initial breach is contained.

Q: What breaks when firmware trust anchors cannot be revoked cleanly?

A: When a signing key cannot be revoked quickly or completely, the organisation may have to keep defending products that still trust the exposed credential. That extends the blast radius, complicates incident response, and forces compensating controls or product retirement decisions long after disclosure.

Q: Who should own the risk when a firmware signing key is exposed?

A: Ownership should sit with the teams responsible for identity governance, platform security, and product integrity together. The breach spans secrets management, update delivery, and customer trust, so accountability cannot stay inside one engineering function or one incident-response team.

Technical breakdown

How code signing keys become trust anchors

Code signing keys are cryptographic credentials that attest a firmware or software package is genuine. Devices and boot chains verify the signature before execution, so the key effectively controls whether code is trusted by default. In MSI’s case, the disclosed keys were tied to firmware and Intel Boot Guard, which means they sat inside a root-of-trust path rather than a normal application boundary. Once exposed, attackers do not need to break the device directly; they can abuse the signing process itself.

Practical implication: treat signing keys as high-value NHI secrets and keep them isolated from general-purpose systems.

Why revoked keys are a special governance problem

Some trust credentials can be rotated, but firmware signing keys often have long-lived effects and limited revocation options. That creates a persistence problem: even after the incident is contained, any product line that trusted those keys may need compensating controls, vendor coordination, or product retirement decisions. This is different from ordinary secret leakage because the damage is not just access. It is continued trust in artefacts that may be maliciously signed and still accepted by devices.

Practical implication: map which keys cannot be cleanly revoked and pre-plan compensating controls for those trust domains.

How ransomware turns into supply-chain exposure

The ransomware event mattered because the attackers reportedly obtained sensitive files, then leaked them when ransom demands were not met. In a normal data theft, the end state is disclosure. In a signing-key theft, disclosure can become impersonation, persistence, and distribution at scale. The attack path crosses from enterprise compromise into the broader supply chain because malicious firmware can be delivered through legitimate update processes and appear authentic to downstream systems.

Practical implication: align incident response with software integrity monitoring, not only data-loss containment.

Threat narrative

Attacker objective: The attacker objective is to turn stolen trust credentials into signed malware or malicious firmware that devices accept as legitimate.

1. Entry occurred through a ransomware intrusion that gave the attackers access to MSI systems and sensitive files.
2. Credential abuse followed when private code signing keys and Boot Guard keys were exposed alongside other proprietary materials.
3. Impact would come from malicious firmware or software signed with trusted keys, allowing attacker-controlled code to pass normal verification paths.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code signing keys are privileged non-human identities, not just encryption material. Their value lies in delegated trust, because they authorize software or firmware to be accepted as authentic. When those keys are stored like ordinary secrets, the organization underestimates both blast radius and lifecycle risk. Practitioners should classify signing credentials alongside the highest-risk NHI assets, not as ordinary build artefacts.

Trusted signing without effective revocation creates identity blast radius. The MSI case shows that when a trust anchor cannot be revoked cleanly, one breach can outlive the incident response window by months or years. That is not only a control gap. It is a structural governance problem in which one credential can continue to validate artefacts long after the breach is over. Practitioners need to govern for persistence, not just disclosure.

Secret storage and device trust must be managed as one lifecycle. The breach exposed how build, signing, and update processes are part of the same identity chain. A secret vault alone does not solve the problem if the signing workflow still permits broad access, weak segregation of duties, or poor monitoring around who can sign what. Practitioners should review the full issuance-to-retirement chain for every high-trust credential.

Firmware supply chains expose a control gap that conventional IAM often misses. IAM teams usually focus on interactive access, but MSI demonstrates that machine trust can be compromised through keys embedded in operational pipelines. That widens the scope of identity governance into software integrity, update channels, and product trust. Practitioners should treat firmware and update signing as part of identity security, not a separate engineering concern.

From our research:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• For the broader secret-sprawl risk pattern, see Guide to the Secret Sprawl Challenge for how discovery, vaulting, and governance fit together.

What this signals

Identity blast radius: when a single signing key can affect dozens or hundreds of products, governance has to shift from account-level oversight to trust-anchor lifecycle control. Teams that still separate secrets management from product integrity will miss the real exposure surface.

If your programme cannot tell which keys are revocable, which are embedded in release pipelines, and which validate downstream trust, then you do not have adequate control visibility. That gap will matter more as software delivery, device boot, and secrets governance continue to converge.

The practical signal is to build a joint review path for platform security, IAM, and product engineering. When trust credentials are treated as lifecycle-managed identities, organisations can reduce persistence after compromise instead of reacting to every leak as a one-off event.

For practitioners

• Classify signing keys as tier-0 secrets Inventory every code signing, boot, and update key, assign an owner, and place them under the strictest secrets governance with segmented access and monitored use.
• Separate signing authority from routine engineering access Restrict who can generate, access, or use firmware signing material so the same operators who build software do not automatically control the trust anchor.
• Map revocation limits before an incident Document which keys can be rotated, which cannot, and which products would need compensating controls or retirement if a trust anchor is exposed.
• Monitor signed artefacts for trust-chain misuse Add controls that alert on unexpected signing activity, unusual update timing, and suspicious artefacts appearing in legitimate firmware distribution paths.

Key takeaways

• The MSI breach matters because exposed signing keys turn a ransomware event into a trust-chain problem.
• The scale is material because the leaked credentials covered 57 firmware products and 116 Intel Boot Guard-protected products.
• The control that changes the outcome is lifecycle governance for signing keys, including segregation, revocation planning, and trust-chain monitoring.

Key terms

• Code Signing Key: A code signing key is a cryptographic secret used to prove that software or firmware came from a trusted source and has not been altered. In identity terms, it is a delegated trust credential with high blast radius because anything signed with it may be accepted as authentic by downstream systems.
• Boot Guard Key: A Boot Guard key is a hardware-rooted trust credential used to verify firmware or boot components before a device starts normally. It protects the chain of trust at startup, which makes exposure especially serious because misuse can affect integrity before operating-system controls load.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential, account, or trust anchor can cause if abused or leaked. For machine identities and signing keys, the blast radius often extends beyond one system into devices, update paths, and downstream customers.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• The exact MSI product and firmware trust chains discussed in the breach analysis
• The vendor's explanation of how leaked keys could be used to sign malicious firmware
• The specific remediation advice the article gives to developers and IT admins
• The original screenshots and source references used to support the breach narrative

👉 The full Entro Security post covers the breach narrative, the leaked key types, and the trust-chain implications in more detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.