T1694.001: Default Credentials
Adversaries may leverage manufacturer or supplier set default credentials on control system devices. These default credentials may have administrative permissions and may be necessary for initial configuration of the device. It is general best practice to change the passwords for these accounts as soon as possible, but some manufacturers may have devices that have passwords or usernames that cannot be changed.[1]
Default credentials are normally documented in an instruction manual that is either packaged with the device, published online through official means, or published online through unofficial means. Adversaries may leverage default credentials that have not been properly modified or disabled.
Analyst context for executives and security teams
Default credentials in ICS matter because they can turn normal vendor setup assumptions into unauthorized access paths across operational technology assets. The ATT&CK object specifically notes manufacturer or supplier defaults on control system devices, sometimes with administrative permissions, and sometimes not changeable. For leaders, the decision value is inventory and assurance: know which operational devices, remote access points, HMIs, PLCs, gateways, and network controls still depend on default or weakly governed accounts before an incident forces discovery under pressure.
Executive priority
Treat this as an operational resilience and governance issue, not only a password hygiene issue. The object targets a broad set of ICS assets, including HMIs, PLCs, RTUs, IEDs, historians, control servers, VPN servers, jump hosts, routers, switches, firewalls, safety controllers, and other embedded or server-based components. Executives should ask whether default credential review is part of commissioning, maintenance, remote access approval, and audit evidence. Priority should go first to internet- or remotely reachable access paths, jump hosts/VPNs, devices with administrative defaults, safety- or process-critical controllers, and assets where credentials cannot be changed and therefore require compensating access management controls.
Technical view
SOC, detection engineering, and IR teams should validate coverage around attempts to authenticate to ICS assets using known default account patterns, successful logons to administrative or built-in accounts, and access to devices that should not accept default credentials. ATT&CK provides no official detection text for this sub-technique, but it is related to DET0756, Detection of Default Credentials, and mitigated by Access Management (M0801) and Password Policies (M0927). Because this is an ICS technique under Insecure Credentials (T1694), teams should combine authentication evidence with asset context: device type, criticality, remote access path, maintenance window, vendor account expectations, and whether the account is changeable or must be controlled through an in-line gateway or authentication service.
Likely telemetry
- Authentication logs from workstations, HMIs, control servers, application servers, historians, VPN servers, jump hosts, and management interfaces where available
- Administrative login records from PLCs, RTUs, IEDs, PACs, DCS controllers, safety controllers, routers, switches, firewalls, data gateways, and other embedded devices where supported
- Remote access telemetry from VPN servers, jump hosts, and access management gateways
- Network session metadata showing management access to ICS assets, especially from corporate, remote, or maintenance networks
- Asset inventory and configuration records identifying vendor default accounts, built-in accounts, and credentials that cannot be changed
Detection direction
- Start with an asset-backed list of devices and applications where default credentials are documented, suspected, or not changeable; detection without inventory will be incomplete.
- Tune alerts for successful or repeated authentication to default, built-in, vendor, or administrative accounts on targeted ICS asset classes, with higher priority when access occurs outside approved maintenance windows or from unexpected network zones.
- Correlate authentication events with remote access paths such as VPN servers and jump hosts, since these assets are explicitly in scope as targeted ICS assets.
- Expect blind spots on embedded controllers and field devices that may not produce rich authentication logs; use compensating network session monitoring, access gateway logs, and configuration evidence.
- Reduce false positives by incorporating approved commissioning, vendor support, and maintenance activity, but require documented exceptions where default credentials remain necessary or cannot be changed.
Mitigation priorities
- Enforce password policies for accounts where the device or application supports credential changes, consistent with M0927.
- Disable or change manufacturer/supplier default credentials during commissioning and after maintenance activities where supported.
- For devices that cannot support adequate user identification or authentication, prioritize Access Management controls consistent with M0801, such as an in-line gateway or access management layer that verifies users before allowing device access.
- Restrict management access to ICS assets through approved jump hosts, VPN servers, and segmented network paths; review routers, switches, firewalls, and data gateways as part of the same control surface.
- Maintain evidence: asset inventory, credential exception register, commissioning checklists, access reviews, and compensating-control documentation for audit and incident readiness.
Analyst notes and limits
This sub-technique is a practical test of ICS security governance: can the organization prove which control system assets still have default, built-in, vendor, shared, or non-changeable credentials, and can it show compensating access control where password changes are not possible? The broad target relationships make this relevant across operator workstations, control devices, servers, network infrastructure, and remote access components. The revoked-by relationship from T0812 indicates this object supersedes the prior Default Credentials technique representation in ATT&CK.
ATT&CK provides no official detection text, tactics, or platforms for the primary object, so telemetry and detection guidance must be validated against the local ICS architecture and device capabilities. The targeted asset relationships include platform information for assets, but the technique itself does not specify platforms. No conclusion should be drawn about active exploitation, local exposure, or detection coverage without environment-specific evidence.
Default Credentials
Adversaries may leverage manufacturer or supplier set default credentials on control system devices. These default credentials may have administrative permissions and may be necessary for initial configuration of the device. It is general best practice to change the passwords for these accounts as soon as possible, but some manufacturers may have devices that have passwords or usernames that cannot be changed.[1]
Default credentials are normally documented in an instruction manual that is either packaged with the device, published online through official means, or published online through unofficial means. Adversaries may leverage default credentials that have not been properly modified or disabled.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0812 | Default Credentials | Default Credentials revoked by this object. |
| ICS | T1694 | Insecure Credentials | This object subtechnique of Insecure Credentials. |
Groups, software, and campaigns
C0031: Unitronics Defacement Campaign
The Unitronics Defacement Campaign was a collection of intrusions across multiple sectors by the CyberAv3ngers, where threat actors engaged in a seemingly opportunistic and global targeting and defacement of Unitronics Vision Series Programmable Logic Controller (PLC) with Human-Machine Interface (HMI). The sectors that these PLCs can be commonly found in are water and wastewater, energy, food and beverage manufacturing, and healthcare. The most notable feature of this attack was the defacement of the PLCs' HMIs.[1][2]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | e6d7c7b37362… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Keith Stouffer May 2015
Keith Stouffer 2015, May Guide to Industrial Control Systems (ICS) Security Retrieved. 2018/03/28
Open source URL -
[2]
mitre-attack T1694.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.