T1694.002: Hardcoded Credentials
Adversaries may leverage credentials that are hardcoded in software or firmware to gain an unauthorized interactive user session to an asset. Examples credentials that may be hardcoded in an asset include:
* Username/Passwords * Cryptographic keys/Certificates * API tokens
Unlike Default Credentials, these credentials are built into the system in a way that they either cannot be changed by the asset owner, or may be infeasible to change because of the impact it would cause to the control system operation. These credentials may be reused across whole product lines or device models and are often not published or known to the owner and operators of the asset.[1][2]
Adversaries may utilize these hardcoded credentials to move throughout the control system environment or provide reliable access for their tools to interact with industrial assets.
Analyst context for executives and security teams
Hardcoded credentials in ICS software or firmware create a business risk because the asset owner may not be able to rotate, disable, or even know the credential exists. If such credentials are reused across device models or product lines, a single weakness can become an operational resilience issue across many sites or assets, especially where Field I/O or other embedded control components are involved.
Executive priority
Prioritize this as an OT asset governance and access-control problem, not just a password problem. Leaders should ask which control-system assets rely on credentials that cannot be changed without operational impact, whether compensating access controls exist, and whether procurement, vulnerability management, and incident response processes capture vendor hardcoded-credential advisories. This matters for continuity planning, audit evidence around privileged access, and cyber-physical risk decisions where unauthorized interactive sessions to industrial assets could affect operations.
Technical view
ATT&CK does not provide detection text for T1694.002, but relationship context identifies a detection strategy, DET0798, and mitigation M0801 Access Management. SOC, OT, and IR teams should validate whether they can observe authentication attempts, interactive sessions, and management/protocol access to ICS assets where hardcoded credentials may exist. Because the technique is a sub-technique of Insecure Credentials and targets Field I/O, defenders should map affected embedded assets, known vendor advisories, and any software or firmware where credentials, keys, certificates, or API tokens are built in and not practically changeable.
Likely telemetry
- OT asset inventory showing device model, firmware/software version, and ownership of Field I/O and other embedded assets
- Authentication, authorization, and session logs from gateways, jump hosts, engineering workstations, access-management systems, or inline control points
- Network traffic metadata for management, engineering, or industrial protocol access to control-system assets
- Vendor advisory and vulnerability management records referencing hardcoded passwords, keys, certificates, or API tokens
- Configuration and firmware/software review evidence where available, including certificates, API tokens, and credential-management constraints
Detection direction
- Validate DET0798 applicability in the local OT environment, since ATT&CK does not include detection detail in the supplied object.
- Look for unauthorized or unexpected interactive sessions to ICS assets, especially where normal authentication records are weak or absent.
- Correlate access attempts with asset inventory and vendor advisories; hardcoded credentials may not appear as named accounts known to the owner.
- Tune for operational false positives such as vendor maintenance, engineering activity, commissioning, or gateway-mediated access that may legitimately use shared or embedded credentials.
- Identify blind spots where field devices do not produce authentication logs and where monitoring must occur at a gateway, jump host, network sensor, or access-management layer.
Mitigation priorities
- Start with inventory: identify ICS assets, firmware/software versions, and whether credentials, keys, certificates, or API tokens are hardcoded or not feasibly changeable.
- Apply Access Management controls where device-native authentication is insufficient, such as enforcing authorization decisions through an inline network device, gateway, or authenticated access path as described by M0801.
- Restrict management and engineering access to affected assets using least privilege, segmentation, and controlled maintenance workflows.
- Track vendor advisories and replacement or firmware options for products where hardcoded credentials are documented or suspected.
- Document compensating controls for compliance and risk acceptance when credentials cannot be changed without affecting control-system operation.
Analyst notes and limits
This object is an ICS sub-technique under Insecure Credentials. The supplied description emphasizes credentials embedded in software or firmware, including usernames/passwords, cryptographic keys/certificates, and API tokens, and distinguishes them from default credentials because the owner may not be able to change them. Relationship context includes Field I/O as a target, Access Management as a mitigation, DET0798 as a detection strategy, and historical software examples Stuxnet and INCONTROLLER as using the technique.
The supplied ATT&CK fields do not specify tactics, platforms for the technique itself, or official detection text. Any assessment of exposure, exploitability, monitoring coverage, or operational impact requires local asset inventory, vendor documentation, network architecture, and IR telemetry. Do not infer active exploitation or malware presence from the relationship examples alone.
Hardcoded Credentials
Adversaries may leverage credentials that are hardcoded in software or firmware to gain an unauthorized interactive user session to an asset. Examples credentials that may be hardcoded in an asset include:
* Username/Passwords * Cryptographic keys/Certificates * API tokens
Unlike Default Credentials, these credentials are built into the system in a way that they either cannot be changed by the asset owner, or may be infeasible to change because of the impact it would cause to the control system operation. These credentials may be reused across whole product lines or device models and are often not published or known to the owner and operators of the asset.[1][2]
Adversaries may utilize these hardcoded credentials to move throughout the control system environment or provide reliable access for their tools to interact with industrial assets.
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 | T1694 | Insecure Credentials | This object subtechnique of Insecure Credentials. |
| ICS | T0891 | Hardcoded Credentials | Hardcoded Credentials revoked by this object. |
Groups, software, and campaigns
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
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 | baaa549b6c62… |
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]
ICS-ALERT-13-164-01
Cybersecurity and Infrastructure Security Agency (CISA). (2013, October 29). Medical Devices Hard-Coded Passwords. Retrieved April 23, 2026.
Open source URL -
[2]
OT IceFall
Forescout Vedere Labs. (2022, June). OT: IceFall Report. Retrieved April 23, 2026.
Open source URL -
[3]
mitre-attack T1694.002Open 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.