Access and communication controls that protect production

Protecting an EtherNet/IP network means planning who can connect, which actions they can perform and how operations will recover from a problem. Standard EtherNet/IP traffic is not automatically encrypted. Its use of Ethernet infrastructure does not make the network secure by default. An effective approach combines network boundaries, device protection, access permissions, monitoring and recovery.

Start with devices and required data flows

Record the model, firmware version, IP address, function and owner of each connected device. Include PLCs, HMIs, drives, remote I/O, switches and maintenance computers. Within the automation application, identify which lost connections would stop the machine and which write operations could change the process.

For each required flow, document its source, destination, direction, service and purpose. An HMI accessing process data does not require the same permissions as a maintenance computer downloading a PLC program. Use this record as the basis for firewall rules and subsequent changes.

Separate machine cells and control communication between them

Separate office systems, production cells and maintenance access into zones according to their needs. The zones and controlled communication paths used in the ISA/IEC 62443 approach help structure this design. Between zones, allow only explicitly defined communication. Design an appropriate industrial DMZ for enterprise data exchange and remote maintenance.

A VLAN alone is not an access policy. It provides logical separation; firewalls or suitable ACLs enforce permissions between zones. Consider the network layers separately: allowing an IP address is not the same as cryptographically verifying a device's identity.

Distinguish port access from permission to perform an action

In unencrypted communication, TCP 44818 is commonly used for explicit messaging and connection establishment, while UDP 2222 carries implicit I/O. UDP 44818 may also appear in services such as discovery. Filter ports and message types according to actual device requirements; these numbers are not a ready-made allowlist for the whole network.

Different CIP services can share the same port. Consequently, opening a port does not grant read-only access. An industrial firewall with suitable support can filter CIP services in greater detail. Verify the required services against the communication architecture; ordinary packet inspection cannot read encrypted application contents either.

Apply CIP Security across endpoints with an explicit policy

On compatible devices, CIP Security provides device authentication and message integrity, with data confidentiality depending on the selected profile and policy. It uses TLS for TCP-based communication and DTLS for UDP-based I/O. Enabling CIP Security does not necessarily mean that all traffic is encrypted.

Check hardware, firmware, software and profile support at both endpoints. During security configuration, define trusted devices, certificate or key management and any exceptions for unsecured connections. Plan time settings relevant to certificate validity and the renewal process. Secure communication may use TCP/UDP 2221, so match firewall rules to vendor documentation. An exception for an unprotected legacy device does not encrypt that connection.

Keep remote maintenance restricted and traceable

Do not expose PLCs or HMIs directly to the internet. Provide remote maintenance through a managed VPN, multifactor authentication and a controlled access point. A jump server in the DMZ can restrict access to engineering workstations. VPN access should not provide unrestricted access to production networks.

Use individual accounts, task-specific permissions and time-limited maintenance access. Log sessions and changes, then remove temporary permissions when the work is complete. Avoid separate, forgotten modems or remote access routes for individual suppliers.

Harden devices and engineering workstations

Change default passwords and separate operator, maintenance and administrator roles where supported. Disable unnecessary web, file-transfer and management services. Check dependencies before removing a service used for commissioning. Protect engineering software, project files and maintenance computers too: compromising an authorized computer can bypass a network boundary.

A PLC's operating mode or physical key switch may restrict certain changes; verify the scope for the specific model. Control physical access to cabinets, switches, unused network ports and field connections. Before disabling a port, check whether it serves a redundant path or ring network.

Measure the impact of security changes on I/O

Test new rules or encryption policies in a suitable environment first. Assess latency and packet loss, I/O updates, connection re-establishment and device load. Preserve the required flows for multicast I/O, time synchronization and redundant topologies where these are used.

IGMP snooping and QoS do not replace authentication. They manage traffic distribution and priority. For example, restricting program downloads must preserve the required communication between the running PLC and remote I/O. Have a rollback plan for rule changes.

Make monitoring, patching and recovery part of operations

Use diagnostics and monitoring to track new devices, unexpected connections, failed logins and program changes. Consider passive observation first for sensitive OT devices; schedule active scanning according to maintenance plans and device suitability. Define who receives alerts and who is responsible for responding.

Follow vendor security advisories and apply patches through compatibility testing and planned maintenance. Keep protected backups of PLC programs, HMI projects, drive parameters and network rules. Testing restoration is as important as creating backups. Decide in advance which connections can be isolated during an incident and under what conditions production can restart. Base the response on the process's safe state rather than disconnecting networks or power indiscriminately.