Static Passwords, Hardcoded Keys, and Weak Cryptography: A Persistent Pattern in OT Products

During a security assessment, we discovered an insecure password encryption vulnerability (CVE-2024-52334) in Siemens Healthineers syngo.plaza VB30E, a medical imaging archiving system deployed in hospitals. The vulnerability allows an attacker to recover original passwords from insufficiently encrypted storage with a static key, potentially gaining unauthorized access to medical records.  

Discovered Vulnerability

Siemens Healthineers has released hot fix HF07 addressing the issue. Operators running affected versions should update following the vendor’s guidance.

Siemens Healthineers Security Advisory: SSA-016040 

While this specific finding is relatively straightforward, it is part of a much larger and long-standing pattern across operational technology (OT) and embedded products: the use of static passwords, hardcoded cryptographic keys, and weak or broken cryptographic implementations. This blog post uses our finding as a starting point to explore that pattern, the reasons behind it, and why the regulatory landscape, particularly in Europe, is about to make these practices a serious liability. 

The Finding: Weak Password Encryption in syngo.plaza

The vulnerability is classified as CWE-261 (Weak Encoding for Password). syngo.plaza did not properly encrypt stored passwords, allowing an attacker with access to the relevant data to recover plaintext credentials. 

We reported the vulnerability through coordinated disclosure, and Siemens Healthineers addressed it with a hotfix. 

A Pattern, Not an Anomaly

This finding did not surprise us. Static passwords, hardcoded keys, and inadequate cryptographic protections have been a persistent issue across OT products for well over two decades. The problem is not limited to any single vendor or sector, it is an industry-wide pattern rooted in historical design decisions and the unique constraints of these environments.

Stuxnet and the hardcoded password that started a conversation

Perhaps the most prominent early example dates back to 2010: Siemens SIMATIC WinCC and PCS 7 used a hardcoded database password (CVE-2010-2772). The Stuxnet worm exploited this vulnerability among others to compromise systems in Iranian nuclear infrastructure. While Stuxnet was an exceptionally sophisticated attack, the hardcoded password it leveraged was an entirely ordinary design shortcut, one that had been openly discussed in Siemens user forums for years before it became world news through the Stuxnet attack campaign. 

S7CommPlus: The Long Road from Hardcoded Keys to TLS

A more instructive example is the evolution of cryptographic protections in the Siemens S7-1200/1500 PLC product line and its S7CommPlus communication protocol. This story, spanning over a decade of research, illustrates both how these practices emerge and how difficult they are to resolve. 

When Siemens introduced asymmetric cryptography to protect PLC communications and configuration with TIA Portal v12 roughly a decade ago, dynamic key management and distribution was not a practical option for most industrial control systems. The operational burden on integrators and plant operators was considered too high. Siemens opted instead for fixed, hardcoded cryptographic keys embedded in every device of the same product family. 

This design decision was understandable in context: it prioritised operational simplicity and backward compatibility, while still raising the bar compared to the entirely unprotected traditional S7Comm protocol that preceded it. But it also meant that every PLC of the same model shared the same private key. 

In 2019, researchers at the Technion (Israel Institute of Technology) demonstrated at Black Hat USA that the S7CommPlus handshake only authenticated the device family, not individual devices. They built a rogue engineering workstation that could impersonate TIA Portal and send commands to S7-1500 PLCs, including downloading rogue logic. As researcher Avishai Wool put it: “All PLCs of the same model have the same key, which means if you crack one, you’ve cracked all of them.” 

In 2022, Claroty’s Team82 took this further (CVE-2022-38465, CVSS 9.3). By exploiting a previously discovered remote code execution vulnerability (CVE-2020-15782) to gain native code execution on S7 PLCs, they extracted the global hardcoded private key directly from PLC memory. With this key, they could decrypt all protected communication between PLCs and engineering workstations, recover configured password hashes, conduct man-in-the-middle attacks, and implement a fully independent S7 client, without requiring TIA Portal at all. 

