Siemens PLC key exposure shows the cost of hardcoded secrets

At a glance

What this is: This is an industrial cybersecurity case study showing how a hardcoded global private key can turn one cryptographic weakness into device-wide compromise.

Why it matters: It matters because identity and secrets teams need to treat embedded credentials, key reuse, and rotation gaps as governance failures that can expand blast radius across NHI, workload, and operational technology environments.

👉 Read Entro Security's analysis of the Siemens PLC private key vulnerability

Context

A hardcoded private key creates a trust problem, not just a technical defect. When the same secret is embedded across many industrial devices, one exposure can invalidate the security boundary for every system using that key, which is why secrets governance belongs in the identity programme, not only in product engineering.

This Siemens PLC case is a classic example of secrets sprawl meeting lifecycle failure. The issue is not merely that a key existed, but that it was shared across devices and could not be treated as a unique, revocable identity artefact.

Key questions

Q: What breaks when hardcoded secrets are reused across industrial devices?

A: Reused secrets collapse device trust into a single failure domain. If one private key is exposed, attackers can impersonate multiple devices, decrypt protected traffic, and potentially install malicious firmware across the fleet. The result is not a local incident but a scalable compromise of identity, integrity, and operational control.

Q: Why do shared device keys increase operational risk in OT environments?

A: Shared device keys make revocation and containment far harder than in systems with unique identities. Industrial environments often have long device lifecycles, so one compromised key can remain useful for years unless the organisation has a clear replacement and rotation strategy. That creates persistent exposure, especially where devices cannot be patched quickly.

Q: How can security teams tell whether embedded secrets are actually governable?

A: An embedded secret is governable only if it can be inventoried, rotated, revoked, and replaced without breaking the system. If the answer depends on vendor-specific firmware changes or a full hardware refresh, the secret is effectively permanent and should be treated as an unmanaged trust root.

Q: Who is accountable when a hardcoded private key causes device compromise?

A: Accountability usually spans product engineering, security architecture, procurement, and vendor management. The failure is rarely just operational, because the trust model was embedded before deployment and then left without a viable offboarding path. Frameworks such as OWASP NHI and NIST CSF help teams assign ownership for secret lifecycle controls.

Technical breakdown

Why hardcoded private keys break device trust

A private key is supposed to prove that a device or service is legitimate. When that key is hardcoded into a product line, the trust model collapses because every instance shares the same cryptographic root. In the Siemens case, researchers reported that the key could be extracted and then used to decrypt protected communications, manipulate configurations, and impersonate trusted devices. That turns cryptography from a control into a single point of failure. In identity terms, the secret is no longer an isolated credential but a reusable bearer of device trust.

Practical implication: inventory any embedded or shared keys and treat them as high-risk identities, not static configuration.

How memory-protection bypasses expose protected secrets

The article describes a chain in which a prior vulnerability was used to bypass native memory protections and reach protected areas containing keys and code. That matters because secrets are often assumed to be safe once placed in hardware or protected memory, yet the protection still depends on the surrounding software and access controls. If an attacker can gain read and write access to those regions, the key material becomes extractable regardless of where it was stored. Hardware-backed trust only helps when the access path to the secret is equally hardened.

Practical implication: review whether protected storage is actually isolated from the code paths that can read or alter it.

Why reusable secrets create persistent control over industrial devices

Once a global key is exposed, the attacker does not need to compromise each device separately. They can leverage the same trust artefact to install malicious firmware or persistently execute code across affected models. That is why this pattern is especially dangerous in operational technology, where long-lived devices often outlive the assumptions made when their credentials were first designed. The risk is not only initial access but durable control over a fleet. In NHI terms, the problem is a credential that was never meant to be shared behaving like a universal identity.

Practical implication: eliminate shared device credentials where possible and segment trust so one compromise cannot cross models or sites.

Threat narrative

Attacker objective: The attacker aims to gain durable, device-level control over industrial PLCs by abusing a reusable trust root.

1. Entry occurred through exploitation of a prior Siemens PLC vulnerability that allowed access to protected memory areas.
2. Credential access followed when researchers extracted global private keys from the SIMATIC S7-1500 devices.
3. Impact could include malicious firmware installation, protected communication decryption, and persistent control of affected industrial devices.

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

