EtherNet/IP and CIP Explained: Messaging, Objects and CIP Security

EtherNet/IP is the industrial Ethernet network that carries the Common Industrial Protocol (CIP) over standard TCP/IP: explicit request and response messages run over TCP port 44818, and cyclic I/O data runs over UDP port 2222. Both CIP and EtherNet/IP are maintained by ODVA. Classic CIP has no authentication, so ODVA added CIP Security, which wraps the same traffic in TLS and DTLS on port 2221 and adds device and user identity.

This post sits next to our other one protocol per post explainers for operational technology: Modbus, OPC UA, PROFINET and BACnet. Here we cover the CIP object model, explicit and implicit messaging, Forward Open, List Identity, the published CIP Security profiles, and a read only lab walkthrough for capturing, mapping and segmenting EtherNet/IP. Protocol constants come from ODVA publications, the IANA registry or the Wireshark dissector source, and we flag what we could not confirm.

Key takeaways

• CIP is the application layer; EtherNet/IP is one transport for it. DeviceNet, ControlNet and CompoNet carry the same CIP. The "IP" means Industrial Protocol.
• Everything is an object. Devices expose classes, instances and attributes that you act on with services. Identity is class 0x01, Assembly 0x04, Connection Manager 0x06.
• Explicit messaging is request and response over TCP 44818. Implicit (I/O) messaging is produce and consume over UDP 2222 at a Requested Packet Interval (RPI).
• Forward Open creates a connection and carries the RPI, timeout multiplier, connection IDs, unicast or multicast choice and the path to the data.
• List Identity (command 0x0063) makes every device report vendor, type, product code, firmware revision, serial number and name. On a flat network one broadcast inventories everything.
• CIP Security (Volume 8 of The EtherNet/IP Specification) adds TLS for TCP, DTLS for UDP I/O, certificates or pre-shared keys and user authentication. ODVA's PUB00319R2 lists five profiles.
• CIP Security is opt in per device, and ODVA designed it for mixed networks, so ISA/IEC 62443 style zones and conduits still do most of the work.

What EtherNet/IP is, how it relates to CIP, and who maintains it

ODVA describes CIP as a media independent protocol using a producer and consumer model that is "strictly object oriented" at the upper layers. CIP defines the application layer: objects, services, connection management, device profiles and electronic data sheets. ODVA then adapts it to several networks. EtherNet/IP is the adaptation to standard, unmodified Ethernet and TCP/IP, using TCP for most messaging and UDP for real time cyclic data, in star, linear or Device Level Ring (DLR) topologies. PUB00123R1 explains that the "IP" stands for Industrial Protocol, not Internet Protocol.

The CIP family

ODVA's own documents disagree on EtherNet/IP's year: PUB00123R1 says 2000 and the current overview PUB00138R8 says 2001, without explaining why, so cite the year with its document.

Because these networks share one object model, ODVA's CIP page presents routing across them, without configuring the devices in between, as a core feature. For security, that means an EtherNet/IP request can be routed onward to a CAN or serial network that has no IP addresses or firewalls at all.

Who maintains the specifications

ODVA, an independent not for profit standards organisation, publishes The CIP Networks Library, including The EtherNet/IP Specification. Vendors sign ODVA's terms of usage, get an ODVA vendor ID (which appears in every Identity object) and can have devices conformance tested. The specifications are sold to adopters; the free material is the technology overviews, white papers and guides in ODVA's document library, which is why this post relies on those publications and on the open source Wireshark dissector for byte level constants. For cabling, PUB00123R1 points to IEC 61784-5-2, and ODVA's PUB00035R0 covers EtherNet/IP network infrastructure.

Timeline: EtherNet/IP, CIP and their security work

Sources are listed at the end. Month dates for ODVA publications come from the upload path on ODVA's site unless the PDF prints a date.

How the CIP object model is organised

PUB00123R1 says a CIP device is modelled as a collection of objects, and ODVA's CIP page summarises it in one line: each object has attributes (data), services (commands), connections and behaviours. Four identifiers address anything in a device:

