Hard-coded credentials in industrial devices are not the same problem as default passwords, and the procurement checklist that closes one will not close the other. A default password is a management credential preset at the factory and invalidated the moment an operator changes it on first login; a hard-coded credential is a string compiled into firmware, debug backdoors, vendor maintenance accounts, or embedded keys, and rotating the front-facing password does nothing to it [S3].
The risk surface spans roughly 300 medical device models across about 40 vendors flagged by CISA in ICS-ALERT-13-164-01 (2013), where hard-coded passwords permitted privileged access that could change critical settings or modify device firmware on surgical, anesthesia, ventilator, infusion pump, defibrillator, and patient-monitor equipment [S1]. The same pattern shows up in industrial routers, where string scans plus decompilation of the firmware image pull out accounts that are identical across every unit of the same model and firmware revision [S3].
Two Failure Classes, Two Different Remediation Bills
CWE-798 documents the weakness formally: the product contains hard-coded credentials such as a password or cryptographic key, with two variants, an inbound default administration account whose password is hard-coded into the product and typically cannot be changed or disabled without patching, and an outbound variant where the front end stores a fixed credential to talk to a back-end service [S4]. OWASP assigns a high severity and a "very high" likelihood of exploit because the same string is reused across every device of that model and is frequently published on public forums [S5].
The remediation cost gap is what makes this a procurement problem, not just an IT one. A default password problem ends the moment the operator changes the credential; a hard-coded credential requires source change, recompilation, a new firmware release, and a unit-by-unit upgrade campaign across the deployed fleet, and the bill is paid by every device in the field [S3]. For a fleet of several hundred industrial routers pumping data from PLCs, cameras, and sensors back to a control center, that is a simultaneous breach of every customer network those routers touch, which is why auditors have started asking about firmware provenance during procurement [S3].
Where the Strings Actually Live
Hard-coded credentials are commonly found in software applications (local and cloud), BIOS and other firmware on computers, mobile devices, servers, and printers, network switches and routers, control systems, IoT devices, and medical devices, plus DevOps tooling and outbound API integrations [S2]. In the industrial-router class specifically, the strings show up as debug backdoors, vendor maintenance accounts, and embedded keys, not as the user-facing login that an operator can rotate [S3].
BeyondTrust's guidance flags an additional exposure path: developers and other users often embed passwords in code and then forget about it, or accidentally publish the code (such as to GitHub), at which point the plaintext remains easily discoverable by anyone with scanning tools [S2]. Outbound variants carry the same shape: a front-end system that authenticates with a back-end service using a fixed password that is easy to discover, and the extraction of that credential from a compiled binary is exceedingly simple [S5].
Standards Landscape: EN 18031, IEC 62443-4-2, and CWE-798
EN 18031 is the EU harmonized standard for the cybersecurity of networked devices, introduced under the Radio Equipment Directive (RED) cybersecurity requirements, and it explicitly covers default passwords, authentication mechanisms, and security update channels; passing it means the device has been through third-party review on exactly the clauses that catch this failure mode [S3]. IEC 62443-4-2 sits one layer up, specifying technical security requirements for industrial automation and control system components at the component level, and is the standard procurement teams most often reference when writing cyber clauses into a lighting-equipment-and-electric-lamps or industrial-router spec.
CWE-798 (Use of Hard-coded Credentials) and its companion CWE-259 (Use of Hard-coded Password) are the weakness taxonomies auditors map to when a CVE is filed; OWASP also lists CWE-321 (Use of Hard-coded Cryptographic Key) for the symmetric-key variant where encrypted data is recoverable once the key is pulled [S4][S5]. On the medical-device side, ICS-CERT and the FDA's 2013 mitigations list a concrete set of compensating controls: user authentication via user ID and password, smartcard, or biometric; avoidance of hard-coded passwords; physical locks, card readers, and guards; fail-safe modes; and routine, validated security patches with authenticated firmware updates [S1].
Comparison: Default Passwords vs Hard-Coded Credentials on Procurement Criteria
Side by side on four decision criteria, the two failure classes diverge sharply. Closure mechanism: a default password is closed by changing it at first login; a hard-coded credential is closed only by firmware replacement [S3]. Detectability: defaults are obvious from a quick password-change retest on arrival; hard-coded strings require firmware extraction, string scans, and decompilation to find [S3]. Blast radius: a default password leak typically affects one misconfigured unit; a hard-coded credential leak affects every unit of the same model and firmware revision, plus every downstream network those units bridge to [S2][S3]. Regulatory framing: defaults are addressed by EN 18031's authentication clauses and the long-standing "change before deployment" guidance [S3][S7]; hard-coded credentials sit under CWE-798 / CWE-259 and are the harder clause for an OEM to claim compliance with, because the strings are usually invisible to the buyer [S4][S5].
Three Procurement Checks That Filter Out Most Risk
First, run a password-change retest on arrival. Change the management password through the device interface, then try logging in again with every preset account listed in the documentation; restore the device to factory settings once and confirm the old password is invalidated. About fifteen minutes of work screens out most obvious problems, including any default that is not actually invalidated by a reset [S3].
Second, ask the vendor directly whether debug or maintenance accounts with fixed credentials exist in the firmware, whether they can be disabled, and what the firmware update channel is when a security issue is found; a vendor that answers these questions head-on usually has its firmware management in order [S3]. Third, look at certifications: EN 18031 for the EU RED cybersecurity regime, and IEC 62443-4-2 for industrial control system components, both of which address default passwords, authentication, and the update path that determines whether a hard-coded credential can ever be patched out of a deployed fleet [S3]. Beyond the credential clauses, the same procurement gate should require a bill of materials for firmware provenance, since the strings in question are buried below the spec sheet and a checking-and-testing-apparatus used at receiving inspection cannot reverse-engineer them on its own.
Failure Modes and Operational Limits
Even when EN 18031 and IEC 62443-4-2 are met, residual failure modes remain. Inbound hard-coded accounts are often invisible to the operator because the credential channel lives parallel to the user-rotatable login; changing the front password a hundred times does not affect the channel buried in the firmware [S3]. Outbound credentials between a front-end device and a back-end service are equally invisible because the string sits in the binary of one side and is checked by a server the operator does not control [S4][S5].
Stale-credential risk is the second-order failure: hard-coded passwords and tokens are often created with the intention that they never be changed, so administrators are wary of touching them for fear of breaking system behaviour, and the credentials age in place long past their threat-model horizon [S2]. On connected building infrastructure, the same exposure pattern extends to lamps-and-light-fittings with network management modules, to construction-machinery-and-equipment telematics gateways, and to industrial-borescope controllers on remote inspection carts, wherever a credential is shipped in firmware rather than provisioned at first power-up.
Sourcing, Standards, and Trackable Signals
The primary weakness taxonomy is CWE-798 (Use of Hard-coded Credentials, version 4.20), supported by CWE-259 (Use of Hard-coded Password) and CWE-321 (Use of Hard-coded Cryptographic Key) on the OWASP vulnerability list [S4][S5]. The product-level requirement is set by EN 18031 under the EU RED cybersecurity regime and by IEC 62443-4-2 for industrial automation and control system components [S3]. The 2013 ICS-ALERT-13-164-01 baseline mitigations from CISA and the FDA remain the reference list for compensating controls on deployed fleets where firmware replacement is not yet possible: trusted-user access control, password hardening, physical locks, fail-safe modes, validated patch cadence, and authenticated firmware updates [S1].
Two signals worth tracking over the next procurement cycle: whether more OEMs are willing to publish firmware bills of materials (FW-HBOM) listing every credential class shipped in the image, and whether EN 18031 certification starts appearing on the EU declaration of conformity for industrial routers, gateways, and connected industrial-adhesive dispensing controllers with remote-management modules, since that is the visible, third-party-reviewed proof that the default-password and update-channel clauses have actually been audited. Related reading on how credential gaps interact with broader 2026 plant-network risk is in the access-control per-door cost and 2026 price bands analysis and the manufacturing data lakehouse OT integration piece.