IEC 62443 network segmentation checklist (with examples)

Network segmentation is the foundation of IEC 62443 compliance. The standard spells out the principles (zones, conduits, security levels) but leaves the operational checklist to you. After auditing a few dozen industrial networks against IEC 62443-3-3, the same gaps show up over and over — and most of them are checkable in an afternoon with the right list.

This is that list. Twelve items, mapped to specific clauses in IEC 62443-3-3, with a verification method for each. Vendor-neutral, runnable, and consistent with the printable PDF version (which you can download below if you want a copy at your audit desk).

Why this checklist matters in 2026

Three things have changed since the IEC 62443 series was last updated:

NIS2 has teeth. Article 21 of the NIS2 Directive requires "appropriate technical and organisational measures" from operators of essential services, which includes most industrial operators in the EU. The Norwegian implementation ("Lov om digital sikkerhet") is in progress as of 2026 and follows the same broad framing. Auditors will look for evidence of segmentation, not just policies that mention it. A policy that says "we segment OT from IT" without a diagram and a verified ACL list will not pass.

Supply-chain attacks have moved down the stack. The 2024 attacks on industrial control vendors made it clear that perimeter defenses alone are not enough. Segmentation is the second line of defense when a vendor or a contractor gets compromised. If your HMI vendor's update server is breached and pushes a malicious patch, segmentation is what keeps that compromise from reaching your PLCs.

Auditors want artifacts, not assertions. Saying "we have network segmentation" is no longer enough. Auditors want to see the diagram, the ACL list, the AAA configuration, the syslog feed. Every item in this checklist produces an artifact you can hand over. If you can show the auditor a verified verification result for each item, the audit goes much faster than if you have to defend policy statements.

Two practical paths through this list: if you are building a new industrial network, work through the items in order. If you are auditing an existing one, run the whole list and triage the gaps by risk.

The 7 Foundational Requirements in 90 seconds

IEC 62443-3-3 organizes its security requirements around seven Foundational Requirements (FRs). These are the categories every industrial security control eventually maps to:

FR	What it covers
FR 1	Identification and authentication control
FR 2	Use control (authorization, permissions)
FR 3	System integrity
FR 4	Data confidentiality
FR 5	Restricted data flow
FR 6	Timely response to events
FR 7	Resource availability

Each FR contains several System Requirements (SRs). For network segmentation, the SRs that matter most live in FR 5 (especially SR 5.1, 5.2, 5.3), but you can't implement FR 5 cleanly without FR 1 and FR 6.

IEC 62443 also defines Security Levels (SL 1 through SL 4) that describe the threat model you're defending against. SL 1 is "casual / coincidental," SL 2 is "intentional with simple means / low resources," SL 3 is "intentional with sophisticated means / moderate resources," and SL 4 is "intentional with sophisticated means / extensive resources." Most industrial operators should target SL 2 as a baseline, with critical systems at SL 3.

The rest of this post is the 12 things that get you there.

The 12-point segmentation checklist

Section 1: Asset inventory

You cannot segment what you don't know exists. Every other section assumes you have an authoritative list of devices, their locations, and their roles. This is the foundation.