• Node address. On EtherNet/IP this is simply the IP address. On DeviceNet and ControlNet it is the MAC ID, the node number.
• Class ID. Identifies a type of object, such as Identity or Assembly.
• Instance ID. Identifies one object of that class. Most devices have one Identity instance but many Assembly instances.
• Attribute ID. Identifies one data item inside a class or instance.

A service code names the action. PUB00123R1 gives the addressing format as [class ID] [instance ID] [attribute ID, if required] and its own example is class 0x04, instance 0x10, attribute 0x03: the data attribute of Assembly instance 16. That three part path is what you will see in a Wireshark decode of almost every explicit message.

Per PUB00123R1, public class IDs are 0x0000 to 0x0063 and 0x00F0 to 0x02FF, and vendor specific ones are 0x0064 to 0x00C7 and 0x0300 to 0x04FF. A class ID in a vendor range on the wire is a private object, worth noting when you tune monitoring.

The objects you will meet on every EtherNet/IP device

The first six class IDs are from PUB00123R1. The last three come from the class name table in Wireshark's packet-cip.c, because their definitions sit in the non public Volume 8; use them for decoding captures and check the specification before building on them.

The Identity object in detail

PUB00123R1 uses the Identity object to teach the whole model because every device must have one and it is simple. The mandatory instance attributes are Vendor ID, Device Type, Product Code, Revision, Status, Serial Number and Product Name.

The Vendor ID is assigned by ODVA, so it identifies the manufacturer unambiguously. The Revision has a major and minor number, and any change in network behaviour must change at least the minor one, which makes Identity the most reliable firmware version source on the network when you check advisories.

The Assembly object and why it deserves change control

PUB00123R1 explains that Assembly objects map attributes from different objects into one data attribute, attribute 3, so that I/O moves as one block. An input assembly is produced by the device and consumed by the controller; an output assembly is consumed by the device and written to its outputs; a configuration assembly carries a full parameter set in one write. Input and output are always named from the controller's point of view.

The configuration assembly is the part people forget: one write can change a whole module's parameters, and change management that covers only controller logic will miss it.

Services: the verbs

Explicit messages name a service and a path. The service codes you will see most often in captures, from Wireshark's packet-cip.h, are:

For monitoring, reads versus writes is the most useful single signal: an HMI that has only ever read suddenly issuing Set_Attribute_Single is worth a look.

Device profiles and EDS files

Device profiles, per PUB00123R1, are standard object groupings for a device type, such as AC drives, with defined configuration options and I/O formats; open profiles use numbers 0x00 to 0x63 and 0x0100 to 0x02FF. The Electronic Data Sheet (EDS) is, per ODVA's vendor handbook PUB00213R0, an ASCII file that describes a device to configuration tools: assemblies, connection points, supported RPIs and, where present, security capabilities. Keep EDS files in version control next to your network design.

Explicit messaging and implicit messaging

EtherNet/IP carries two very different kinds of traffic, which ODVA's vendor handbook PUB00213R0 contrasts:

IANA registers EtherNet-IP-2 on 44818 as "EtherNet/IP messaging" and EtherNet-IP-1 on 2222 as "EtherNet/IP I/O," and PUB00213R0 agrees on both.

Explicit messaging and the encapsulation layer

Every explicit message on EtherNet/IP travels inside an encapsulation packet. PUB00123R1 gives the structure: a 24 byte header made of Command (2 bytes), Length (2), Session Handle (4), Status (4), Sender Context (8) and Options (4), followed by up to 65,511 bytes of command specific data. PUB00213R0 adds that the encapsulation format is little endian, and that an encapsulation session must be registered before any CIP communication takes place.

The encapsulation commands, with values taken from Wireshark's packet-enip.c:

PUB00123R1 confirms 0x6F in its worked example and adds that only one session may exist between two devices. Inside, the Common Packet Format holds an address item and a data item carrying the CIP (Message Router) request.

Unconnected requests go to the device's unconnected message manager (UCMM). PUB00123R1 recommends them only for infrequent requests; regular polling should use a connected class 3 explicit connection.

Implicit messaging: produce and consume

