A0013: Field I/O

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.

Additional 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.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

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.

Filter related techniques28 rows

Domain	ID	Name	Relationship / procedure
ICS	T1695.001	Serial COMSub-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 CredentialsSub-technique	Default Credentials targets this object.
ICS	T1694.002	Hardcoded CredentialsSub-technique	Hardcoded Credentials targets this object.
ICS	T0884	Connection Proxy	Connection Proxy targets this object.
ICS	T1695.002	EthernetSub-technique	Ethernet targets this object.
ICS	T1695.003	Wi-FiSub-technique	Wi-Fi targets this object.
ICS	T0809	Data Destruction	Data Destruction targets this object.
ICS	T1691.002	Reporting MessageSub-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 MessageSub-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: Sep 28, 2023, 17:57 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 9149da9815bd5856...

Imported snapshots across ATT&CK releases(1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	Jul 14, 2026, 09:14 UTC (UTC+00:00)	1.1	May 12, 2026, 15:12 UTC (UTC+00:00)	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.

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]
Guidance - NIST SP800-82
Keith Stouffer. (2015, May). Guide to Industrial Control Systems (ICS) Security. Retrieved March 28, 2018.
Open source URL
[2]
mitre-attackA0013
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