Background

EtherNet/IP (Ethernet Industrial Protocol) is an industrial communication protocol developed by Rockwell Automation and managed by the Open DeviceNet Vendor Association (ODVA). It carries the Common Industrial Protocol (CIP) over standard Ethernet and TCP/UDP, making it the preferred protocol for integrating Allen-Bradley PLCs (ControlLogix, CompactLogix, MicroLogix), industrial robots, variable frequency drives, and smart sensors in North American manufacturing environments.

Unlike Modbus and DNP3 — which were built for serial links and retrofitted to Ethernet — EtherNet/IP was designed for Ethernet from the start. It operates on two transport modes: explicit messaging (TCP port 44818, request/response for configuration and data reads) and implicit messaging (UDP port 2222, cyclic/event-driven for real-time control). The protocol has broad adoption: hundreds of thousands of installed devices in automotive manufacturing, food and beverage, pharmaceuticals, oil and gas, and increasingly energy infrastructure.

Like its predecessors, EtherNet/IP in its default form has no authentication and no encryption. CIP specifies an optional security extension — CIP Security — but adoption remains limited in deployed infrastructure.

The CIP Protocol Attack Surface

No Authentication on Explicit Messaging

Any device that can reach port 44818 on a CIP-capable device can send CIP commands. The protocol accepts explicit messages — which include commands to read attributes, write attributes, reset the device, and reconfigure parameters — without authentication.

This means that from an attacker’s perspective, access to the OT network segment is equivalent to access to the PLCs and controllers on that segment. There is no second authentication boundary. An attacker who pivots from IT to the OT VLAN and reaches port 44818 can:

  • Read all device attributes and configuration parameters
  • Write to configurable parameters including setpoints, motion profiles, and safety parameters (on devices that allow it)
  • Perform a Forward Open to establish a cyclic connection for real-time I/O data manipulation
  • Issue device reset commands, returning PLCs to initial state and disrupting production

In lab demonstrations and the 2023 IEEE research paper “Attacks on EtherNet/IP and Migrations through CIP Security,” researchers demonstrated that command replay and parameter manipulation attacks against unprotected EtherNet/IP devices are straightforward with publicly available tooling.

Implicit Messaging Attack Surface

UDP port 2222 carries real-time I/O data in EtherNet/IP implicit messaging — the “scanner” (typically a controller or PLC) sends cyclic output data to a device (the “adapter”), and the device returns input data cyclically. The connection is established via a Forward Open request over explicit messaging.

The implicit messaging attack surface includes:

  • I/O data injection: A device able to spoof UDP packets to port 2222 can inject fabricated I/O data into existing implicit connections, potentially causing a controller to act on false sensor readings
  • Connection hijacking: By monitoring and replaying Forward Open sequences, an attacker may be able to establish or interfere with I/O connections
  • DoS via connection flooding: EtherNet/IP devices have a limited number of supported concurrent connections. Flooding with Forward Open requests can exhaust the connection table, denying access to legitimate controllers

A CISA advisory from 2026 noted Mitsubishi MELSEC iQ-F EtherNet/IP modules are vulnerable to denial of service via continuous UDP packets, requiring a manual system reset to recover — a pattern that affects multiple vendor implementations.

Feature Expansion and Attack Surface Growth

Modern EtherNet/IP devices increasingly include embedded web servers, FTP servers, and SNMP agents for configuration and asset management. Each additional service is an additional attack surface. A device that previously presented only port 44818 may now also offer:

  • HTTP/HTTPS on port 80/443 for web-based configuration (with default credentials or no authentication)
  • FTP on port 21 for firmware upload/download
  • SNMP with community strings set to “public” by default

Penetration testers routinely find that the FTP and HTTP interfaces on EtherNet/IP devices have independent, often weaker security postures than the primary CIP interface. Firmware extraction via FTP has been used to identify hardcoded credentials and unpatched vulnerabilities in several published disclosures.

Known CVEs and Vulnerabilities

Rockwell Automation has published security advisories for ControlLogix and CompactLogix series PLCs addressing several CIP-related vulnerabilities:

CVE-2022-1161 / CVE-2022-1159 (Rockwell ControlLogix, CompactLogix): These vulnerabilities in the Studio 5000 Logix Designer EDS file parsing allowed an attacker to modify the process logic executing on a controller without visible indication in the engineering tool. An operator viewing the running program would see correct-looking logic while the controller executed a modified version — a capability that echoes the Stuxnet approach.

CVE-2024-7507 (Rockwell Automation 5015-AENFTXT): A denial-of-service vulnerability where a malformed EtherNet/IP request causes device restart, disrupting I/O communications.

