Live Active security incident? Get immediate response
MITRE ATT&CK® Mitigation

M0814: Static Network Configuration

Configure hosts and devices to use static network configurations when possible, protocols that require dynamic discovery/addressing (e.g., ARP, DHCP, DNS) can be used to manipulate network message forwarding and enable various AiTM attacks. This mitigation may not always be usable due to limited device features or challenges introduced with different network configurations.

ICSM0814MitigationObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Static Network Configuration is an ICS mitigation that reduces reliance on dynamic network behaviors such as ARP, DHCP, and DNS where feasible. For leaders, the value is operational resilience: fewer opportunities for network-positioned adversaries to redirect, observe, discover, or block traffic that supports industrial visibility and control.

Executive priority

Prioritize this as a control-assurance and resilience topic for OT/ICS networks, especially where command messages, reporting messages, alarms, or device discovery could affect safe operations. Executives should ask which critical segments and devices can use static configuration, which cannot, and whether exceptions are documented with compensating monitoring. The listed IEC 62443 and NIST CM-7 mappings also make this relevant for compliance evidence around least functionality and restricted network behavior.

Technical view

SOC, OT engineering, and IR teams should validate where static IP addressing, fixed name resolution, and constrained network configuration are actually implemented versus assumed. Because ATT&CK provides no detection guidance and no specific platforms for this mitigation, coverage should be assessed through configuration review, asset inventory, network baselining, and monitoring for unexpected DHCP, DNS, ARP, broadcast, multicast, discovery, or traffic-forwarding anomalies. Relationship context makes this most relevant to reducing opportunities for Adversary-in-the-Middle, Network Sniffing, Remote System Discovery, Port Scan, Broadcast Discovery, Multicast Discovery, Alarm Suppression, and blocking of OT command or reporting messages.

Likely telemetry

  • Authoritative OT asset inventory with assigned IP addresses, hostnames, roles, and expected network segments
  • Network device configuration records for switches, routers, gateways, and industrial network infrastructure
  • DHCP lease logs or evidence that DHCP is disabled or tightly scoped where static addressing is required
  • DNS configuration and query logs for OT zones where name resolution is used
  • ARP tables, ARP inspection data, or passive network observations showing address-to-MAC stability

Detection direction

  • Treat this primarily as a mitigation validation exercise, not a standalone detection rule, because official detection content is not provided.
  • Baseline expected static address, hostname, and MAC relationships, then investigate unexpected changes or conflicts in critical OT segments.
  • Tune monitoring for unauthorized or unexpected DHCP, DNS, ARP, broadcast, and multicast activity, while accounting for devices or protocols that legitimately require dynamic discovery.
  • Correlate anomalies with relationship-driven behaviors such as remote system discovery, port scanning, AiTM indicators, and disruption of command or reporting messages.
  • Avoid over-alerting on engineering maintenance windows, commissioning activity, or vendor-supported discovery functions by requiring approved change context.

Mitigation priorities

  • Inventory critical ICS hosts and devices and identify where static network configuration is technically supported and operationally safe.
  • Apply static addressing and fixed network parameters first to high-criticality control, monitoring, alarm, command, and reporting paths.
  • Disable or restrict unnecessary dynamic discovery/addressing services where feasible, and document required exceptions.
  • Use segmentation and configuration management to limit the blast radius of devices that must retain dynamic behavior.
  • Maintain compliance evidence mapped to the supplied IEC 62443 SR/CR 7.7 and NIST SP 800-53 CM-7 labels, including configuration standards, exception approvals, and periodic validation results.
Analyst notes and limits

This mitigation is most valuable when assessed jointly by OT engineering, network operations, SOC, and incident response teams. Static configuration can improve predictability, but ATT&CK explicitly notes that it may not always be usable due to device limitations or network design challenges. Local architecture and safety requirements should drive implementation decisions.

The ATT&CK object does not specify platforms, tactics, or official detection analytics. The related techniques indicate defensive relevance but do not prove exposure or exploitation in any environment. Local asset data, network captures, configuration exports, and operational constraints are required to determine applicability and coverage.

