Official intent
Strictly segment OT networks so a business-network compromise cannot reach production. The official source remains authoritative.
Read the official campaign ↗The single most valuable OT control is keeping the plant network separate from the business network. Strict segmentation uses zones and conduits, a controlled boundary (ideally a DMZ) between IT and OT, and default-deny rules so that a phished laptop in the office cannot pivot to a controller on the floor. Inside OT, further zoning contains a problem to one line or cell.
Who this applies to: Every environment where the plant network can reach, or be reached from, the business network — which includes most sites that added remote support or historian reporting over the years.
Why it matters
Most OT incidents start in IT and cross a flat connection into production. A hard, well-defined boundary is what stops that pivot — and what keeps ransomware on the business side from halting operations. Zoning also limits how far any single OT compromise can spread once inside.
Risks this reduces
- A business-network compromise pivoting straight onto the plant floor
- Ransomware on the IT side halting production it should never have reached
- Uncontrolled spread between production lines or cells once inside OT
- Vendor and remote sessions landing directly on control networks
Introducing segmentation, firewalls, or new boundary rules can disrupt real-time OT traffic and safety functions. Design with the process owner, validate against production timing requirements, stage changes in maintenance windows, and keep a tested rollback. A control that improves security but risks a safety trip is not an improvement.
Who owns it
OT / network administrator
Plant / OT leader, IT leader, Vendors
High
High
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-02 — Validated OT asset inventory
- A validated inventory and a map of every connection between business and OT networks
- Documented real-time and determinism requirements for the traffic you are about to filter
- Process-owner involvement in the zone design, not just sign-off at the end
Action timeline
- Map every connection between the business and OT networks
- Flag any direct, unfiltered IT-to-OT paths
- Map every connection between the business and OT networks, including forgotten links, cellular modems, and vendor tunnels
- Close or broker the riskiest direct path in an approved window, with a tested rollback
- Define OT zones and the boundary architecture with the process owner
- Close or broker the riskiest direct connections in a window
- Stand up or harden an IT/OT DMZ under default-deny
- Route vendor and remote access into controlled zones only
- Add zones/conduits within OT for critical lines
- Monitor and log all cross-boundary traffic
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Map all connections between the business and OT networks, including forgotten and vendor links.
- Define zones (by line, cell, or criticality) and the conduits allowed between them, with the process owner.
- Establish a controlled IT/OT boundary — ideally a DMZ — that brokers all cross-boundary traffic under default-deny.
- Direct remote and vendor access into controlled zones rather than straight onto the OT network.
- Monitor and log traffic crossing the boundary and between zones so unexpected flows are visible.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
The plant and business networks are effectively one network.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A zone-and-conduit design exists on paper, agreed with the process owner, with the intended boundary described.
Is the intent written down, with a named owner and a scope? - Configured
A boundary device exists between IT and OT and rules are configured, though not yet default-deny.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
An IT/OT DMZ brokers cross-boundary traffic under default-deny, and OT is divided into zones with defined conduits.
Does it cover everything in scope, with the exceptions written down? - Measured
Cross-boundary traffic is logged and reviewed, and segmentation is tested rather than assumed.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
The zone model is owned, reviewed against the inventory, and every broad permit rule is an exception with an expiry date and a safety review.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- From a business-network host, attempt to reach an OT controller directly — it must be blocked.
- Confirm no undocumented direct path bypasses the IT/OT boundary.
- Verify vendor/remote access terminates in a controlled zone, not the production network.
Evidence to retain
OT segmentation architecture and zone/conduit policy
Boundary/DMZ and firewall rule exports enforcing default-deny
Logs of cross-boundary traffic and investigated anomalies
Segmentation test results showing blocked IT-to-OT access
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Unbrokered IT-to-OT paths | Network paths from the business network into OT that bypass the boundary. | Zero. |
| Any-any boundary rules | Rules permitting unrestricted traffic across the IT/OT boundary or between OT zones. | Zero outside a dated, safety-reviewed exception. |
| Segmentation test result | Blocked cross-boundary attempts ÷ attempts in the periodic test. | 100% of paths the design says should be blocked. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
A firewall between IT and OT with an any-any rule, a forgotten engineering laptop bridging both networks, and vendor access that lands directly on the plant floor. A boundary with a hole in it is not segmentation.
Two sized paths
One well-configured firewall between the office and the plant, with default-deny and a short list of documented exceptions, delivers most of the available protection. Add a small DMZ for the historian and remote access when you can. Do not attempt cell-level zoning before the IT/OT boundary is real.
Model zones and conduits against IEC 62443, broker all cross-boundary traffic through a DMZ with protocol-aware inspection, monitor east-west traffic inside OT, and reconcile the zone model against the asset inventory so a new device in the wrong zone surfaces as an event.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Filtering can break real-time and safety-related traffic in ways that are not obvious in a lab. Learn the actual traffic in permit-and-log mode first, validate against the process's timing requirements, stage in approved maintenance windows with the process owner present, and keep a tested rollback and a person at the panel.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication treats separating OT from IT networks, with a controlled boundary, as a primary architectural control.
What this does not claim: 800-82 is guidance, not a compliance standard.
Why: This is the part of the series that requires defining the system under consideration, partitioning it into zones and conduits, assessing risk per zone and conduit, and setting target security levels — the practice's core construct. IEC 62443-3-3 is the companion standard whose technical requirements apply to zones and conduits once defined.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. A companion 62443-3-3 mapping for boundary-enforcement requirements is deliberately withheld until its SR numbers are verified against the licensed text.
Why: The outcome for protecting networks and environments from unauthorized logical access describes the intent.
What this does not claim: The CSF describes outcomes, not testable controls.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.13.1Boundary communications protectionPartial implementation supportModerate
Why: Strict OT segmentation — zones and conduits separating business networks from production — establishes exactly the key internal boundary this requirement cares most about in a manufacturing environment, with an enforcement point governing what crosses it.
What this does not claim: May partially address the requirement, and only where OT assets fall within the assessed CUI boundary — much OT never touches CUI at all. The external-boundary and communications-monitoring expectations sit mostly with the IT estate, and no boundary change in OT can be allowed to interrupt safety systems or production interlocks: firewall work between IT and OT happens in planned windows with safety review and rollback, not on a normal change ticket.
Review status: Technical review complete.
Open the 3.13.1 page →3.13.5Public-access subnetworksPartial implementation supportModerate
Why: The practice's separation of production networks from everything else applies the same physical-or-logical subnetwork discipline this requirement demands, and the industrial DMZ between IT and OT is its most common plant-floor expression.
What this does not claim: 3.13.5 is not a general-purpose IT/OT segmentation requirement — it is specifically about subnetworks for publicly accessible components, so this mapping is conditional: it applies only where an internet-facing or publicly reachable component (a historian, vendor portal, or jump host) is actually placed in a DMZ inside the assessed boundary. Moving such a component into a separated subnetwork is a production change: it gets a planned window, a rollback path, and vendor coordination, because a mis-scoped rule can stop the line. The general segmentation relationship lives in 3.13.1 and 3.13.6.
Review status: Technical review complete.
Open the 3.13.5 page →3.13.6Deny-by-default network trafficPartial implementation supportModerate
Why: Default-deny with permit-by-exception is the traffic policy strict OT segmentation enforces at the IT/OT boundary and between zones — the practice's mature state is exactly this requirement's posture, applied to the plant.
What this does not claim: May partially address the requirement, and only for OT components within the assessed CUI boundary — organizational scoping determines applicability. The requirement covers the whole system's network communications, including the IT estate the practice never touches, and deny-by-default on a live control network is reached incrementally: learn the real traffic in permit-and-log mode first, then tighten in planned windows with the process owner, because a missed permit rule can stop production or sever a safety-relevant flow.
Review status: Technical review complete.
Open the 3.13.6 page →NIST SP 800-171 Rev. 3
03.13.01Boundary ProtectionPartial implementation supportModerate
Why: The IT/OT boundary the practice enforces is exactly a key internal boundary in this requirement's terms: zones and conduits between business and production networks, brokered crossings, and a DMZ for the data that must flow up — boundary protection applied where compromise costs physical downtime.
What this does not claim: May partially address the requirement within the OT enclave; the enterprise external boundary and the rest of the internal architecture sit outside the practice. Tightening OT boundary enforcement can interrupt safety-relevant or production-critical traffic, so changes are staged behind observation and safety review — which means the boundary's effectiveness must be demonstrated with monitoring and test evidence rather than inferred from the plant still running.
Review status: Pending NIST SME review.
Open the 03.13.01 page →03.13.06Network Communications — Deny by Default, Allow by ExceptionPartial implementation supportModerate
Why: Deny-by-default with permit-by-exception is the traffic policy strict OT segmentation enforces at the IT/OT boundary and between zones — the practice's mature state is this requirement's posture, applied to the plant. Mirrors the corrected Rev. 2 relationship (3.13.6).
What this does not claim: May partially address the requirement, and only for OT components within the assessed CUI boundary — organizational scoping determines applicability. The requirement spans the whole system's network communications including the IT estate, and deny-by-default on a live control network is reached incrementally through permit-and-log observation and planned windows, because a missed permit rule can stop production or sever a safety-relevant flow.
Review status: Pending NIST SME review.
Open the 03.13.06 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.