Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1694: Insecure Credentials

Adversaries may target insecure credentials as a means to persist on a system or device or move laterally from one system or device to another. Insecure credentials may appear as default credentials which are pre-configured credentials on a system, device, or software that are well-known in documentation or hard-coded credentials which are built into the system, device, or software that cannot be changed or not easily changed because of the impact on control processes.[1][2][3] Adversaries often times use insecure credentials to evade detection as they are typically forgotten about by system and device owners.

ICST1694TechniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Insecure credentials in ICS matter because they can turn forgotten default or hardcoded access into a persistence or lateral movement path across operational assets. The business issue is not just password hygiene; it is whether operators, engineers, vendors, and asset owners can prove that critical workstations, HMIs, controllers, gateways, remote access systems, and network devices are not still reachable through credentials documented by suppliers, embedded in firmware/software, or impractical to rotate.

Executive priority

Treat this as an OT resilience and governance priority. Leaders should ask for evidence that default and hardcoded credentials have been identified, changed where possible, compensated for where not possible, and controlled through access management. This is especially important for audit readiness and incident decision-making because these credentials may be overlooked by system owners and can appear legitimate in logs. Budget and remediation planning should prioritize assets that provide remote access, segmentation, control, safety, or data aggregation functions, including VPN servers, jump hosts, firewalls, control servers, HMIs, PLCs, RTUs, IEDs, safety controllers, gateways, switches, routers, historians, and engineering workstations.

Technical view

SOC, detection engineering, and IR teams should validate coverage around use of known default credentials, shared/vendor accounts, hardcoded service credentials, and authentication to ICS assets from unusual sources. The ATT&CK object has no official detection text and no technique-level platforms or tactics specified, so local asset context is required. Relationship context points to a detection strategy, DET0905 Detection of Insecure Credentials, and mitigation M0801 Access Management. Defensive validation should be asset-led: enumerate where authentication is supported, where credentials cannot be changed, where gateways or inline access management can enforce identity, and where logs can distinguish authorized engineering/vendor activity from unexpected credential use.

Likely telemetry

  • Authentication logs from Windows, Linux, embedded management interfaces, VPN servers, jump hosts, HMIs, historians, application servers, and control servers where available
  • Remote access session records, including VPN, jump host, RDP, SSH, web administration, and vendor access logs where present
  • Network traffic metadata showing management connections to PLCs, RTUs, IEDs, PACs, DCS controllers, safety controllers, routers, switches, firewalls, and data gateways
  • Asset inventory records identifying default accounts, vendor accounts, shared accounts, and devices or software with hardcoded credentials
  • Configuration and change-management evidence showing whether default credentials were changed or whether compensating access controls were applied

Detection direction

  • Because MITRE does not provide official detection detail for T1694, start by validating whether DET0905-style detection is implemented in the local environment rather than assuming coverage exists.
  • Build detections around authentication to ICS assets using known default, vendor, shared, or otherwise unauthorized credentials, while avoiding exposure of the credential values themselves in detection content or tickets.
  • Tune against approved engineering and maintenance activity; many legitimate sessions may use service, vendor, or shared accounts, so alerts need source, destination, asset criticality, time window, and change-ticket context.
  • Prioritize visibility for remote access choke points such as VPN servers and jump hosts, then expand to HMIs, control servers, historians, gateways, and network infrastructure.
  • For embedded assets that do not produce rich logs, use network telemetry, access management logs, and configuration evidence as compensating detection sources.

Mitigation priorities

  • Prioritize M0801 Access Management: enforce authorization decisions through access management technologies, gateways, or inline controls where devices cannot adequately support user identification and authentication.
  • Inventory default and hardcoded credentials across ICS software, firmware, remote access systems, network devices, controllers, HMIs, servers, and field devices.
  • Change default credentials where supported and operationally safe; document exceptions where credentials cannot be changed or are difficult to change because of control-process impact.
  • Reduce credential exposure by limiting management paths to approved jump hosts, VPN servers, gateways, and segmented network zones.
  • Apply compensating controls for hardcoded or non-rotatable credentials, including strict access paths, monitoring, authorization controls, and asset-specific exception ownership.
