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.
Analyst context for executives and security teams
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.
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.
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.
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.
| 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. |
All related ATT&CK context
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.1 | Current bundle | 9149da9815bd… |
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]
Guidance - NIST SP800-82
Keith Stouffer. (2015, May). Guide to Industrial Control Systems (ICS) Security. Retrieved March 28, 2018.
Open source URL -
[2]
mitre-attack A0013Open 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.