Item 01: Authoritative device inventory exists and is current. A single source of truth listing every network device: hostname, IP, vendor, model, role, location, owner. Updated within the last 30 days. Verify: Query your inventory tool (NetBox, PacketPilot Registry, even a maintained spreadsheet). Confirm the most recent entry is within 30 days and that the count matches what arp -a shows on a representative subnet. IEC 62443-3-3: SR 5.1 (you need to know what's there before you can segment it).

Item 02: OT devices are physically and logically mapped. PLCs, HMIs, SCADA servers, and engineering workstations are tagged with site and zone. A walk-the-floor verification matches the inventory to reality. Verify: Site survey document, or PacketPilot Registry with site/zone hierarchy populated for >90% of OT assets. Spot-check three sites: are the physical labels and the logical records consistent? IEC 62443-3-3: SR 5.1.

Section 2: Network zones (Purdue model)

Devices are grouped into zones based on function and trust level. The Purdue model is the reference architecture, but the principle (zone by function, not by physical location) applies regardless of which model you use.

Item 03: Zones are defined and documented. Every device belongs to a documented zone. Zones map to the Purdue levels (L0 through L5) or to a custom functional grouping. Each zone has a stated purpose and a list of authorized device types. Verify: Network diagram with zones overlaid, dated within the last 90 days. Cross-reference each device in the inventory to a zone. IEC 62443-3-3: SR 5.1, SR 5.2 (zone boundary protection).

Item 04: Zone boundaries are enforced at Layer 3. Traffic between zones is filtered. Default-deny. No implicit "any any" rules. ACLs or firewall rules enforce the policy at every zone boundary. Verify: Export the ACL or ruleset from each zone boundary device. Run grep "any any" against the export — should return empty, or only documented exceptions with business justification. IEC 62443-3-3: SR 5.2.

Section 3: Conduits between zones

Conduits are the controlled paths between zones. They're where the real risk lives — and where most OT networks have the weakest controls.

Item 05: Every cross-zone path is a documented conduit. If traffic can flow between zones, there is a conduit. The conduit has a defined purpose, a list of authorized protocols and ports, and a list of source and destination endpoints. Verify: Conduit list document, or network diagram with cross-zone arrows labeled by purpose. Each conduit's purpose should match a business requirement. IEC 62443-3-3: SR 5.1, SR 5.3 (person-to-person communication restrictions).

Item 06: Conduits deny by default; only authorized flows pass. Firewall rules on each conduit are deny-all plus explicit allow. No broad permits. Each allowed flow has a documented justification. Verify: Pull the firewall ruleset. For each rule, confirm there is a business justification on file. Rules with no justification are candidates for removal. IEC 62443-3-3: SR 5.3.

Section 4: IT/OT DMZ

The DMZ between IT and OT networks is the most attacked boundary. Vendor remote access, jump hosts, replication traffic — all should pass through it.

Item 07: A documented DMZ exists between IT and OT networks. A separate network segment with firewalls on both sides. No direct IT-to-OT traffic; all flows transit the DMZ. Verify: Network diagram showing the DMZ. Run show ip route on a representative IT and OT device — verify no direct routes exist between them. All inter-zone traffic must traverse the DMZ. IEC 62443-3-3: SR 5.2.

Item 08: Vendor remote access goes through the DMZ only. No direct VPN tunnels from vendors into OT. All remote access terminates in the DMZ and is brokered through a jump host or privileged access management tool. Verify: Pull the VPN configuration from perimeter devices. Verify no vendor-issued tunnels exist directly into OT subnets. Vendor sessions should always land in the DMZ and be brokered from there. IEC 62443-3-3: SR 5.2, SR 1.1 (identity and authentication control).

Section 5: Identity and access

Segmentation assumes you know who is authorized. Without identity controls, an attacker on a low-trust zone can pivot to a high-trust zone by stealing a credential.

Item 09: AAA is enabled on every network device. Authentication, Authorization, Accounting. Every switch, router, firewall uses central auth (TACACS+ or RADIUS). No local-only accounts except an emergency break-glass account that is documented and monitored. Verify: For each device, run show aaa, show tacacs, and show running-config | include username. Local accounts should be empty or contain only the documented break-glass account. IEC 62443-3-3: SR 1.1 (human user identification), SR 1.5 (authenticator management).

Item 10: Privileged access is restricted and audited. Privilege 15 / enable mode is granted only to specific named accounts or groups. Each privilege-15 action is logged centrally. Verify: Pull the AAA configuration. Verify privilege levels per user and group. Confirm the audit log destination is a central SIEM, not just a local buffer that an attacker could clear. IEC 62443-3-3: SR 2.1 (authorization enforcement), SR 6.1 (audit log accessibility).

Section 6: Logging and monitoring

Segmentation without monitoring is a wall without a guard. You need to see who is crossing your zone boundaries, when, and why.

Item 11: Centralized syslog for every network device. Every switch, router, firewall, and zone-boundary device sends logs to a central SIEM. Local log buffer alone does not count — a successful attack often includes clearing local logs. Verify: For each device, run show logging. Verify a remote syslog target is configured and that target is reachable from the device. Spot-check the SIEM to confirm logs are arriving. IEC 62443-3-3: SR 6.1, SR 6.2 (continuous monitoring).

Item 12: Alerts on cross-zone traffic anomalies. Unusual cross-zone flows trigger alerts. Detection, not just collection. Verify: SIEM rule list. Verify rules exist for: cross-zone denies (someone tried to traverse a zone boundary and was blocked), after-hours OT access (an account authenticating to an OT device at 03:00 is suspicious), new source IP into OT (a workstation in IT that has never talked to OT suddenly tries to), large data transfers across the IT/OT DMZ (a baseline of 5 MB per day jumping to 500 MB is a data exfiltration signal). Test by simulating one of these and confirm the alert fires within 5 minutes. IEC 62443-3-3: SR 6.2.

How to use this checklist

If you're designing a new industrial network: work through the 12 items in order. The first three (inventory, zones, conduits) are the foundation; everything else assumes those are in place. Budget half a day with two engineers — one networking, one OT/control systems — to complete all 12.

If you're auditing an existing network: run the 12 items as a gap analysis. Mark each one as passing, failing, or "cannot verify right now." Triage by risk, not by volume: a 200-line config that drifts on a non-critical switch is less urgent than a 3-line gap that disables auth on a core router. The audit prep checklist below is useful for prioritizing:

Priority	Items to fix first
Critical (fix before any audit)	09 AAA, 11 Logging, 12 Alerts
High (fix this quarter)	01 Inventory, 04 Zone boundaries, 08 Vendor remote access
Medium (fix this year)	02 OT mapping, 06 Conduit deny-default, 10 Privileged access
Lower (good practice)	03 Zone docs, 05 Conduit docs, 07 DMZ docs

If you're prepping for a NIS2 audit: run the full list, document every verification (the "Verify" line in each item tells you what artifact to capture), and keep the results. Auditors want evidence you ran the controls, not just that the controls exist. The PDF version of this checklist is the artifact you hand over.

Total time for the full run: 2 to 4 hours against a mid-size OT network, longer if you also fix the gaps you find.

When PacketPilot Registry fits

Section 1 of this checklist — the asset inventory — is the foundation. If your inventory lives in a spreadsheet that someone updates quarterly, you are one compromised laptop away from a security incident where nobody can answer "what's on our network?" PacketPilot Registry auto-populates from PacketPilot Config discoveries, so the inventory stays current without manual work. That is the only place PacketPilot appears in this checklist, because the rest of the items do not depend on any specific product.

Download the checklist + follow along

The printable PDF version of this 12-point checklist is available below. Same items, same SR references, designed to take to your audit desk.

Download the IEC 62443 segmentation checklist (PDF)

If you want to follow what we are building, find dB-Electronics on LinkedIn. No spam — just product updates and the occasional technical post.

— Ole