M0802: Communication Authenticity
When communicating over an untrusted network, utilize secure network protocols that both authenticate the message sender and can verify its integrity. This can be done either through message authentication codes (MACs) or digital signatures, to detect spoofed network messages and unauthorized connections.
Analyst context for executives and security teams
Communication Authenticity is an ICS mitigation focused on making sure devices can trust who sent a network message and whether the message was changed in transit. In practical terms, this matters because many related ICS behaviors involve spoofed, injected, or altered communications that can affect controller modes, firmware updates, program transfers, operator view, and physical process control.
Executive priority
Treat this as a resilience and cyber-physical risk control, not just an encryption setting. Leaders should ask whether critical ICS communications that cross untrusted networks use protocols or mechanisms that authenticate the sender and verify message integrity. This supports defensible control prioritization for risks such as unauthorized command messages, manipulated reporting data, rogue masters, adversary-in-the-middle activity, program changes, firmware modification, and device restart or shutdown. The ATT&CK labels also map the concept to IEC 62443 and NIST SP 800-53 control families, which can help frame audit and compliance evidence.
Technical view
SOC, OT security, and IR teams should validate where secure network protocols, message authentication codes, or digital signatures are actually enforced for ICS communications. Because ATT&CK provides no detection text and no specific platform scope for this mitigation, coverage should be proven through local architecture review, asset/protocol inventory, configuration evidence, and monitoring of unauthenticated or integrity-failing communications where available. Relationship context is important: this mitigation is relevant to techniques involving unauthorized messages, command and reporting message spoofing, adversary-in-the-middle activity, rogue master behavior, firmware and program transfer activity, controller operating mode changes, and wireless compromise.
Likely telemetry
- ICS network flow and protocol metadata showing communicating peers, direction, and command/reporting message patterns
- Security logs or device events indicating authentication failures, integrity check failures, or rejected unauthorized connections where supported
- Engineering workstation, controller, and management interface logs related to program upload/download, online edits, program append, firmware update activity, and operating mode changes
- Wireless network authentication and connection records for ICS wireless segments where present
- Asset and configuration records showing which ICS protocols or communications paths support sender authentication and message integrity
Detection direction
- Do not assume detection exists because the mitigation is documented; ATT&CK provides no official detection guidance for M0802.
- Inventory ICS communications that traverse untrusted networks and identify where sender authentication and integrity verification are absent, optional, or not enforced.
- Tune monitoring around relationship-driven scenarios: unexpected command messages, reporting message anomalies, rogue master-like communications, program transfer events, firmware update attempts, device restart/shutdown commands, and operating mode changes.
- Account for false positives from legitimate engineering, maintenance, firmware update, and commissioning activity by correlating network events with approved change windows and authorized workstations.
- Prioritize blind spots where legacy or vendor-specific ICS protocols may lack strong authentication or integrity features, or where monitoring cannot inspect whether authenticity checks succeeded or failed.
Mitigation priorities
- Start with critical process paths and untrusted network crossings; determine which ICS message flows could affect safety, availability, operator view, controller logic, firmware, or device operating state.
- Prefer secure network protocols or mechanisms that authenticate message senders and verify integrity, using MACs or digital signatures where supported by the environment.
- Restrict and document authorized engineering workstations, masters, controllers, and management interfaces so authenticity controls align with known communication relationships.
- Use configuration and change-management evidence to prove the control is enabled, enforced, and maintained across program transfer, firmware update, and command/reporting message paths.
- Where full protocol-level authenticity is not available, document compensating controls and residual risk for risk owners rather than treating the mitigation as complete.
Analyst notes and limits
This mitigation has broad relationship coverage across ICS techniques where trusted communications are central to process integrity. The business value is strongest when mapped to specific process consequences: misleading operators, unauthorized command execution, controller reconfiguration, firmware modification, or disruption of expected device response functions.
The supplied ATT&CK object does not specify platforms, tactics, or official detection analytics. It also does not identify particular vendors, protocols, or deployment patterns. Local ICS architecture, device capability, protocol support, and change-management evidence are required to determine applicability and coverage.
Communication Authenticity
When communicating over an untrusted network, utilize secure network protocols that both authenticate the message sender and can verify its integrity. This can be done either through message authentication codes (MACs) or digital signatures, to detect spoofed network messages and unauthorized connections.
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 | T1693 | Modify Firmware | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T1692.001 | Command Message Sub-technique | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0845 | Program Upload | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0858 | Change Operating Mode | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0843.001 | Download All Sub-technique | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0860 | Wireless Compromise | Do not inherently rely on the authenticity provided by the network/link layer (e.g., 802.11, LTE, 802.15.4), as link layer equipment may have long lifespans and protocol vulnerabilities may not be easily patched. Provide defense-in-depth by implementing authenticity within the associated application-layer protocol, or through a network-layer VPN. CitationCISA March 2010 Furthermore, ensure communication schemes provide strong replay protection, employing techniques such as timestamps or cryptographic nonces. |
| ICS | T0832 | Manipulation of View | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0816 | Device Restart/Shutdown | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0843.002 | Online Edit Sub-technique | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0843.003 | Program Append Sub-technique | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0848 | Rogue Master | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0868 | Detect Operating Mode | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T1693.001 | System Firmware Sub-technique | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T1693.002 | Module Firmware Sub-technique | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0800 | Activate Firmware Update Mode | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0831 | Manipulation of Control | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0861 | Point & Tag Identification | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T1692 | Unauthorized Message | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
| ICS | T0843 | Program Download | Protocols used for device management should authenticate all network messages to prevent unauthorized system changes. |
| ICS | T0830 | Adversary-in-the-Middle | Communication authenticity will ensure that any messages tampered with through AiTM can be detected, but cannot prevent eavesdropping on these. In addition, providing communication authenticity around various discovery protocols, such as DNS, can be used to prevent various AiTM procedures. |
| ICS | T1692.002 | Reporting Message Sub-technique | Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs). |
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 | 79da1df4a4d2… |
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]
mitre-attack M0802Open 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.