Implicit messages carry almost no description of themselves. The format is agreed at connection time, so per PUB00123R1 a UDP I/O frame has no encapsulation header, just Common Packet Format items carrying the connection ID, sequence number and data. A 16 bit sequence count prefixes the I/O data, and a real time header can carry the Run or Idle state; ODVA recommends the real time header method.

PUB00213R0 lists three triggers for producing I/O: cyclic (the most common, at the RPI), change of state (send when a value changes, plus a background heartbeat so the connection does not time out) and application (rare, similar to change of state). It also defines three kinds of I/O connection:

• Exclusive Owner. A bidirectional class 0 or 1 connection to an output assembly. Only one scanner may control those outputs.
• Input Only. The scanner receives input data; it sends only a heartbeat back.
• Listen Only. Like Input Only, but it can only attach to an existing Exclusive Owner or Input Only connection, and it closes or times out when that underlying connection does.

For security, note that I/O packets are not acknowledged and, in classic EtherNet/IP, nothing authenticates their sender beyond the connection ID and sequence number. Anyone who can see the stream can read the values.

RPI and connection timeouts

The Requested Packet Interval is how often each side of an I/O connection produces data. Wireshark's CIP dissector decodes cip.cm.otrpi and cip.cm.torpi in every Forward Open and displays them in milliseconds after dividing the raw value by 1,000, so the field is carried in microseconds.

Each connection also has a timeout multiplier, whose eight encoded values Wireshark labels times 4 through times 512. If nothing arrives within the RPI scaled by that multiplier, the connection times out and both ends take their configured fault action. The exact rule, including how a target rounds an RPI it cannot meet, is in the non public CIP Networks Library, so check your device manual before relying on a precise figure.

Worked example 1: a fast I/O rack. An Exclusive Owner connection runs a 10 ms RPI both ways with the multiplier encoded as 0 (times 4). The adapter expects a controller packet at least every 40 ms. That is 1,000 divided by 10, or 100 packets per second each way, 200 for one connection. If the controller goes quiet for 40 ms, the conveyor outputs drop to their fault state.

Worked example 2: a slow analog module. A 100 ms RPI with the multiplier encoded as 2 (times 16) gives 100 times 16, or 1,600 ms, before timeout. That tolerance hides short network glitches, but a stream can stop for over a second before anything alarms. List each connection's RPI and multiplier next to the physical consequence of a timeout; long timeouts on outputs that move things are a safety conversation.

Worked example 3: multicast load. Ten consumers want the same input assembly at a 5 ms RPI. As unicast the producer sends 10 streams of 200 packets per second, 2,000 in total. As multicast it sends 200 and the switches replicate them, which is why multicast is common on EtherNet/IP.

How a connection gets set up: Forward Open

All connections on EtherNet/IP are established with a UCMM Forward_Open message, per PUB00123R1. The device that sends it is the originator (usually a controller, which ODVA calls a scanner); the device that accepts it is the target (an adapter, drive or another controller). The originator sends Forward_Open (service 0x54, or Large_Forward_Open 0x5B for big data sizes) to the target's Connection Manager, class 0x06, instance 1, inside a SendRRData encapsulation on TCP 44818.

PUB00123R1 lists what a Forward_Open carries:

• Timeout information, and the network connection IDs for each direction.
• The originator's vendor ID and serial number.
• Maximum message sizes, unicast or multicast, and the trigger (cyclic, change of state or application).
• An optional electronic key, so the target can check it is the right kind of device.
• The connection path to the data, usually assembly instances.
• An optional configuration data segment, which is how a configuration assembly gets written at connection time.
• Optional routing information if the connection crosses networks.

The target's reply confirms the connection IDs and packet intervals. I/O then flows on UDP 2222 until Forward_Close (0x4E) or a timeout.

Walkthrough of a single I/O connection

