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

A0013: Field I/O

Field I/O are devices that communicate with a controller or data aggregator to either send input data or receive output data. Input data may include readings about a given environment/device state from sensors, while output data may include data sent back to actuators for them to either undertake actions or change parameter values.[1] These devices are frequently embedded devices running on lightweight embedded operating systems or RTOSes.

ICSA0013ICS AssetObject v1.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Field I/O devices sit close to the physical process: they send sensor inputs to controllers or data aggregators and receive outputs that drive actuators or parameter changes. Because they are often embedded or RTOS-based, they can be operationally critical while offering limited local logging and security controls. For leaders, the practical issue is whether the organization can prove these devices are inventoried, monitored, and recoverable when communications, credentials, firmware state, wireless links, or physical-process messages are disrupted or manipulated.

Executive priority

Treat Field I/O as a cyber-physical resilience priority, not just an engineering component. ATT&CK relationships show these assets can be relevant to denial of service, restart/shutdown, blocked command or reporting messages, adversary-in-the-middle activity, wireless compromise/sniffing, insecure credentials, firmware update mode abuse, and supply chain concerns. Executives should ask whether OT asset inventories identify Field I/O, whether incident response plans include loss or manipulation of sensor/actuator pathways, and whether audit evidence exists for credential handling, approved firmware/update procedures, network segmentation, and monitoring of controller-to-field communications.

Technical view

SOC, OT security, and IR teams should validate visibility around communications between Field I/O, controllers, and data aggregators, especially where sensor readings, actuator commands, or reporting messages are expected. Since the ATT&CK asset has no official detection guidance and no tactics specified, detection engineering should be relationship-driven: look for abnormal device restarts, update-mode state changes, blocked or missing reporting/command traffic, unexpected intermediaries or proxies, unusual use of commonly used ports, unexpected file/tool transfer paths, credential use against embedded devices, and wireless activity where Field I/O uses RF links. Baselines must be developed with operations teams because normal process behavior, maintenance windows, and safety workflows can resemble suspicious activity without engineering context.

Likely telemetry

  • OT network traffic between Field I/O, controllers, data aggregators, OPC/historian systems, and engineering workstations
  • Sensor input values, actuator output commands, process state, and historian or tag data where available
  • Device status events such as restart, shutdown, loss of communication, inactive state, or firmware/update mode indicators
  • Authentication, administrative access, and credential-use records for embedded devices where supported
  • Configuration, make/model, role, and firmware inventory for Field I/O assets

Detection direction

  • Start with an authoritative asset inventory for Field I/O, including embedded platform details, network paths, wireless use, firmware state, and normal controller/data-aggregator relationships.
  • Baseline normal reporting and command-message timing so missing, blocked, delayed, or altered telemetry can be investigated without relying only on endpoint logs.
  • Correlate process anomalies with network events, device state changes, and maintenance activity; Field I/O behavior often requires engineering context to separate malicious activity from faults or planned work.
  • Validate monitoring for credential-based access, especially default or hardcoded credential exposure noted in related ATT&CK techniques.
  • Review visibility for AiTM, proxying, and commonly used port abuse on OT segments because these can affect communications without obvious device compromise.

Mitigation priorities

  • Prioritize complete inventory and ownership of Field I/O assets, including configuration, firmware, communication dependencies, and maintenance procedures.
  • Harden access paths: remove or manage default credentials where possible, document hardcoded credential risk, restrict administrative interfaces, and control vendor or contractor access.
  • Segment and monitor OT communications so only expected controllers, data aggregators, engineering systems, and protocols can interact with Field I/O.
  • Establish approved firmware/update-mode procedures with operational signoff and evidence capture, because update states can affect expected response functions.
  • Protect process-message integrity by monitoring for missing, blocked, or unexpected command and reporting messages and by defining operational escalation paths when telemetry is unreliable.
Analyst notes and limits

This is an ATT&CK ICS asset object, not a technique. The strongest defensive value comes from its relationships: many ICS techniques target Field I/O because these devices bridge digital control logic and physical process behavior. Glexia would use this object to drive OT visibility, credential governance, firmware/change-control review, and incident-response tabletop scenarios focused on sensor and actuator pathways.

MITRE provides no official detection text, no tactics, and only the Embedded platform for this asset. The supplied fields do not establish active exploitation, specific vendors, exposed services, or guaranteed telemetry. Local architecture, process safety requirements, device capabilities, and maintenance practices are required to turn these recommendations into validated detections or controls.

Official MITRE ATT&CK definition

Field I/O

Field I/O are devices that communicate with a controller or data aggregator to either send input data or receive output data. Input data may include readings about a given environment/device state from sensors, while output data may include data sent back to actuators for them to either undertake actions or change parameter values.[1] These devices are frequently embedded devices running on lightweight embedded operating systems or RTOSes.

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

Techniques used

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.

28 rows
Domain ID Name Relationship / procedure
ICS T1695.001 Serial COM Sub-technique Serial COM targets this object.
ICS T0847 Replication Through Removable Media Replication Through Removable Media targets this object.
ICS T0860 Wireless Compromise Wireless Compromise targets this object.
ICS T0887 Wireless Sniffing Wireless Sniffing targets this object.
ICS T0859 Valid Accounts Valid Accounts targets this object.
ICS T0885 Commonly Used Port Commonly Used Port targets this object.
ICS T0814 Denial of Service Denial of Service targets this object.
ICS T0801 Monitor Process State Monitor Process State targets this object.
ICS T0867 Lateral Tool Transfer Lateral Tool Transfer targets this object.
ICS T1694.001 Default Credentials Sub-technique Default Credentials targets this object.
ICS T1694.002 Hardcoded Credentials Sub-technique Hardcoded Credentials targets this object.
ICS T0884 Connection Proxy Connection Proxy targets this object.
ICS T1695.002 Ethernet Sub-technique Ethernet targets this object.
ICS T1695.003 Wi-Fi Sub-technique Wi-Fi targets this object.
ICS T0809 Data Destruction Data Destruction targets this object.
ICS T1691.002 Reporting Message Sub-technique Reporting Message targets this object.
ICS T0851 Rootkit Rootkit targets this object.
ICS T0871 Execution through API Execution through API targets this object.
ICS T0816 Device Restart/Shutdown Device Restart/Shutdown targets this object.
ICS T0834 Native API Native API targets this object.
ICS T0888 Remote System Information Discovery Remote System Information Discovery targets this object.
ICS T1691 Block Operational Technology Message Block Operational Technology Message targets this object.
ICS T1691.001 Command Message Sub-technique Command Message targets this object.
ICS T1694 Insecure Credentials Insecure Credentials targets this object.
ICS T0800 Activate Firmware Update Mode Activate Firmware Update Mode targets this object.
ICS T0830 Adversary-in-the-Middle Adversary-in-the-Middle targets this object.
ICS T1695 Block Communications Block Communications targets this object.
ICS T0862 Supply Chain Compromise Supply Chain Compromise targets this object.
Relationship explorer

All related ATT&CK context

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.1
Created
Modified
Raw hash
9149da9815bd5856...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 9149da9815bd…
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.

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]
    Guidance - NIST SP800-82

    Keith Stouffer. (2015, May). Guide to Industrial Control Systems (ICS) Security. Retrieved March 28, 2018.

    Open source URL
  2. [2]
    mitre-attack A0013
    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.