Notifications
Clear all
Topic starter
25/06/2026 5:07 pm
TL;DR: Claroty’s analysis of Siemens PLCs showed how a hardcoded global private key could enable firmware tampering, protected-communication bypass, and persistent device control across more than 100 vulnerable models. The case shows why industrial secrets management must treat key uniqueness, lifecycle control, and device trust as a governance issue, not just a cryptography problem.
NHIMG editorial — based on content published by Entro Security covering the Siemens PLC vulnerability: a deep dive into industrial cybersecurity
Questions worth separating out
Q: What breaks when hardcoded secrets are reused across industrial devices?
A: Reused secrets collapse device trust into a single failure domain.
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.
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.
Practitioner guidance
- Map all embedded device trust roots Identify hardcoded keys, shared certificates, and factory-set secrets across industrial devices, firmware, and adjacent management tooling.
- Measure the blast radius of a single key leak Document which device models, sites, and communication paths rely on the same cryptographic material.
- Require revocation paths for long-lived device identities Do not accept secrets that cannot be rotated, revoked, or replaced without a full product refresh.
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
👉 Read Entro Security's analysis of the Siemens PLC private key vulnerability →
Hardcoded PLC keys: what identity teams need to fix first?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:38 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Siemens PLC key exposure shows the cost of hardcoded secrets
