M0807: Network Allowlists
Network allowlists can be implemented through either host-based files or system hosts files to specify what connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in Filter Network Traffic mitigation.
Security context for executives and security teams
Network allowlists matter in ICS because they reduce which devices, addresses, ports, protocols, or MAC addresses can communicate with a control device. For executives and OT leaders, the value is not just “blocking traffic”; it is limiting the paths an attacker could use to reach controllers, engineering functions, alarms, remote services, or OT message flows that can affect physical operations.
Executive priority
Prioritize this as a resilience and safety-supporting control for OT environments where unauthorized communication could enable program changes, operating mode changes, alarm manipulation, remote service movement, rogue master behavior, or unauthorized/blocking of OT messages. Leaders should ask whether critical controllers and engineering assets have documented allowed communication paths, whether exceptions are approved by process owners, and whether evidence exists for audits tied to access control expectations such as NIST SP 800-53 Rev. 5 AC-3.
Technical view
Validate allowlists at the network or host/system level for IP address, MAC address, port, and protocol communication to and from ICS devices. The relationship context shows this mitigation is relevant across many ICS behaviors, including Activate Firmware Update Mode, Program Upload/Download, Online Edit, Program Append, Change/Detect Operating Mode, Remote Services, Rogue Master, Standard Application Layer Protocol use, Alarm Suppression/Modify Alarm Settings, and unauthorized or blocked OT command/reporting messages. MITRE distinguishes this mitigation from application-layer filtering; DNP3, Modbus, HTTP, and similar application-layer controls are addressed by Filter Network Traffic (M0937), so teams should not treat simple allowlists as full protocol-aware inspection.
Likely telemetry
- Network connection records showing source, destination, port, and protocol for ICS segments
- Firewall, router, switch, host firewall, or device allowlist configuration and change logs
- MAC address and IP address inventory for authorized engineering workstations, controllers, servers, and remote access paths
- Denied connection events where allowlist enforcement exists
- OT network flow baselines showing expected controller, engineering workstation, HMI, server, and outstation communications
Detection direction
- MITRE provides no official detection text for this mitigation, so coverage should be validated through control testing and telemetry review rather than assumed detections.
- Compare observed ICS communications against documented allowlists; investigate new sources, destinations, ports, protocols, or MAC addresses that are not tied to an approved operational need.
- Tune for operational realities: maintenance windows, engineering workstation activity, firmware or program changes, and approved remote services may create expected exceptions that still need authorization and logging.
- Check blind spots where allowlists exist only on one enforcement point, where MAC/IP assignments are stale, or where standard application-layer protocols are allowed broadly without protocol-aware filtering.
- Use relationship-driven scenarios to test visibility: attempts to reach engineering functions, upload/download programs, change operating mode, communicate as a rogue master, or send unauthorized command/reporting messages should produce observable allow/deny evidence where controls are deployed.
Mitigation priorities
- Start with an accurate asset and communication inventory for critical ICS devices and the systems allowed to reach them.
- Define least-necessary allowlists for IP address, MAC address, port, and protocol communications, with process-owner approval for exceptions.
- Apply allowlists consistently at practical enforcement points such as host-based controls, system host files, or network controls where supported by the environment.
- Separate this control from application-layer filtering needs; use protocol-aware filtering for application-layer cases referenced by MITRE under M0937.
- Review allowlists during engineering changes, remote access changes, firmware/program maintenance, and incident response to prevent stale or overly broad access from becoming the default.
Additional notes and limits
This is an ICS ATT&CK mitigation, not a technique. Its decision value comes from reducing unauthorized communication paths to sensitive OT functions and message flows. The strongest validation question is whether the organization can prove that only approved systems can communicate with critical controllers, engineering interfaces, alarms, and remote service paths.
The supplied ATT&CK object does not specify platforms, tactics, or official detection guidance. It also does not provide vendor-specific implementation details. Local architecture, asset inventory, change-management records, and OT network telemetry are required to determine whether allowlists are complete, enforceable, and safe for operations.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Network Allowlists
Network allowlists can be implemented through either host-based files or system hosts files to specify what connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in Filter Network Traffic mitigation.
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 | T0816 | Device Restart/Shutdown | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T1692.002 | Reporting MessageSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T1693.002 | Module FirmwareSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0800 | Activate Firmware Update Mode | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T1695.003 | Wi-FiSub-technique | Implement network allowlists to minimize network access to only authorized hosts. |
| ICS | T0838 | Modify Alarm Settings | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T0861 | Point & Tag Identification | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T1693 | Modify Firmware | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0843 | Program Download | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0806 | Brute Force I/O | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
| ICS | T0879 | Damage to Property | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T0843.003 | Program AppendSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0848 | Rogue Master | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T0802 | Automated Collection | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
| ICS | T1695.001 | Serial COMSub-technique | Implement network allowlists to minimize serial comm port access to only authorized hosts, such as comm servers and RTUs. |
| ICS | T1691.002 | Reporting MessageSub-technique | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
| ICS | T0886 | Remote Services | Network allowlists can be implemented through either host-based files or system host files to specify what external connections (e.g., IP address, MAC address, port, protocol) can be made from a device. |
| ICS | T0843.002 | Online EditSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0868 | Detect Operating Mode | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T1691.001 | Command MessageSub-technique | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
| ICS | T0858 | Change Operating Mode | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T0878 | Alarm Suppression | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
| ICS | T1693.001 | System FirmwareSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T1692.001 | Command MessageSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0845 | Program Upload | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations. CitationDepartment of Homeland Security September 2016 |
| ICS | T1695.002 | EthernetSub-technique | Implement network allowlists to minimize network access to only authorized hosts. |
| ICS | T1692 | Unauthorized Message | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T0884 | Connection Proxy | Network allowlists can be implemented through either host-based files or system host files to specify what external connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in the Filter Network Traffic mitigation. |
| ICS | T0869 | Standard Application Layer Protocol | Network allowlists can be implemented through either host-based files or system host files to specify what external connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in the Filter Network Traffic mitigation. |
| ICS | T0843.001 | Download AllSub-technique | Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.CitationDepartment of Homeland Security September 2016 |
| ICS | T1695 | Block Communications | Implement network allowlists to minimize network access to only authorized hosts. |
| ICS | T1691 | Block Operational Technology Message | Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support. |
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 | 32e87614c84e… |
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-attackM0807Open 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.