1. The controller opens TCP 44818 to the adapter and sends RegisterSession (0x0065); the adapter returns a session handle.
2. Inside SendRRData (0x006F), the controller sends Forward_Open to class 0x06, instance 1, asking for 10 ms RPIs, unicast outputs, multicast inputs and the adapter's output, input and configuration assemblies.
3. The adapter checks the electronic key, applies the configuration data, and replies with the connection IDs.
4. Both sides produce on UDP 2222. A third device can add a Listen Only connection to the same input stream.
5. Forward_Close (0x4E) ends it cleanly; otherwise the adapter times out after the RPI times the multiplier.

Multicast versus unicast I/O

PUB00123R1 says originator to target I/O is typically unicast, while target to originator I/O can be multicast or unicast, and that multicast lets other EtherNet/IP devices listen to the input data. It then makes a specific recommendation: use switches that support IGMP snooping so that multicast frames do not propagate too widely. ODVA's infrastructure guide PUB00035R0 adds that IGMP snooping needs at least one IGMP querier somewhere on the network, which a router or capable switch can provide. Without snooping, a switch floods multicast to every port in the VLAN, loading devices that never asked for the data.

Where only one consumer exists, a unicast target to originator connection keeps I/O traffic predictable and much easier to firewall. Multicast is still the right answer for genuinely shared data, but confine it to a VLAN with an IGMP querier and snooping switches. Whether multicast I/O can cross a router depends on device settings and your routers; check the device manual and test before you design around it.

What List Identity reveals, and why EtherNet/IP devices are easy to enumerate

PUB00123R1 says the ListIdentity command "typically is sent as a broadcast UDP message" asking every device for its identity, and that tools use it to browse a network. It needs no session and no credentials. The reply mirrors the Identity object, and Wireshark's ENIP display filters show exactly what leaks:

The Nmap enip-info script documentation lists the same fields and sends the identity request to TCP 44818.

Three properties make enumeration trivial on a flat network. Discovery is a broadcast, so one packet reaches every device in the broadcast domain. Classic CIP has no authentication: ODVA's own threat model in PUB00319R2 says every user and attacker has "the highest access privilege that the object is designed to support." And the firmware revision is on the wire, ready to match against advisories. CISA's joint Primary Mitigations to Reduce Cyber Threats to Operational Technology makes the internet version of the point: OT devices are "quickly found by searching for open ports" on public IP ranges, and TCP 44818 is such a port.

None of this means blocking List Identity everywhere; engineering tools and your own inventory depend on it. The goals are a small broadcast domain, a known list of hosts that send List Identity, and an alert when anything else does.

What CIP Security adds

PUB00319R2 states the goal: make the CIP device able to defend itself as one layer of defence in depth, rejecting altered data (integrity), messages from untrusted people or devices (authenticity) and disallowed actions (authorization). Its assumptions echo zero trust: the network is untrusted, people and devices are untrusted until authenticated, and access waits for the device's authorization. Physical access is out of scope. CIP Security is Volume 8 of The EtherNet/IP Specification and currently focuses on EtherNet/IP.

Secure transport: TLS, DTLS and port 2221

ODVA's CIP Security page says it uses TLS (RFC 5246) for TCP traffic (encapsulation, UCMM and class 3 connections) and DTLS (RFC 6347) for UDP class 0 and 1 I/O, much as HTTPS uses TLS. IANA lists ethernet-ip-s on port 2221, "EtherNet/IP over TLS" for TCP and over DTLS for UDP, registered on 28 May 2015, and Wireshark treats 2221 as the secure port. The transport authenticates both endpoints with X.509 certificates or pre-shared keys, protects integrity with the TLS HMAC, and encrypts only when configured to, since confidentiality is optional.

RFC 5246 is TLS 1.2 and RFC 6347 is DTLS 1.2. We could not confirm from public ODVA material whether later editions of Volume 8 add TLS 1.3 or DTLS 1.3, so check the edition your devices conform to.

The CIP Security profiles

ODVA groups capabilities into profiles so buyers can see what a product supports. PUB00319R2 lists five:

Two discrepancies matter. The EtherNet/IP Integrity Profile now survives only as a subset of Confidentiality, so a device advertising "Integrity" alone probably follows an earlier revision. And ODVA's current CIP Security web page lists only the first four profiles, omitting Device-Based Firewall; we could not tell from public material whether that is editorial or a change in status, so confirm it per product. PUB00319R2 also notes that authorization is "fixed" (predefined roles) today, with flexible policy left as future work, and that no profile yet provides change detection for audit.