Siemens responded by overhauling the cryptographic architecture. TIA Portal v17 and corresponding firmware updates consequentially introduced state-of-the-art TLS-based communication and individual per-device passwords for configuration protection. This was a significant and commendable engineering effort, but it also illustrates the scale of remediation required when fundamental cryptographic assumptions turn out to be flawed. Operators worldwide must update both firmware  as well as engineering software, reconfigure device passwords, and migrate projects,  a multi-year effort in large installations.

Schneider Electric: Hardcoded Salts and Plaintext Protocols

This underlying issue certainly affects probably a large amount of traditional OT equipment verndors. In 2020 for instance, researchers found a hardcoded cryptographic salt in Schneider Electric’s EcoStruxure Machine Expert (CVE-2020-28214). Because the same salt was used for every installation, an attacker could brute-force application protection passwords offline once the hashing scheme was known. The hardcoded value was found by simply disassembling the .NET binary with a standard decompiler. 

In 2022, Forescout disclosed CVE-2022-46680 affecting Schneider Electric’s UMAS protocol, used by Modicon M340 and M580 PLCs. The protocol transmitted passwords in cleartext, a design choice dating back roughly 30 years. Schneider Electric worked closely with Forescout on a fix, a notable achievement given the age of the protocol, but the example underscores how legacy design decisions persist in production environments for decades. 

OT:ICEFALL, The Systemic View

Also in 2022, Forescout’s Vedere Labs published the OT:ICEFALL research resulting in 56 vulnerabilities across products from 10 major OT vendors, including Siemens, Honeywell, Emerson, Omron, and Yokogawa. More than a third of the reported vulnerabilities (38%) involved compromise of credentials, through plaintext storage, hardcoded credentials, or broken cryptographic implementations. 

The researchers’ key observation was significant: these were not obscure bugs, but fundamental design-level issues. Hardcoded passwords, lack of authentication, client-side authentication checks, and broken cryptographic schemes were recurring patterns across vendors and product lines. Perhaps most striking was that 74% of the affected product families held some form of security certification, as CISA noted when releasing corresponding advisories. The issues found should have been discovered relatively quickly during professional security evaluations including technical checks.

Why This Keeps Happening: Understanding the Motivations

It would be easy to simply blame vendors for poor security practices. The reality is more nuanced. Several factors have historically driven these design decisions in OT environments. 

Operational simplicity takes precedence. OT systems are operated by engineers and technicians, not IT (security) specialists. Complex key management, certificate infrastructure, and password policies create operational friction that can directly impact system availability. When a PLC needs to be replaced during an unplanned outage, a shared key that works immediately has clear appeal. When a field service engineer needs remote access to diagnose a fault, a hardcoded service password is operationally convenient. 

Long product lifecycles create inertia. OT products are designed for 15–25 year operational periods. Cryptographic best practices that were considered acceptable at design time may be outdated by deployment, and clearly inadequate a decade later. Retrofitting proper cryptography into fielded products, especially embedded systems with limited computational resources, is a significant engineering challenge. 

Backward compatibility constrains improvement. Many protocols and products must maintain interoperability with older devices. Introducing proper authentication or encryption often means breaking compatibility with the existing installed base, creating a painful transition period where old and new must coexist. The Schneider Electric UMAS protocol fix demonstrates both that it can be done and how long it can take. 

Security was historically deprioritised. For much of the history of industrial control systems, the operating assumption was that these systems would be air-gapped, physically isolated from untrusted networks. Under that assumption, investing heavily in product-level security made little economic sense. The convergence of IT and OT networks over the past two decades has thoroughly invalidated this assumption, but product development cycles in OT move slowly. 

None of these factors excuse the continued shipment of products with hardcoded credentials or weak cryptography in 2026. But understanding them helps explain why the problem is so entrenched, and why regulatory pressure is increasingly seen as necessary to drive change. 

The Regulatory Reckoning: CRA

For European operators and manufacturers, a regulatory framework is set to transform how these practices are assessed and penalized. 

EU Cyber Resilience Act (CRA)

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024, with mandatory reporting obligations applying from September 2026 and full compliance required by December 2027. The CRA introduces mandatory cybersecurity requirements for all “products with digital elements” placed on the EU market, a broad scope that covers industrial control system components, IoT devices, network equipment, and most commercial software. 

