Quick answer. Industrial network segmentation for a machine means three zones: a Machine zone (PLC, HMI, remote I/O), a Service zone (service laptop and remote-access gateway) and a Plant zone. A firewall between machine and plant passes only the flows listed in a table, both ways. Port 102 on the PLC cannot be switched off in the CPU, so you close it at the firewall. With SCALANCE XB-000 switches, whose manual lists no Web or SNMP diagnostics, the separation is physical.
This article works on a fictional plant, Line P1: a palletizing line with one S7-1500, one Comfort HMI panel, two ET 200SP stations and two switches. All addresses are made up. The zones defined here are the ones reused in IEC 62443 for PLC programmers; the wider picture is in the practical PLC cybersecurity guide for machine programmers.
In particolar modo vedremo:
Industrial network segmentation: zones and conduits, briefly
The ISA quick start guide to IEC 62443 defines a zone as a grouping of logical or physical assets based on risk or on other criteria such as criticality, operational function or responsible organization. A conduit is a logical grouping of communication channels that connects two or more zones and shares common security requirements. Among the things to keep apart, the guide lists business assets versus control assets, temporarily connected devices, and devices connected via external networks.
Siemens’ Operational Guidelines talk about a cell: it contains only components with the same protection requirements, and all devices of a PROFINET system belong to a single cell. The PLC and ET 200SP stations on Line P1 form one PROFINET system, so they sit together, with the HMI.
That gives three zones:
- Machine zone: PLC, HMI, remote I/O, switches. This is the cell.
- Service zone: the laptop that is plugged in only during a job, and the gateway that brings remote support in. These are the guide’s “temporarily connected” and “connected via external networks” devices.
- Plant zone: the site network run by the plant owner, 10.20.0.0/16 in this example.
Who decides? Per the ISA guide, the asset owner establishes the risk assessment methodology, and the last step of the zone and conduit process is the asset owner’s approval; the integrator may help partition the system into zones and conduits. The machine builder proposes the zones. The Plant zone and its DMZ belong to the customer.
Managed and unmanaged switches: what you can actually configure
NIST SP 800-82 Rev. 3 says segmentation is typically done physically, with different switches, or logically, with VLANs. VLANs live on the switching equipment and separate traffic by switch port. NIST adds that VLANs can be cost-effective, but physically separate switches should be considered for high-criticality devices, such as those supporting safety systems.
On Line P1 both switches are SCALANCE XB005. In the XB-000 operating instructions (edition 01/2022), the feature table shows “-” for “Diagnostics: Web, SNMP, PROFINET” on every model, and the same manual says these switches cannot be used in a redundant ring. The word VLAN appears only in the technical specifications, in the row “IEEE 802.1Q tags (VLAN ID, priority) transparent forwarding”: the switch passes tagged frames through as they are. With no management interface, in our reading, there is nowhere to set up a VLAN or port security.
That leaves two options, and both belong in the quote, not in a surprise later:
- Keep the XB005s and separate physically: the Machine zone has its own switches, which reach the plant network only through the firewall. That is NIST’s first route, and with two dedicated switches it is already how Line P1 is built.
- Replace the switches with managed ones if you want to split the cell logically or shut unused ports. That is an extra cost line. Pick the model from its own manual, not by analogy with another one.
What the firewall has to stop, and why the PLC can’t do it alone
The S7-1500 Communication Function Manual (edition 11/2025) lists the CPU’s ports and services. Two rows drive the firewall design. Port 102/TCP (ISO-on-TCP: S7, PG and HMI traffic) and port 34964/UDP (PROFINET Context Manager) are active, and for both the manual says “This function cannot be deactivated.” You cannot turn them off in the CPU. If the plant network must not reach them, you block them upstream.
| CPU service | Port | Default | At the boundary |
|---|---|---|---|
| ISO-on-TCP (S7, PG, HMI) | 102/TCP | active, cannot be deactivated | blocked from the Plant zone |
| PROFINET Context Manager | 34964/UDP | active, cannot be deactivated | stays inside the cell |
| Web server | 80 / 443 TCP | off | blocked; if enabled, HTTPS only |
| OPC UA server | 4840/TCP | off | open only to the client that uses it |
| SNMP | 161/UDP | on up to FW V2.9, off from V3.0 | blocked |
| Modbus TCP | 502/TCP | off | blocked unless used |
| Syslog client | 6514/TCP, 514/UDP | off | outbound to the log server |
If you enable the web server, “Permit access only with HTTPS” is already ticked; the certificate encrypts the link but, in the manual’s words, does not provide access protection. User management does that. For the OPC UA server the manual recommends allowing access only with user authentication. The default SNMP communities, “public” and “private”, go over the wire in plain text; switch SNMP off, though, and tools such as PRONETA lose topology diagnostics. If you need topology diagnostics, keep it on inside the cell only and block it at the boundary; otherwise leave it off, as it is by default from FW V3.0.
For hardening inside the CPU (access levels, PUT/GET, secure PG/HMI communication), see how to protect an S7-1500 with passwords and access levels.
For the rules, NIST asks for connections only between adjacent levels (in a Purdue architecture, no direct traffic from Level 4 to Levels 2, 1 or 0) and for outbound rules as strict as inbound ones. The CISA advisory on DarkSide ransomware adds that industrial control protocols should not traverse the IT network. Placing the PLC and HMI in Purdue levels is our reading; the principles are not.
CP 1543-1: a firewall inside the S7-1500 station
If you don’t want a separate box, Siemens lists CPs with “Security Integrated” functions as an alternative or complement to security appliances. According to the Communication Function Manual, the CP 1543-1 provides an IP firewall with stateful packet inspection on layers 3 and 4, a firewall for non-IP Ethernet frames (layer 2), bandwidth limitation, and an IPsec VPN in tunnel mode. Logs go either to local storage or to a network Syslog server.
One exception is written in the manual and should be read before you choose the CP: if you access the CPU through the CP’s interface using the “Access to PLC via communication module” function, the firewall does not protect that connection. Our takeaway: with that function on, the path to the CPU is open whatever the rules say.
We don’t give the TIA menu path for the CP rules here: check it on your version.
DCP and LLDP travel as Ethernet frames (Ethertype 0x8892 and 0x88CC), not as IP packets, so a rule written on addresses and ports doesn’t describe them. In the CPU services table, the Communication Function Manual shows how to limit them: the “End of detection of accessible nodes” boundary for DCP and “End of topology discovery” for sending LLDP. How your boundary device handles them depends on the device.
The CP 1543-1 firewall does not protect a connection to the CPU that goes through the CP’s interface with the “Access to PLC via communication module” function.
Service zone, remote support and the DMZ
The Line P1 remote-access gateway has one leg on the machine network (192.168.10.2) and one towards the plant. It is a second conduit, and it does not go through the cell firewall: its rules live on the gateway and on the customer’s firewall.
The OT secure connectivity principles published by NCSC-UK, CISA and partner agencies (January 2026) ask for connections initiated outbound from inside the OT environment, vendor support brokered through a gateway in a separate segment such as a DMZ, and access enabled only when needed. They also warn that in a flat OT network with vendor VPN access, a contractor connecting to their own equipment can reach every other device. Check your gateway’s manual to see whether it can restrict reachable destinations.
Siemens’ Operational Guidelines describe the DMZ as well: in the more secure variant the link runs through a separate network and direct traffic between production and company networks is blocked by firewalls. On Line P1 the DMZ belongs to the customer: you ask for it, you don’t build it. How sessions are opened and closed is covered in PLC remote access and what not to do.
Example scenario: Line P1
Fictional plant. Addresses marked * are added in this article and stay the same across the series.
| Zone | Device | Address |
|---|---|---|
| Machine zone | S7-1500 PLC | 192.168.10.10 |
| Machine zone | Comfort HMI panel | 192.168.10.20 |
| Machine zone | ET 200SP no. 1 and no. 2 | 192.168.10.31, 192.168.10.32 |
| Machine zone | Switches SW1, SW2 (XB005, unmanaged) | no address |
| Boundary | Cell firewall | 192.168.10.1* / 10.20.12.1* |
| Service zone | Remote-access gateway | 192.168.10.2 / 10.20.12.2* |
| Service zone | Service laptop | 192.168.10.100 (only during a job) |
| Plant zone | OPC UA supervisory client | 10.20.30.50* |
| Plant zone | Syslog server | 10.20.30.60* |
| Customer DMZ | Remote-access broker | 172.16.50.10* |
PLANT ZONE 10.20.0.0/16 (run by the customer)
[OPC UA 10.20.30.50] [Syslog 10.20.30.60] [customer FW]--[DMZ 172.16.50.0/24]
| | | [broker .10]
--------+--------------------+-----------+---------+-----------------------
| |
10.20.12.1 10.20.12.2
[CELL FIREWALL] [REMOTE-ACCESS GATEWAY]
192.168.10.1 192.168.10.2
| | SERVICE ZONE
=================== MACHINE ZONE 192.168.10.0/24 ===========|==============
| |
[SW1 XB005] -------------+------------------+
| | |
[PLC .10] [HMI .20] [service port] --- [laptop .100] SERVICE ZONE
|
[SW2 XB005]
| |
[ET200SP .31] [ET200SP .32]
The Service zone shares 192.168.10.0/24 because the laptop and the gateway must reach the PLC on port 102. The boundary here is about responsibility and time, not an IP filter: laptop on the labelled service port only during a job, gateway enabled only on request. A real filter between the two would need a device in between.
The cell firewall rules. Port numbers come from the Siemens manual; which flows to allow is a design choice. Rule 1 is a declared exception: a plant host talks straight to the PLC. A stricter variant would route it through a server in the DMZ.
| # | From | To | Port | Action | How to check |
|---|---|---|---|---|---|
| 1 | 10.20.30.50 | 192.168.10.10 | 4840/TCP | allow | the client reads with user and password; without credentials the session is refused |
| 2 | 192.168.10.10 | 10.20.30.60 | 6514/TCP | allow (outbound) | CPU events show up on the log server |
| 3 | 10.20.0.0/16 | 192.168.10.0/24 | 102/TCP | deny and log | an attempt from a plant PC appears as denied in the log |
| 4 | 10.20.0.0/16 | 192.168.10.0/24 | 80, 443, 502/TCP; 161, 34964/UDP | deny and log | same as above |
| 5 | 192.168.10.0/24 | any | everything else | deny and log | no allowed outbound traffic in the log apart from rule 2 |
| 6 | any | any | everything else | deny and log | the final rule is last in the list |
The gateway conduit has to be closed separately, or rule 3 is bypassed through 10.20.12.2. The gateway accepts nothing inbound from the plant side and opens only outbound to the broker at 172.16.50.10, on the port its vendor specifies; the customer’s firewall between plant and DMZ lets only that through. Whether your gateway can refuse all inbound connections is in its manual: check.
The sequence we use:
- Look before you close. NIST suggests temporarily allowing and recording all traffic between segments, then deriving the legitimate flows from the logs. Do it at commissioning, with the machine running: a forgotten flow shows up here, not on the night shift.
- Write the table above and get it approved by whoever runs the plant network.
- Turn on the rules and logging, local or Syslog.
- Test on the bench or during a planned stop. NIST asks for extreme caution with active scanning on an operational network: it can make devices unstable. A single targeted attempt on port 102, with the machine stopped, is enough to see the deny line in the log.
What not to do
- Don’t write “VLAN” into the spec if the machine switches are XB-000: their manual mentions VLANs only as transparent forwarding of IEEE 802.1Q tags, and Web and SNMP diagnostics are marked “-“.
- Don’t leave port 102 reachable from the office and count on the PLC: it can’t be deactivated in the CPU.
- Don’t enable “Access to PLC via communication module” on the CP 1543-1 assuming the firewall covers it: the manual says it doesn’t.
- Don’t load an old project onto a replacement CPU without rechecking SNMP: a CPU from FW V3.0 running a project made for older firmware behaves like the old one, with SNMP on and the “public” and “private” communities in effect.
- Don’t scan a production network just to “see what’s there”.
What this article doesn’t cover
The zone and conduit definitions come from the ISA guide, not from the full text of the IEC 62443 standards. We don’t cover any specific vendor’s firewall, the TIA menus for the CP 1543-1, or IPsec VPN ports. The SNMP points apply to CPUs from FW V3.0: check on your version.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (§5.2.3.1, §6.2.1.3, E.1.3, E.2.3)
- Siemens, S7-1500 Communication Function Manual, 11/2025 (table 5-2, chapter 17)
- Siemens, S7-1500 Web server Function Manual, 11/2025
- Siemens, SCALANCE XB-000 Operating Instructions, 01/2022
- Siemens, Cybersecurity for Industry – Operational Guidelines, v2.2.1
- ISA GCA, Quick Start Guide: An Overview of ISA/IEC 62443 Standards
- NCSC-UK, CISA et al., Secure connectivity principles for OT
- CISA/FBI AA21-131A, DarkSide Ransomware
Last checked: 29 September 2026

“Semplifica, automatizza, sorridi: il mantra del programmatore zen.”
Dott. Strongoli Alessandro
Programmatore
CEO IO PROGRAMMO srl


