Insecure Credentials (T1694) is an adversary logging in to a PLC, HMI, RTU, relay or OT server with a password the vendor shipped and nobody changed, or with one built into the firmware that the owner cannot change at all. MITRE ATT&CK for ICS v20 places T1694 under both Persistence (TA0110) and Lateral Movement (TA0109), for Embedded, Windows, Linux and Network Devices platforms, with two sub-techniques: Default Credentials (T1694.001) and Hardcoded Credentials (T1694.002). It replaces the older IDs T0812 and T0891, which ATT&CK now shows as revoked. MITRE notes that adversaries favour these credentials because owners tend to forget they exist. This guide is for OT security engineers, control system engineers and asset owners: what the technique covers, how real campaigns used it, the ATT&CK v20 detection analytics, and a practical programme to find and remove insecure credentials without disturbing the process. For the wider matrix see the MITRE ATT&CK for ICS Guide; for cross-sector incidents see the Default Credential Breaches Lessons Guide.
Key takeaways
- Two different problems share one ID. Default credentials can be changed and usually are not; hardcoded credentials often cannot be changed by the owner, so they need compensating network controls rather than a password reset.
- Internet exposure turns a default password into an incident. CISA's Unitronics advisories tie the 2023 water sector intrusions to devices reachable from the internet that had a default password or no password.
- The technique is used to stay and to spread. ATT&CK maps it to Persistence and Lateral Movement: Stuxnet used a hardcoded WinCC database password to move, and INCONTROLLER can log in to Omron PLCs with hardcoded credentials.
- Detection is about who logs in from where. ATT&CK's v20 analytics flag authentication with known default or hardcoded values from a source outside the approved engineering hosts, jump path or management subnet.
- Procurement is the durable fix. Require unique per-device credentials and changeable accounts in purchase specifications, because a credential that cannot be changed stays a risk for the life of the asset.
What T1694 covers
ATT&CK describes insecure credentials as either default credentials, which are pre-configured and well known from documentation, or hardcoded credentials, which are built into the system, device or software and cannot be changed, or cannot easily be changed because of the impact on control processes. The hardcoded sub-technique lists three forms: usernames and passwords, cryptographic keys or certificates, and API tokens. MITRE notes these may be reused across whole product lines and are often not known to the owner.
| Sub-technique | What it is | Can the owner change it? | Primary response |
|---|---|---|---|
| T1694.001 Default Credentials | Manufacturer or supplier set credentials, often administrative, documented in manuals or online | Usually yes; MITRE notes some devices have usernames or passwords that cannot be changed | Change at commissioning, verify, and alert on any later use |
| T1694.002 Hardcoded Credentials | Passwords, keys, certificates or API tokens built into software or firmware | Often no, or not without operational impact | Vendor fix through firmware update, plus network allowlisting and monitoring until then |
T1694 sits next to related techniques that have their own pages: Valid Accounts (T0859) covers use of legitimate accounts more broadly, and Change Credential (T0892) covers an adversary changing a device password to lock owners out. Keep these distinct when mapping detections.
What real campaigns show
ATT&CK v20 lists the following procedure examples for T1694 and its sub-techniques. They are described here only as ATT&CK and the cited government sources state them.
| Campaign or software | What ATT&CK or the source records | Lesson for defenders |
|---|---|---|
| Unitronics Defacement Campaign (C0031), CyberAv3ngers (G1027) | Default credentials on Unitronics Vision Series PLCs with integrated HMIs; many used the default password 1111. CISA AA23-335A says actors reached internet-connected devices that had a default password or no password, at least 75 devices compromised between November 2023 and January 2024, including at least 34 in the US water and wastewater sector. | Default password plus internet exposure. CISA also notes the actors moved the device port from the default TCP 20256 to 20257, which hindered owners reconnecting. |
| 2026 U.S. Water Utilities Attacks (C0066) | ATT&CK records the adversary logging in to internet-exposed PLCs using default credentials, at water towers and lift stations reachable through cellular gateways, then reconfiguring IP addresses and passwords to lock operators out. ATT&CK notes attribution for these intrusions is unconfirmed. | Cellular gateways are an exposure path that perimeter firewall reviews miss. |
| 2025 Poland Wiper Attacks (C0063) | ATT&CK, citing CERT Polska, records default credentials used to access RTUs, protection relays, HMI computers and serial device servers at energy sites. | Field and communication devices need the same credential review as PLCs. |
| Stuxnet (S0603) | Used a hardcoded password in the WinCC database server to propagate to nearby systems. | Hardcoded credentials in OT software become a lateral movement path between hosts. |
| INCONTROLLER (S1045) | Can log in to Omron PLCs using hardcoded credentials, documented in CVE-2022-34151. | Track vendor advisories for hardcoded credential CVEs and apply fixes when outages allow. |
For the actor behind the Unitronics campaign see the CyberAv3ngers Threat Actor Profile, and for the water sector rules that followed see the EPA Water Sector Cybersecurity Requirements Guide.
Why insecure credentials survive in OT
- Commissioning pressure: integrators bring systems up with documented defaults and the hand-over checklist does not include changing them.
- Fear of lockout: operators worry that a changed password will be lost and block access to a controller during an upset, so defaults are kept "for safety".
- Shared accounts: one engineering login used by every engineer and the vendor makes rotation a coordination problem.
- Hidden accounts: hardcoded credentials are often undocumented, so asset owners do not know to compensate for them. ATT&CK's detection analytic for T1694.002 cites undocumented power-user accounts with hardcoded credentials in older TriStation 1131 versions as an example.
- Research volume: Forescout's OT:ICEFALL research in 2022 disclosed 56 vulnerabilities across 10 OT vendors, and reporting on it notes that 38 percent of them allowed credential compromise, which shows how common the design pattern is.
Detection: ATT&CK v20 analytics
ATT&CK v20 gives T1694 the detection strategy DET0905, with platform analytics that share one idea: a successful login using a known default or hardcoded value is suspicious when it comes from a source outside the approved identity, host, jump path or zone policy, and MITRE asks for corroboration (access to a protected asset, a configuration change or execution) before alerting, with approved shift and vendor activity suppressed.
| Platform | Log source named by ATT&CK | What to look for |
|---|---|---|
| Windows (HMI, historian, SCADA server) | Windows Security Event ID 4624 and 4625 | Logons with accounts on your default or hardcoded credential list from hosts outside the approved list |
| Linux OT assets | syslog auth (sshd Accepted) | SSH or application logins with default or hardcoded usernames from outside the approved admin subnet |
| Network devices | Device authentication and audit syslog | Management logins with vendor default or prohibited accounts from outside the network management subnet |
| Embedded field devices | Network security monitoring of protocol content | Authentication success with default or known hardcoded values from a source not on the engineering workstation list |
The embedded analytic depends on passive monitoring that can parse the device's management protocol. See the OT Network Security Monitoring Guide for sensor placement. Two practical points: build the default credential list from your own asset inventory and vendor manuals rather than generic lists, and never test credentials actively against production controllers without an operations-approved test plan.
Prevention: ATT&CK mitigations in practice
| Mitigation | ATT&CK wording (summarised) | What it means on the plant floor |
|---|---|---|
| M0801 Access Management | Protect embedded controls and network devices with access management because they often have insecure, unknown default or hardcoded accounts | Put device management behind a controlled access path (jump host or OT remote access gateway) that adds individual identity and MFA in front of devices that cannot do it themselves |
| M0927 Password Policies (T1694.001) | Review vendor documents and security alerts for unknown or overlooked default credentials on existing devices | Keep a per-model record of every documented account, changed or not, and recheck when advisories appear |
| Network controls (CISA Unitronics guidance) | Remove PLCs from the public internet, allow only approved IP addresses, place a firewall or VPN in front, change the default port where possible | Compensating control for hardcoded credentials until the vendor fixes them |
CISA's November 2023 Unitronics alert is explicit: replace all default passwords on PLCs and HMIs with strong passwords and make sure the Unitronics default password 1111 is not in use, require MFA for all remote access to the OT network, and back up PLC logic and configuration. Its December 2023 Secure by Design alert asks manufacturers to stop shipping static default passwords. See the OT Remote Access Guide and the OT Product Procurement Guide.
Where identity fits
Most insecure credentials in OT are non-human or shared identities: built-in device accounts, service accounts between the HMI and its database, vendor support logins and API tokens in firmware. Treat them as you would any machine credential: give each an owner, record where it is stored, and rotate what can be rotated on a schedule that matches outage windows. Store changed device passwords in a vault reachable from the OT side so the fear of lockout does not push teams back to defaults. The OT and ICS Identity and Access Guide covers the account model and the Device and IoT Identity Guide covers certificate-based device identity.
How to implement
- Inventory first. From passive asset discovery and project files, list every PLC, HMI, RTU, relay, gateway, switch and server by make, model and firmware. See the OT Asset Visibility Guide.
- Build the credential register. For each model record every documented account from the manual and vendor advisories, whether it can be changed, and whether hardcoded credential CVEs exist.
- Close internet exposure. Check external exposure, including cellular gateways and modems, and remove direct access before touching passwords.
- Change defaults in maintenance windows. Start with engineering workstations, HMIs and network devices, then controllers. Change one device, confirm the HMI, historian and engineering software still connect, then proceed. Rollback is the previous credential held in the vault for the window only.
- Compensate for hardcoded credentials. Allowlist which hosts can reach the device's management port, route vendor access through a brokered gateway, and plan the vendor firmware update in the next outage. See the OT Patch Management Guide.
- Turn on detection. Load your credential register into the monitoring rules described above and alert only on out-of-policy sources.
- Lock it into procurement and commissioning. Add unique per-device credentials, changeable accounts and no undocumented accounts to purchase specifications and site acceptance tests.
Decision guidance
- Change the password or compensate: change it when the device supports it and the dependent applications are known; compensate with network controls when the credential is hardcoded or when changing it would need a full requalification of the process.
- Small sites: a water utility with a handful of PLCs gets most value from removing internet exposure, changing defaults and adding a VPN or gateway with MFA, as CISA recommends.
- Large estates: passive monitoring with credential-aware protocol parsing, a central vault and procurement clauses scale better than site-by-site checks.
- Shared engineering accounts: where a device supports only one account, keep it in a vault, release it per session through the access gateway, and log who checked it out.
Detection and measurement
- Default credential coverage: percentage of inventoried devices confirmed changed from defaults (target 100 percent of changeable devices).
- Hardcoded credential exposure: number of devices with known hardcoded credentials reachable from outside their zone (target zero).
- Internet-exposed OT assets: count from periodic external exposure checks, as CISA advises inventorying internet-accessible devices periodically.
- Out-of-policy logins: alerts on default or hardcoded accounts from non-approved sources, and time to triage.
- Register freshness: days since each vendor's credential entries were checked against new advisories.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for ICS | T1694, T1694.001, T1694.002; M0801, M0927; DET0905 | Technique, mitigations and detection strategy |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, IA-5(1) Password-based Authentication, AC-2 Account Management, AC-17 Remote Access, SC-7 Boundary Protection | Change defaults, manage accounts, control remote and boundary access |
| NIST CSF 2.0 | PR.AA-01, PR.IR-01, DE.CM-01, ID.AM-01 | Credential management, logical access protection, network monitoring, hardware inventory |
| NIST SP 800-82 Rev 3 | Guide to OT Security | OT overlay for applying SP 800-53 controls; see the NIST SP 800-82 OT Security Guide |
| IEC 62443 | System and component security requirements | Authentication requirements for systems and components; see the IEC 62443 Guide |
Common failure patterns
- Changing the password but leaving the device online: a strong password on an internet-facing PLC still exposes its other weaknesses; remove exposure first.
- Missing the cellular path: remote sites reached through cellular gateways sit outside firewall reviews, as the 2026 water utility intrusions recorded by ATT&CK show.
- Treating hardcoded credentials as a password problem: they cannot be reset by the owner, so the only interim control is restricting who can reach the device.
- Forgetting communication devices: serial device servers, relays and RTUs were among the default-credential targets ATT&CK records in the 2025 Poland attacks.
- No recovery plan for lockout: ATT&CK records CyberAv3ngers locking operators out in its 2026 Iranian Water Campaign, and the unattributed 2026 U.S. Water Utilities Attacks (C0066) reconfiguring IP addresses and passwords to the same effect; without logic backups and a known factory reset process, recovery is slow. See the OT Backup, Recovery and Golden Image Guide.
Practitioner checklist
- Confirm no PLC, HMI or RTU is reachable from the internet, including through cellular gateways.
- Maintain a per-model register of default and hardcoded accounts, with changeability and CVE status.
- Change every changeable default in a planned window and confirm dependent applications still connect.
- Restrict management ports of devices with hardcoded credentials to named engineering hosts.
- Route vendor and engineering access through a gateway with individual identity and MFA.
- Store device credentials in a vault reachable from the OT network, with checkout logging.
- Alert on default or hardcoded account use from sources outside the approved access path.
- Back up PLC logic and configuration and rehearse the factory reset and restore process.
- Add unique per-device credentials and no undocumented accounts to procurement and acceptance tests.
Standards and references
- MITRE ATT&CK: Insecure Credentials (T1694)
- MITRE ATT&CK: Default Credentials (T1694.001)
- MITRE ATT&CK: Hardcoded Credentials (T1694.002)
- CISA: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors (AA23-335A)
- CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
- CISA: Secure by Design Alert, Eliminating Default Passwords
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- Dark Reading: 56 Vulnerabilities Discovered in OT Products From 10 Different Vendors
Related NHI Mgmt Group resources: Default Credential Breaches Lessons Guide · OT and ICS Identity and Access Guide · HMI and SCADA Server Hardening Guide · MITRE ATT&CK for ICS T0866 Exploitation of Remote Services