Analyst notes and limits

This object is an ICS ATT&CK technique, T1694 Insecure Credentials. It has two supplied subtechnique relationships: T1694.001 Default Credentials and T1694.002 Hardcoded Credentials. It targets a broad set of ICS assets, including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, safety controllers, VPN servers, jump hosts, field I/O, routers, switches, firewalls, DCS controllers, and PACs. The strongest decision value is to force asset owners and security teams to prove credential state and access-control coverage, not merely to assert that password policy exists.

The supplied ATT&CK object does not specify tactics, technique-level platforms, or official detection text. It also does not provide actor, campaign, prevalence, or active exploitation information. Any assessment of exposure, detection coverage, or business impact must be based on local asset inventory, authentication architecture, vendor documentation, configuration evidence, and operational constraints.

Official MITRE ATT&CK definition

Insecure Credentials

Adversaries may target insecure credentials as a means to persist on a system or device or move laterally from one system or device to another. Insecure credentials may appear as default credentials which are pre-configured credentials on a system, device, or software that are well-known in documentation or hard-coded credentials which are built into the system, device, or software that cannot be changed or not easily changed because of the impact on control processes.[1][2][3] Adversaries often times use insecure credentials to evade detection as they are typically forgotten about by system and device owners.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
Domain ID Name Relationship / procedure
ICS T1694.002 Hardcoded Credentials Sub-technique Hardcoded Credentials subtechnique of this object.
ICS T1694.001 Default Credentials Sub-technique Default Credentials subtechnique of this object.
Relationship explorer

All related ATT&CK context

targets · ICS Asset A0017: Distributed Control System (DCS) Controller ICS targets · ICS Asset A0014: Routers ICS targets · ICS Asset A0003: Programmable Logic Controller (PLC) ICS subtechnique of · Technique T1694.002: Hardcoded Credentials ICS targets · ICS Asset A0010: Safety Controller ICS targets · ICS Asset A0002: Human-Machine Interface (HMI) ICS detects · Detection Strategy DET0905: Detection of Insecure Credentials ICS targets · ICS Asset A0005: Intelligent Electronic Device (IED) ICS targets · ICS Asset A0009: Data Gateway ICS targets · ICS Asset A0007: Control Server ICS targets · ICS Asset A0004: Remote Terminal Unit (RTU) ICS targets · ICS Asset A0018: Programmable Automation Controller (PAC) ICS targets · ICS Asset A0012: Jump Host ICS mitigates · Mitigation M0801: Access Management ICS targets · ICS Asset A0016: Firewall ICS subtechnique of · Technique T1694.001: Default Credentials ICS targets · ICS Asset A0008: Application Server ICS targets · ICS Asset A0013: Field I/O ICS targets · ICS Asset A0006: Data Historian ICS targets · ICS Asset A0001: Workstation ICS targets · ICS Asset A0015: Switch ICS targets · ICS Asset A0011: Virtual Private Network (VPN) Server ICS
Mitigations

Mitigation direction

Mitigation ICS

M0801: Access Management

Access Management technologies can be used to enforce authorization polices and decisions, especially when existing field devices do not provide sufficient capabilities to support user identification and authentication. [1] These technologies typically utilize an in-line network device or gateway system to prevent access to unauthenticated users, while also integrating with an authentication service to first verify user credentials. [2]

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
d8d50d123af7f1f9...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d8d50d123af7…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    NIST SP 800-82r3

    Keith Stouffer. (2023, September). Guide to Operational Technology (OT) Security. Retrieved April 22, 2026.

    Open source URL
  2. [2]
    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
  3. [3]
    OT IceFall

    Forescout Vedere Labs. (2022, June). OT: IceFall Report. Retrieved April 23, 2026.

    Open source URL
  4. [4]
    mitre-attack T1694
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use