Device identity and certificates

Device identity is an X.509v3 certificate or a pre-shared key; PUB00319R2 says pre-shared keys suit simpler installations and devices. Certificates scale but put a private key on the device, so a replacement needs a new certificate. The Pull Model fixes that: the new device finds an enrollment service through DNS-SD and requests its certificate over EST, so a technician can swap hardware without a security engineer on site.

User authentication

The CIP User Authentication Profile brings people into the model. ODVA's page says it uses OpenID Connect, either with an external identity provider or with users held inside the device for small systems. That ends the situation the threat model describes, where every network user has the device's highest privilege.

What CIP Security does not do

• It does not force itself on a network. PUB00319R2 requires CIP Security devices to interoperate with non-secure ones and leaves the mix to end user configuration and responsibility.
• It protects only devices that implement and enable it, not the installed base or anything bridged onto DeviceNet or ControlNet.
• Encryption is optional, so integrity only links still expose values.
• It does not fix software flaws in the stack or the TLS library. CISA's ICSA-21-105-02, for example, covers crafted packet parsing flaws in an EtherNet/IP stack.

Configuring CIP Security in practice

Screens differ by vendor tool, so plan by property:

1. Inventory capability per device from vendor documentation, the EDS file and ODVA's CIP Security product listings.
2. Choose the trust model: pre-shared keys for a small static cell, certificates from a plant CA for anything larger, with the CA in the industrial DMZ or a security zone, backed up.
3. Choose integrity or confidentiality per conduit, knowing encryption reduces what monitoring can see.
4. Commission one cell in a lab and confirm connections establish on 2221 and I/O still meets its RPI.
5. Turn off non-secure access on secured devices where the profile allows it, and block 44818 to them at the conduit.
6. Test a device swap end to end, with the Pull Model if supported, and record certificate expiry dates in your change process.

Comparison: EtherNet/IP, PROFINET, Modbus TCP and OPC UA

Ports come from our IANA lookups; details for the other protocols summarise our sibling posts linked above, which carry their primary sources. Each protocol was designed for networks assumed to be isolated and added security later as an option, so plan for a mix.

Step by step: capture, map and segment EtherNet/IP in a lab

This walkthrough is read only and passive except for one single host identity request. Run it in a lab or a test cell, never on a live production line without approval from whoever owns the process. Even reads can load small devices, and some older devices are known to misbehave under unexpected traffic.

Step 1: set up a mirror port and capture

Configure a switch port mirror (SPAN) from the cell's uplink or the controller's port to a capture laptop. Passive capture puts nothing on the wire. Then capture only EtherNet/IP traffic:

# List interfaces and pick the one connected to the mirror port
tshark -D

# Capture EtherNet/IP explicit (44818), I/O (2222) and CIP Security (2221) traffic
sudo tshark -i en7 \
  -f "tcp port 44818 or udp port 44818 or udp port 2222 or tcp port 2221 or udp port 2221" \
  -w enip-lab.pcapng

Wireshark registers its ENIP dissector on TCP and UDP 44818 and its CIP I/O dissector on UDP 2222, and it treats 2221 as the secure port, so traffic on the standard ports decodes automatically. Traffic on 2221 will show as TLS or DTLS; you will see the handshake and certificates (for TLS 1.2) but not the CIP content, which is the point.

Step 2: read the conversation with display filters

Open the capture and work through these filters. All field names come from Wireshark's ENIP and CIP display filter references.

enip                               # all EtherNet/IP encapsulation traffic
enip.command == 0x0063             # List Identity requests and replies
enip.command == 0x0065             # RegisterSession
enip.command == 0x006f             # SendRRData (unconnected explicit)
enip.command == 0x0070             # SendUnitData (connected explicit)
cip.sc == 0x54 || cip.sc == 0x5b   # Forward_Open and Large_Forward_Open
cip.sc == 0x4e                     # Forward_Close
cip.sc == 0x10                     # Set_Attribute_Single (a write)
cip.class == 0x04                  # anything touching an Assembly object
cip.cm.otrpi || cip.cm.torpi       # requested packet intervals in Forward_Open
enip.cpf.sai.connid                # I/O packets by connection ID