Official MITRE ATT&CK definition

Static Network Configuration

Configure hosts and devices to use static network configurations when possible, protocols that require dynamic discovery/addressing (e.g., ARP, DHCP, DNS) can be used to manipulate network message forwarding and enable various AiTM attacks. This mitigation may not always be usable due to limited device features or challenges introduced with different network configurations.

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.

11 rows
Domain ID Name Relationship / procedure
ICS T0846.001 Port Scan Sub-technique

ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols.CitationD. Parsons and D. Wylie September 2019CitationColin Gray Examples of automation protocols with discovery capabilities include OPC UA Device DiscoveryCitationJosh Rinaldi April 2016, BACnetCitationAditya K Sood July 2019, and Ethernet/IP.CitationLangner November 2018
ICS T0846.003 Multicast Discovery Sub-technique

ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols.CitationD. Parsons and D. Wylie September 2019CitationColin Gray Examples of automation protocols with discovery capabilities include OPC UA Device Discovery CitationJosh Rinaldi April 2016, BACnetCitationAditya K Sood July 2019, and Ethernet/IP.CitationLangner November 2018
ICS T0878 Alarm Suppression

Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.
ICS T0888 Remote System Information Discovery

ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols. CitationD. Parsons and D. Wylie September 2019 CitationColin Gray Examples of automation protocols with discovery capabilities include OPC UA Device Discovery CitationJosh Rinaldi April 2016, BACnet CitationAditya K Sood July 2019, and Ethernet/IP. CitationLangner November 2018
ICS T0830 Adversary-in-the-Middle

Statically defined ARP entries can prevent manipulation and sniffing of switched network traffic, as some AiTM techniques depend on sending spoofed ARP messages to manipulate network host's dynamic ARP tables.
ICS T1691.002 Reporting Message Sub-technique

Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.
ICS T0846 Remote System Discovery

ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols.CitationD. Parsons and D. Wylie September 2019CitationColin Gray Examples of automation protocols with discovery capabilities include OPC UA Device DiscoveryCitationJosh Rinaldi April 2016, BACnetCitationAditya K Sood July 2019, and Ethernet/IP.CitationLangner November 2018
ICS T0846.002 Broadcast Discovery Sub-technique

ICS environments typically have more statically defined devices, therefore minimize the use of both IT discovery protocols (e.g., DHCP, LLDP) and discovery functions in automation protocols.CitationD. Parsons and D. Wylie September 2019CitationColin Gray Examples of automation protocols with discovery capabilities include OPC UA Device DiscoveryCitationJosh Rinaldi April 2016, BACnetCitationAditya K Sood July 2019, and Ethernet/IP.CitationLangner November 2018
ICS T1691 Block Operational Technology Message

Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.
ICS T0842 Network Sniffing

Statically defined ARP entries can prevent manipulation and sniffing of switched network traffic, as some AiTM techniques depend on sending spoofed ARP messages to manipulate network host's dynamic ARP tables.
ICS T1691.001 Command Message Sub-technique

Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.
Relationship explorer

All related ATT&CK context

mitigates · Technique T0846.001: Port Scan ICS mitigates · Technique T0846.003: Multicast Discovery ICS mitigates · Technique T0878: Alarm Suppression ICS mitigates · Technique T0888: Remote System Information Discovery ICS mitigates · Technique T0830: Adversary-in-the-Middle ICS mitigates · Technique T1691.002: Reporting Message ICS mitigates · Technique T0846: Remote System Discovery ICS mitigates · Technique T0846.002: Broadcast Discovery ICS mitigates · Technique T1691: Block Operational Technology Message ICS mitigates · Technique T0842: Network Sniffing ICS mitigates · Technique T1691.001: Command Message ICS
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.2
Created
Modified
Raw hash
7ba9b5c5f267b037...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle 7ba9b5c5f267…
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. [1]
    mitre-attack M0814
    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