Hardcoded global keys are a lifecycle failure, not just a coding flaw. A shared private key was designed for a world where device trust could be simplified across models and where revocation pressure was low. That assumption fails when the same identity artefact is copied into hundreds of devices and becomes impossible to retire without systemic impact. The implication is that key lifecycle governance must be treated as part of product trust architecture, not as an afterthought.

Identity blast radius is the real control metric in industrial environments. This incident shows that the question is not whether a key is protected in storage, but how far that key can reach if exposed. A reusable device key turns one compromise into fleet-wide authentication failure, which is why standing trust roots are more dangerous than isolated credentials. Practitioners should measure how much device identity collapses behind one secret.

Embedded secret trust debt: the longer a key remains hardcoded and reusable, the more security debt accumulates in the environment that depends on it. The debt is not abstract. It shows up as impossible rotation, brittle upgrade paths, and dependence on memory or firmware protections that attackers can sometimes bypass. The practical conclusion is that industrial identity programmes must identify where trust is still anchored to non-revocable secrets.

Industrial NHI governance needs to cover devices that were never designed like modern workloads. PLCs, controllers, and similar equipment may not fit the same control patterns as cloud service accounts, but the governance problem is the same: who or what is trusted, for how long, and with what revocation path. When the answer is “for the life of the device,” the environment has already accepted excessive identity risk. That should trigger remediation planning, not reassurance.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• In the same research, 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• For lifecycle-focused follow-up, read NHI Lifecycle Management Guide for the governance controls that make secrets revocation and ownership traceable.

What this signals

Embedded trust roots are becoming an enterprise governance problem, not just an OT engineering problem. As more industrial systems, workloads, and integration points depend on long-lived secrets, the cost of treating those secrets as immutable grows quickly. Teams should look for places where a key or certificate cannot be rotated without vendor intervention, because that is where identity risk becomes operational debt.

The pattern here also reinforces a broader secrets-management reality. With 91% of former employee tokens remaining active after offboarding in our research, lifecycle control is still failing even in less complex environments, which means industrial teams should expect the same weakness to be worse where devices are harder to change.

That is why the next step is not more confidence in hardware protection alone, but tighter governance over secret creation, ownership, rotation, and retirement. The same discipline that applies to service accounts and workload identity has to extend to industrial devices if organisations want to shrink identity blast radius.

For practitioners

• Map all embedded device trust roots Identify hardcoded keys, shared certificates, and factory-set secrets across industrial devices, firmware, and adjacent management tooling. Classify which secrets are unique, which are reused, and which cannot be rotated without vendor support.
• Measure the blast radius of a single key leak Document which device models, sites, and communication paths rely on the same cryptographic material. Use that map to prioritise isolation, segmentation, and replacement of the highest-impact shared identities first.
• Require revocation paths for long-lived device identities Do not accept secrets that cannot be rotated, revoked, or replaced without a full product refresh. Build procurement and engineering requirements around recoverability, not just secrecy.
• Separate hardware protection from trust assumptions Validate whether secure elements, memory protections, and firmware boundaries actually prevent extraction or reuse of the underlying key. If the surrounding software can still expose the secret, the control is not sufficient on its own.

Key takeaways

• The Siemens PLC case shows that a hardcoded global key can turn one exposure into fleet-wide device compromise.
• The evidence points to a much larger trust problem, because reusable secrets and protected-memory assumptions can fail together.
• Practitioners should prioritise secret uniqueness, revocation, and lifecycle control before accepting embedded trust roots as safe.

Key terms

• Hardcoded Private Key: A hardcoded private key is a secret built into software or firmware rather than issued and managed dynamically. In practice, it creates a fixed trust root that is difficult to rotate, revoke, or isolate, which makes every device using it vulnerable if the key is discovered.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, or devices exposed when one credential or trust artefact is compromised. For non-human identities, the metric matters because a shared secret can turn one exposure into a fleet-wide or platform-wide security failure.
• Embedded Trust Root: An embedded trust root is a secret or cryptographic anchor that product design treats as foundational to device authentication. When that root is shared or non-revocable, it becomes a structural risk because compromise undermines all higher-level security controls built on top of it.

What's in the full article

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

• Claroty's vulnerability analysis and the specific CVE references tied to Siemens PLCs
• The technical explanation of how protected memory was bypassed to extract the private keys
• Entro Security's product-oriented walkthrough of secrets discovery, enrichment, and anomaly detection
• The vendor's interpretation of how hardcoded keys affect industrial secrets management at scale

👉 The full Entro Security post covers the exploit path, the PLC models affected, and the secrets-management response.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.