Wireshark masks the response bit out of cip.sc, so a request and its reply show the same service code; add cip.rr (the request or response flag) to tell them apart, and confirm in the packet details pane.

Step 3: build an inventory from List Identity replies

If an engineering tool browsed the network while you were capturing, every device's identity is already in the file. Extract it to CSV:

tshark -r enip-lab.pcapng -Y "enip.command == 0x0063 && enip.lir.name" \
  -T fields -E header=y -E separator=, -E quote=d \
  -e ip.src -e enip.lir.vendor -e enip.lir.devtype -e enip.lir.prodcode \
  -e enip.lir.revision -e enip.lir.serial -e enip.lir.name \
  | sort -u > enip-inventory.csv

This gives you vendor, device type, product code, firmware revision, serial number and product name for every responding device, without sending a packet yourself. Compare the revision column with the vendor's advisories and CISA ICS advisories for those products.

Step 4: confirm one device with a single identity request

If a device did not appear passively, you can ask it directly, one host at a time. The Nmap documentation gives this usage for its enip-info script, which sends the identity request and parses the reply:

# One lab host only; this sends a read-only identity request to port 44818
nmap --script enip-info -sU -p 44818 192.0.2.10

Do not sweep subnets on a production network. If you must do active discovery at scale, agree a window with operations, rate limit it, and prefer the vendor's own engineering tool, which the plant already trusts.

Step 5: map who talks to whom

Now build the communication map that your segmentation will be based on:

# Explicit messaging: which clients talk to which servers on 44818
tshark -r enip-lab.pcapng -q -z conv,tcp -Y "tcp.port == 44818"

# I/O streams: UDP 2222 conversations, including multicast destinations
tshark -r enip-lab.pcapng -q -z conv,udp -Y "udp.port == 2222"

# Who opened which connections, with requested intervals
tshark -r enip-lab.pcapng -Y "cip.sc == 0x54 || cip.sc == 0x5b" \
  -T fields -E header=y -e ip.src -e ip.dst -e cip.cm.otrpi -e cip.cm.torpi \
  -e cip.cm.timeout_multiplier

The result should be a short list of controllers (originators), their adapters and drives (targets), the HMIs and engineering workstations that use explicit messaging, and the multicast groups in use. Anything you cannot explain goes on a list to investigate before you write a single firewall rule.

Step 6: design zones and conduits

The ISA/IEC 62443 series, in particular Part 3-2 (Security risk assessment for system design), groups assets with similar security needs into zones and allows traffic between zones only through defined conduits. NIST SP 800-82r3 covers OT topologies and countermeasures along the same defence in depth lines. For a typical EtherNet/IP plant:

A minimal example for an nftables firewall in front of one cell; adjust addresses and test in the lab first:

# Example only: cell 10.20.1.0/24, engineering 10.20.9.0/24, HMI 10.20.2.15
nft add table inet cell1
nft add chain inet cell1 fwd '{ type filter hook forward priority 0; policy drop; }'
nft add rule inet cell1 fwd ct state established,related accept
nft add rule inet cell1 fwd ip saddr 10.20.9.0/24 ip daddr 10.20.1.0/24 tcp dport '{ 44818, 2221 }' accept
nft add rule inet cell1 fwd ip saddr 10.20.2.15 ip daddr 10.20.1.0/24 tcp dport 44818 accept
nft add rule inet cell1 fwd udp dport '{ 2222, 44818, 2221 }' log prefix "enip-xzone " drop

Keep UDP 2222 inside the cell on its own VLAN with IGMP snooping and a querier. If a supervisory system needs I/O values, give it a gateway or historian connection rather than stretching the cell's multicast domain.

Step 7: monitor what you cannot yet secure

