M0808: Encrypt Network Traffic
Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications.
Analyst context for executives and security teams
Encrypt Network Traffic is an ICS mitigation focused on making captured network communications less useful to an adversary. Its business value is strongest where control-system communications, wireless links, remote reporting, or firmware update paths could expose sensitive operational information or enable unsafe changes if observed or manipulated.
Executive priority
Treat this as a resilience and assurance control, not just a technical hardening item. Leaders should ask which ICS communications remain unencrypted, whether wireless and remote links are protected, and whether firmware update traffic is cryptographically protected. The supplied ATT&CK labels map this mitigation to IEC 62443 SR/CR 4.1 and NIST SP 800-53 SC-8, so it can also support compliance evidence when implementation is documented and tested.
Technical view
SOC, IR, and engineering teams should validate where strong cryptographic protocols are actually used across ICS network paths. Priority review areas are those connected to the related ATT&CK techniques: Network Sniffing, Wireless Compromise, Wireless Sniffing, and firmware modification scenarios where update mechanisms may occur over the network. Because ATT&CK provides no detection text and no platform scope for this mitigation, coverage must be proven through local architecture review, packet/flow inspection, configuration evidence, and change records rather than assumed from the ATT&CK entry.
Likely telemetry
- Network flow metadata showing encrypted versus cleartext communication patterns
- Packet capture or protocol inspection evidence for critical ICS links
- Wireless network configuration and monitoring evidence for protected communications
- Firmware update logs, device management logs, and change records where updates occur over the network
- Asset inventory and network diagrams identifying ICS communication paths requiring encryption
Detection direction
- Validate whether sensitive ICS traffic can be observed in cleartext on monitored segments; prioritize paths where sniffing or wireless capture would expose operational data.
- Tune monitoring to distinguish expected encrypted management or control traffic from unexpected protocol changes that may indicate configuration drift.
- Review wireless communications separately from wired traffic because Wireless Compromise and Wireless Sniffing are explicitly related techniques.
- For firmware-related relationships, confirm whether firmware update mechanisms use protected communications and whether logs can prove when updates were initiated and completed.
- Account for blind spots: encrypted traffic reduces content visibility, so defenders may need flow behavior, endpoint/device logs, configuration baselines, and approved change windows to maintain monitoring value.
Mitigation priorities
- Inventory ICS communication paths and identify cleartext traffic carrying sensitive operational, management, wireless, or firmware-update data.
- Prioritize strong cryptographic techniques and protocols for links exposed to sniffing risk, wireless capture risk, or remote update activity.
- Document encryption requirements in architecture standards and change-control processes so new ICS links do not reintroduce unencrypted communications.
- Maintain compliance evidence showing where encryption is implemented and where exceptions are risk-accepted.
- Test operational compatibility carefully in ICS environments before broad changes, because availability and process safety requirements may constrain rollout sequencing.
Analyst notes and limits
This mitigation is most useful as a control validation prompt: prove which communications are encrypted, where exceptions exist, and how monitoring adapts when payload visibility is reduced. The relationship set makes it especially relevant to network and wireless sniffing risks and to firmware update pathways that may occur over the network.
The supplied ATT&CK object does not specify platforms, tactics, or detection guidance. It also does not define specific protocols, cryptographic configurations, or implementation procedures. Local asset inventory, network architecture, and engineering constraints are required to turn this mitigation into a deployable control plan.
Encrypt Network Traffic
Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications.
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 | T0887 | Wireless Sniffing | Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications. CitationBastille April 2017 |
| ICS | T1693 | Modify Firmware | The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware. |
| ICS | T1693.001 | System Firmware Sub-technique | The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware. |
| ICS | T1693.002 | Module Firmware Sub-technique | The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware. |
| ICS | T0860 | Wireless Compromise | Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications. |
| ICS | T0842 | Network Sniffing | Ensure that wired and/or wireless traffic is encrypted when feasible. Use best practices for authentication protocols, such as Kerberos, and ensure web traffic that may contain credentials is protected by SSL/TLS. CitationKeith Stouffer May 2015 |
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 | 1f691507d07e… |
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 M0808Open 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.