What ports do industrial control protocols use?

A Modbus TCP scan lights up port 502. On its own that tells you one fact: something on that address is listening and willing to talk. It does not tell you whether the answer is a PLC, a gateway standing in front of a PLC, a simulator left running on a test bench, or an HMI with a driver nobody remembers installing. A port opens a door. The exchange behind it tells you who is standing there.

This page is the port list for the protocols you will meet on a plant floor, in a substation or in a building automation network. Every number below is either an IANA registration or comes from the vendor's own documentation or a protocol specification, linked at first use. Bookmark it. Link to it. And read the "authenticates by default" column as carefully as the port number, because for most of this list the honest answer is no.

The port list

Transport and port decide where a probe is worth sending. Nothing in this table decides what a device is on its own, a point the next two sections cover in more detail.

Where these protocols sit on the plant network

Most of this list was never meant to face the internet, and most of it was never meant to face a corporate laptop either. Where a protocol's port sits on the Purdue model says more about what a probe is likely to disturb than the port number alone, and that placement is the axis an engagement gets planned around, see how the Purdue model shapes an OT penetration test for the full picture. The figure below maps this guide's ports onto that ladder.

Two things fall out of that ladder immediately. First, almost nothing at Level 0 carries an IP address, HART-IP is the exception, most field instruments are still 4-20mA loops or fieldbus segments a network scan will never see. Second, protocols that share a level do not share a vocabulary. A Modbus master and an EtherNet/IP scanner on the same Level 1 switch cannot talk to each other without a gateway between them, and neither can identify the other by listening on its own port.

A port tells you where to look, not what is listening

Port 102 is the clearest illustration of the whole point of this page. Both S7comm and IEC 61850 MMS ride on ISO-TSAP over RFC 1006, and both listen on TCP/102 by specification. A scan result of "102 open" is genuinely ambiguous: it could be a Siemens S7-1500 running a bottling line, or a protection IED in a substation bay, where the wrong probe has very different consequences. The only way to tell them apart is to read the first protocol data unit after the COTP connection is established. S7comm frames carry Siemens' own job and acknowledgement structure. MMS frames open with an ISO 9506 Initiate-RequestPDU. Different grammar, same door.

The same discipline applies everywhere in the table above, not just on port 102. A device answering on 502 might be a real PLC, a Modbus/TCP-to-serial gateway relaying a different fieldbus behind it, or a honeypot built to look like one. A device on 44818 might expose a full EtherNet/IP object model, or refuse everything except an identity request. Treat the port as a hypothesis worth testing, never as a conclusion, and log the bytes that came back as your evidence, not the port number you connected to.

Ports that should never be probed

Some of these channels are not just fragile, sending anything to them at all is the wrong call regardless of how carefully it is crafted.

None of this is a reason to avoid identifying what is on an OT network. It is a reason to identify it passively first, from a mirrored switch port or a network tap, and to agree the do-not-touch list with the site engineer before a single active packet goes out. A plant engineer will usually know these boundaries by instinct. A security lead running the assessment needs them written down.

What the specifications and registries leave out

A specification defines a default. It does not define what actually ships.

• Vendors remap ports in the field. A site standardising twenty RTUs might move DNP3 off 20000 behind a firewall NAT rule to avoid a conflict, and the specification will not warn you.
• One port, several protocols. Port 102 is the standing example, but any protocol built on a generic transport, ISO-TSAP, plain TCP, plain UDP, can end up shared by more than one vendor's application.
• An open port does not mean the function you need is implemented. A device answering on 502 may support only a handful of Modbus function codes. Reading holding registers does not guarantee the device also accepts a write, and the safety half of that question belongs to the Modbus guide.
• Capable of security is not the same as secured. OPC UA and MQTT can both authenticate and encrypt. Both are routinely deployed without either, because turning security on can break an older client that has no certificate to present.
• Registration is not deployment. An IANA entry tells you what a port is meant for. It says nothing about whether the specific device on the other end of a cable in a specific plant actually honours it.

A short checklist before you scan

• Get the do-not-touch list from the site engineer in writing before anything active happens, safety I/O, failover links and licence servers belong on it by default.
• Start passive. A SPAN or mirror port on an OT switch will identify most of what is on the segment from observed traffic alone, with nothing sent.
• When an active probe is agreed, confirm identity from the protocol exchange, never from the port number, and keep the capture as your evidence. For whether a scan itself is safe to run in the first place, see will a port scan crash a PLC.
• Treat every device that answers as production until told otherwise. A test bench and a live line can share the same subnet and the same port.
• Write down what actually answered, including the protocols that were expected on a port and were not there. A silent 502 is information too.

Nexich runs authorised offensive assessment work inside the perimeter, air-gapped by default. On control networks it stays read-only.