Most plants will run classic CIP for years. Against the Step 5 baseline, alert on List Identity from unexpected hosts, Forward_Open from a new originator, writes (Set_Attribute_Single or writes to Assembly configuration instances) from hosts that only ever read, and any 44818, 2222 or 2221 traffic crossing the enterprise boundary. The Step 2 filters let you prototype each rule before choosing monitoring tooling.

What CISA and NIST have published that applies to EtherNet/IP

Two CISA ICS advisories serve as dated examples of the defensive guidance:

• ICSA-21-056-03, Logix controllers (25 February 2021; Update A, 18 March 2021). CISA describes a flaw that could let an unauthenticated party connect to the listed controllers and alter configuration or code, which the vendor said could not be patched. Mitigations include isolating control networks and "restricting or blocking traffic on TCP 44818" from outside the ICS zone, and the advisory states that CIP Security mitigates the issue through TLS and DTLS with certificates or pre-shared keys.
• ICSA-21-105-02, EIPStackGroup OpENer (15 April 2021). OpENer is an open source EtherNet/IP stack for I/O adapter devices. CISA lists four crafted packet vulnerabilities in commits before 10 February 2021, leading to denial of service or data exposure; the fix was to apply the latest commits. An EtherNet/IP stack is software with its own patch history, often shared across products.

CISA's primary mitigations guidance puts removing OT from the public internet first. NIST SP 800-82r3 (September 2023) is the main US guide to OT security; NIST posted the Revision 4 initial public draft on 21 September 2026, with comments due 30 November 2026.

Common mistakes

• Exposing TCP 44818 to the internet, often through a "temporary" remote support port forward. Use a secured jump path instead.
• Leaving devices in "no security" mode after a CIP Security capable upgrade. Capable is not configured; track the configured state.
• Enabling CIP Security but leaving 44818 open, so an attacker just uses the old port.
• Flat networks with multicast I/O everywhere. Without VLANs and IGMP snooping, every stream reaches every port and the whole plant is one List Identity broadcast domain.
• No change control on Assembly configurations. Configuration assemblies and Forward_Open data segments change device behaviour without touching controller logic. Back them up and review writes.
• Long timeouts on outputs that move things. Review RPI and multiplier with the people who own safety.
• Treating CIP Security as a substitute for segmentation. ODVA built it for mixed networks as one layer of defence in depth.
• Forgetting certificate lifecycle. A plant CA on a laptop is a single point of failure.
• Sweeping production subnets with active scans. Capture passively first; query single hosts with approval.

FAQ

What is the difference between EtherNet/IP and CIP?

CIP, the Common Industrial Protocol, is the application layer: objects, services, connections and device profiles. EtherNet/IP is the network that carries CIP over standard Ethernet and TCP/IP. DeviceNet, ControlNet and CompoNet carry the same CIP over other physical layers. ODVA maintains all of them.

What ports does EtherNet/IP use?

IANA registers TCP and UDP 44818 for EtherNet/IP messaging (explicit messages and encapsulation commands such as List Identity) and TCP and UDP 2222 for EtherNet/IP I/O, which in practice is UDP implicit messaging. Port 2221 is registered for EtherNet/IP over TLS (TCP) and over DTLS (UDP), used by CIP Security.

What is the difference between explicit and implicit messaging?

Explicit messages are request and response, each naming the service and object they act on, and run over TCP 44818 for configuration, diagnostics and HMI reads. Implicit messages are cyclic I/O over UDP 2222 with a format agreed at connection time, so each packet carries only a connection ID, a sequence number and data, produced at the RPI.

What is RPI in EtherNet/IP?

The Requested Packet Interval is how often each side of an I/O connection produces data, set in the Forward Open. Wireshark shows it in milliseconds. If no packet arrives within the RPI scaled by the connection's timeout multiplier, the connection times out and the device applies its fault action.

Is EtherNet/IP secure?

Classic EtherNet/IP has no authentication or encryption; ODVA's own threat model says every user effectively has the highest privilege an object supports. CIP Security adds TLS and DTLS, device identity, user authentication and integrity, but only on devices that support and enable it. Segmentation and monitoring remain essential.

What are the CIP Security profiles?

