NIST SP 800-82r3 segmentation guidance for OT

NIST SP 800-82 is the US National Institute of Standards and Technology’s guide to securing industrial systems. Revision 3, published in September 2023 as the Guide to Operational Technology (OT) Security, replaced Revision 2 (Guide to Industrial Control Systems (ICS) Security) and widened its scope from ICS to OT in general. It is guidance, not a regulation, but auditors, insurers and sector rules often point to it.

This guide pulls out what SP 800-82r3 says about segmentation and firewalls, with section numbers so you can check each point against the source.

Network architecture (section 5.2.3.1)

Section 5.2.3.1 opens with the core idea: “A good practice for network architectures is to characterize, segment, and isolate IT and OT devices.” It suggests organizing segments with an industry-recognized model, naming the Purdue model, ISA-95 levels and the three-tier IIoT architecture, and adds that organizations “may consider incorporating a DMZ as an enforcement boundary between network segments.” Fig. 16 shows the Purdue model and an IIoT model side by side, each with DMZ segments.

The OT-specific guidance in the same section is where firewall rules come in:

• Firewall rulesets “should be established to only permit connections between adjacent levels, tiers, or zones.”
• With a Purdue architecture, rules and connection paths should “prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices.” The same concept applies to ISA/IEC 62443 and IIC architectures.
• Outbound traffic from the control network is called out as an area of “considerable variation in practice”; organizations “should consider making outbound rules as stringent as inbound rules.”
• Unidirectional gateways are offered as an alternative to firewalls where traffic needs to flow one way only.

Segmentation and isolation (section 6.2.1.3)

Section 6.2.1.3 (Network Segmentation and Isolation, PR.AC-5) adds how to build the rules: use mapped data flows to identify required communications, then configure firewalls and gateways to permit “only explicitly authorized communication between segments.”

Where nobody knows which flows are needed, it suggests temporarily allowing and recording traffic between segments, so the logs show what to authorize. The same review “may also reveal previously unknown or undocumented communication that needs to be reviewed.” That is the case for reading firewall rules together with their traffic, not the rules alone.

The DMZ between enterprise and operations (section 5.4.1)

In the defense-in-depth architecture example for a DCS-based system (section 5.4.1, Fig. 18), SP 800-82r3 separates the field, operations management and DMZ levels, and says:

• Boundary devices control communications between levels, with inbound and outbound rules “defined so that only authorized communication passes between adjacent levels.”
• “Any communications between the enterprise level and the operations management level are required to go through services within the DMZ” in that example, and the DMZ services must be monitored and protected so an attacker cannot pivot through them unseen.

The IDMZ guide covers what usually sits in that DMZ.

Remote access (section 6.2.10)

Section 6.2.10 says remote access “should be provided only if justified and limited to what is required for the business need,” should “not circumvent or negate safety or security controls,” and that multi-factor authentication “should be considered.” For temporary vendor access it lists practices such as removing access when no longer required, monitoring remote activities, and initiating the connection from the OT environment.

The OT overlay of SP 800-53 (Appendix F)

Appendix F tailors the SP 800-53 Rev. 5 security controls to OT. For firewall evidence, the relevant controls include:

Control	Name	What firewall evidence speaks to
SC-7	Boundary Protection	Paths that cross levels without a boundary
AC-4	Information Flow Enforcement	Rules that let traffic flow where the design says it should not
AC-17	Remote Access	Internet, VPN and vendor paths into OT
SC-8	Transmission Confidentiality and Integrity	Cleartext or uninspected traffic across boundaries
AC-3	Access Enforcement	Firewall management reachable from the wrong zones

How SegAudit reports against SP 800-82r3

SegAudit’s audit report has a NIST SP 800-82r3 overlay you can turn on or off. With it on, each finding is restated with the SP 800-82r3 section and figure it relates to and the SP 800-53 controls from the OT overlay, for example section 5.2.3.1 with Fig. 16 and SC-7 and AC-4 for a direct IT-to-OT path, or sections 5.2.3.1 and 6.2.10 with SC-7 and AC-17 for an internet path into OT. Turn it off for a report that cites IEC 62443 only. The overlay is the same findings with assessor citations, not a certification.

In the Northline sample (a made-up three-site company that ships with SegAudit), findings such as “IT L4 talking straight into L2 · 38 sessions” and “Internet (L5) reaching L1 OT · 13 sessions” carry those citations. Paths that skip an adjacent level, the pattern section 5.2.3.1 recommends against, are reported as findings with the traffic and the allowing rule behind them. See the Purdue model guide for the full list.

Common questions

Is NIST SP 800-82 mandatory? Not by itself. It is guidance. Some sector rules, contracts and assessments reference it, so check what applies to your site.

What changed from Revision 2? Revision 3 widens the scope from ICS to OT, updates the threats, risk management, recommended practices and architectures, aligns more closely with other standards including the NIST Cybersecurity Framework, and adds tailoring guidance and an OT overlay for SP 800-53 Rev. 5.

Does SP 800-82r3 require the Purdue model? No. It names the Purdue model as one industry-recognized option among several for organizing segmentation.