It requires that manufacturers must ensure that their products are designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. Amongst other requirements, a product must be placed on the market according to an evaluation of the risks,  without any known exploitable vulnerabilities, in a secure by default configuration, with a minimized attack surface as well as the confidentiality and integrity of data at rest and in transit are protected as required.  Moreover, security updates must be provided for free for the duration of the specified support period, guaranteeing that any later on identified exploitable vulnerabilities in the product can be patched if required.  

While it does not specifically prohibit the use of weak or default hardcoded passwords, considering the aforementioned requirements, it will be harder to defend such design choices. Hardcoding or not enforcing a change on default passwords, stands in contrast with secure by default and is a known exploitable vulnerability.  

The enforcement regime has teeth. Non-compliance with the essential cybersecurity requirements in Annex I carries penalties of up to €15 million or 2.5% of global annual turnover, whichever is higher. Products that fail conformity assessment lose EU market access entirely. IoT devices shipping with hardcoded or unchangeable default passwords are explicitly cited as examples that would trigger the highest tier of penalties. 

For manufacturers of OT products, the implications are significant. Products shipping with hardcoded credentials, weak password encryption, or shared cryptographic keys will face scrutiny not just from security researchers, but from market surveillance authorities with enforcement power. The era where “insecure by design” was an accepted trade-off is ending, at least for the European market. 

IEC 62443

The IEC 62443 series of standards has long been the reference framework for industrial cybersecurity. Part 4-1 defines secure product development lifecycle requirements, and Part 4-2 specifies technical security requirements for individual components, including explicit requirements around credential management, cryptographic implementation, and authentication mechanisms. The IEC has approved IEC 62443 as “horizontal” standards, meaning they serve as the foundation when sector-specific OT security standards are developed. 

While IEC 62443 certification has been available for years, the OT:ICEFALL research revealed an uncomfortable truth: 74% of affected product families held some form of security certification. This suggests that certification processes have sometimes focused on procedural compliance and functional testing rather than rigorous security assessments. 

Standardization bodies are currently working on several standards in order to provide manufacturers of products with digital elements with clear sets of requirements on how to comply with the CRA. In type B norms, general principles and security requirements for products will be defined. In dedicated type C norms, vertical standards for specific groups of products are defined. Most of these standards are however still in a draft phase, with publish dates being set out by Q3 2026 as well as Q4 2027. Waiting for those standards is risky as they still can change and not be declared a harmonized standard in the end too.  

A harmonized standard series already existing is EN 18031-1/2/3 for the security requirements set out in the Radio Equipment Directive. In regard to secrets and cryptographic algorithms it specifies that state of the art algorithms shall be used as well as that factory-default secrets must either be unique per device, or must be enforced to be changed on first use. 

While the IEC 62443 series in its current form cannot become a harmonized standard, it is however an existing agreed upon standard that is commonly used in the industry. It covers a vast majority of requirements set out in the CRA. Hence any efforts put into introducing and being compliant with IEC 62443-4-1 for organizational aspects as well as IEC 62443-4-2 for technical requirements for components or IEC 62443-3-3 for technical requirements for systems prepares the product best in order to comply with the upcoming regulations.

Recommendations for Operators and Manufacturers 

For operators of affected systems: 

• Apply the hotfix for syngo.plaza (VB30E_HF07) per Siemens Healthineers advisory SSA-016040 
• Audit your OT and embedded product inventory for products with known static credential or weak cryptography vulnerabilities 
• Prioritise network segmentation to limit the impact of credential compromise 
• Conduct regular security assessments that include product-level testing, not just configuration reviews:  
• Penetration Tests are an essential tool for identifying vulnerabilities. 

For manufacturers: 

• Eliminate hardcoded credentials and static keys from all products, this is a baseline expectation under both the CRA and IEC 62443 
• The Limes Security Product and Solution Security Team can help you in clarifying regulatory requirements, determining the risk picture, defining security requirements and a secure architecture, as well as introducing organizational processes and work instructions in order to ensure that product security is an integral part throughout the entire product life cycle (from initial design, to implementation, testing, documentation and updates). 

We thank Siemens Healthineers for their professional handling of this disclosure.