Multiple Siemens, ABB, and Schneider Electric products implementing CIP as a secondary protocol have had similar DoS and authentication bypass CVEs in recent years, reflecting that the protocol’s lack of built-in authentication means any implementation weakness has disproportionate impact.

CIP Security: The Extension That Would Help

ODVA published CIP Security in 2016 as an optional extension that adds:

  • TLS: encrypted communications for explicit messaging
  • DTLS: encrypted communications for implicit messaging (UDP)
  • Device-level authentication: certificate-based device authentication before connections are accepted
  • Integrity protection: HMAC-based message integrity for preventing injection attacks

CIP Security would, if deployed, address the fundamental authentication and confidentiality weaknesses. The problem is adoption. CIP Security requires:

  1. CIP Security-capable hardware (firmware versions that support TLS/DTLS and certificate management)
  2. A PKI infrastructure for device certificate issuance, rotation, and revocation
  3. Compatible engineering tools (Rockwell Automation’s Studio 5000 supports CIP Security configuration for compatible hardware)

Most deployed EtherNet/IP devices pre-date CIP Security support or are mid-lifecycle hardware that will not receive firmware enabling it. Greenfield deployments using current-generation hardware can implement CIP Security, but brownfield environments — which represent the vast majority of installed base — typically cannot without hardware replacement.

The practical timeline for meaningful CIP Security adoption in brownfield manufacturing environments is measured in years to decades, tied to equipment refresh cycles.

Network Hardening: Compensating Controls

Since protocol-level security is unavailable for most deployed infrastructure, network architecture becomes the primary control layer.

Segmentation and VLAN Isolation

EtherNet/IP devices should not be reachable from corporate IT networks, engineering workstations not specifically authorised for OT access, or any network segment accessible from the internet. The standard architecture:

  • OT devices on a dedicated VLAN with no default gateway to IT networks
  • Industrial DMZ (I-DMZ) or data diode between OT and IT networks for historian data flow
  • Explicit firewall rules permitting only the specific traffic required:
    • Authorised HMI/SCADA stations to controller port 44818 (explicit messaging)
    • Authorised controllers to device port 2222 (implicit messaging)
    • No inbound from IT or internet to OT VLAN

ACL/Firewall Policy for Port 44818

In environments where layer-7 industrial firewalls (Fortinet FortiGate-Rugged, Cisco IE switches with SGT/ACL, Claroty) are deployed, restrict explicit messaging access:

permit tcp <authorised_hmi_subnet> any eq 44818
permit tcp <engineering_workstation_ip> any eq 44818
deny   tcp any any eq 44818
deny   udp any any eq 2222
permit udp <authorised_controllers_subnet> <device_subnet> eq 2222

Passive Monitoring and Baselining

Deploy passive OT network monitoring (Claroty, Dragos, Nozomi Networks, Tenable.OT) to:

  • Build a baseline of all EtherNet/IP devices, their normal communication patterns, and expected cyclic I/O rates
  • Alert on new Forward Open connections (new I/O relationships appearing without change control)
  • Alert on explicit messaging to/from unexpected source addresses
  • Detect anomalous parameter writes and device reset commands

Passive monitoring is non-intrusive and does not require interrupting production processes to deploy.

Firmware and Patch Management

EtherNet/IP device firmware should be in patch management scope. While change control in OT environments means firmware updates happen less frequently than in IT, known CVEs with available patches should be scheduled for application during planned maintenance windows.

Maintain an asset inventory that includes firmware versions for all EtherNet/IP devices. Tenable.OT, Dragos, and Claroty can all enumerate device firmware versions passively from network traffic.

  1. Inventory: Identify all EtherNet/IP devices (port 44818/2222 traffic baseline) and document firmware versions
  2. Segmentation audit: Verify that EtherNet/IP devices are not reachable from corporate IT networks. Run a controlled test from an IT system attempting to reach port 44818 on OT devices
  3. Default credential check: Audit the web, FTP, and SNMP interfaces on EtherNet/IP devices for default or no credentials — these are separate from the CIP interface and often overlooked
  4. Firewall rules: Ensure only authorised controllers and HMI stations can reach port 44818/2222 on OT devices
  5. CIP Security assessment: For greenfield or upcoming hardware refresh projects, specify CIP Security support as a procurement requirement and plan the PKI infrastructure needed to support it
  6. Monitoring: If not already deployed, evaluate passive OT monitoring to baseline normal EtherNet/IP communication patterns
Tags
EtherNet/IPCIPAllen-BradleyRockwell Automationindustrial protocolPLCmanufacturingOT securityprotocol securityVLAN segmentation