ODVA's PUB00319R2 lists five: the EtherNet/IP Confidentiality Profile (which includes the EtherNet/IP Integrity Profile as a subset), the CIP User Authentication Profile, the Resource-Constrained CIP Security Profile, the Pull Model Profile and the Device-Based Firewall Profile. ODVA's current web page lists the first four.

Why can anyone discover EtherNet/IP devices on a network?

The List Identity encapsulation command is normally sent as a UDP broadcast and every device answers with vendor, device type, product code, firmware revision, serial number and name, without a session or credentials. On a flat network, one packet inventories the whole plant.

How do I find EtherNet/IP devices without disrupting them?

Capture passively from a mirror port while an engineering tool browses the network, then extract the List Identity replies with tshark. For a missing device, send one identity request to that single host, for example with Nmap's enip-info script, and avoid sweeping production subnets.

Where Safeguard fits

Safeguard does not sit on the plant network, does not inspect EtherNet/IP traffic and does not scan device firmware, so it is not a replacement for segmentation, CIP Security or OT monitoring. The fit is the software around EtherNet/IP that your teams build and ship: edge collectors, protocol gateways running in containers, historian connectors, test harnesses and in house tools that embed open source protocol libraries, including open source EtherNet/IP stacks like the one in CISA's ICSA-21-105-02. Safeguard scans those repositories, container images and SBOM files (safeguard scan --dir ., --image <name> and --sbom <file> from the CLI), matches components against vulnerability databases, uses reachability analysis to rank what your code actually calls, shows which projects contain a given component and version, and evaluates policies and gates in the platform. Autonomous remediation can open fix pull requests where a fixed version exists, and it ships switched off. For devices you buy, ask suppliers for an SBOM; if they provide one, Safeguard can analyse that file like any other.

The EtherNet/IP stack in a controller is the vendor's to fix, but the gateways, collectors and tools your own teams write around it pull in open source libraries, and those are yours to keep current. The steps below apply to that software, and the fork and patch path described at the end is generally available.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. For OT teams this is the natural way to scan a gateway or collector project on an engineering network where code should not leave the site.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: the assistant reads a finding and its advisory, asks before any command that changes something, edits package.json to a fixed lodash version, runs the install and tests with approval, and pushes nothing. The same approve each step flow suits a protocol gateway repository, where a dependency bump should be tested before it goes anywhere near a cell.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude may use. That lets an engineer ask in plain language which of the team's projects carry a given library version, using read only tools.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• ODVA: EtherNet/IP technology page
• ODVA: Common Industrial Protocol (CIP) technology page
• ODVA: CIP Security technology page
• ODVA: Document library
• ODVA PUB00123R1: The Common Industrial Protocol (CIP) and the Family of CIP Networks (February 2016)
• ODVA PUB00138R8: EtherNet/IP technology overview
• ODVA PUB00319R2: Overview of CIP Security At a Glance
• ODVA PUB00213R0: EtherNet/IP Quick Start for Vendors Handbook (2008)
• ODVA PUB00035R0: Network Infrastructure for EtherNet/IP, Introduction and Considerations
• IANA: Service Name and Transport Protocol Port Number Registry (44818, 2222, 2221, 502, 4840, 4843, 34964)
• Wireshark: EtherNet/IP display filter reference
• Wireshark: CIP display filter reference
• Wireshark source: EtherNet/IP dissector (packet-enip.c)
• Wireshark source: CIP dissector (packet-cip.c)
• Wireshark source: CIP service code definitions (packet-cip.h)
• Nmap NSE documentation: enip-info
• CISA ICSA-21-056-03: Logix Controllers (Update A)
• CISA ICSA-21-105-02: EIPStackGroup OpENer EtherNet/IP
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• ISA: ISA/IEC 62443 Series of Standards
• OpENer: open source EtherNet/IP stack on GitHub

Last reviewed: 25 October 2026. The EtherNet/IP Specification, CIP Security profiles, ISA/IEC 62443 parts and NIST SP 800-82 are all under active revision; check the pages above for the edition your devices and auditors actually use.