Key takeaways
- Pull Model Profile — supports automated, certificate-based provisioning and ongoing credential management rather than manual configuration per device.
- Treat CIP messaging as unauthenticated unless CIP Security is confirmed deployed on both ends.
EtherNet/IP carries the Common Industrial Protocol (CIP) across a large share of North American discrete manufacturing, and CIP's core messaging has no built-in authentication unless a site has deployed ODVA's separate CIP Security extension — a gap documented not only in the specification's own framing but in a five-year run of CISA advisories against the Rockwell Automation controllers and adapters that speak it. ODVA has answered that gap with four CIP Security profiles since the mid-2010s, but the CISA record shows the most severe recent failures sit in places CIP Security was never designed to reach: unauthenticated debug ports and packet-parsing bugs, not just stolen or guessed credentials.
A sourcing note: ODVA's CIP Security page and press release are fetched directly as rendered HTML; ODVA's "CIP Security At a Glance" PDF (PUB00319R2) is listed as a source but this guide's fetch tooling could not render it as extractable text, so the profile descriptions below rely on ODVA's HTML page, cross-checked against the press release. CISA's three advisories are fetched directly from cisa.gov. Confirm exact profile requirements against ODVA's own specification volumes before citing this guide as authoritative on any single requirement.
Why CIP has no authentication, by design
CIP and the EtherNet/IP network that carries it were standardized by ODVA in 2000, building on Rockwell Automation's existing Allen-Bradley protocols, with real-time determinism and broad interoperability as the design goals — not authentication. CIP's explicit messaging (request/response, used for configuration and diagnostics) and implicit messaging (cyclic I/O data) both run over standard TCP/UDP port 44818 and UDP port 2222 with no field in the base protocol for a credential or signature. Per ODVA's own CIP Security page, this is exactly why the extension exists: CIP and EtherNet/IP devices, left as originally specified, are exposed to attack, because any station that can reach the right port can send CIP messages a device will act on. That is a structural gap in the base protocol, not a configuration mistake in any single vendor's implementation — the same pattern documented across Modbus, DNP3, BACnet and PROFINET.
What that gap costs: three documented CISA findings
| Advisory | CVE | CVSS | Weakness | What happens |
|---|---|---|---|---|
| ICSA-21-056-03 | CVE-2021-22681 | v3 10.0 | CWE-522, Insufficiently Protected Credentials | Unauthenticated attacker bypasses the verification key securing Logix controller communication, enabling unauthorized configuration or application-code changes across multiple ControlLogix/CompactLogix/GuardLogix families |
| ICSA-26-195-04 | CVE-2026-10577 | v3.1 / v4.0 both 10.0 | CWE-306, Missing Authentication for Critical Function | Unauthenticated, network-reachable debug port on the 1715-AENTR EtherNet/IP adapter lets a remote attacker read or delete files, stop tasks, modify memory and change I/O states |
| ICSA-26-167-03 | CVE-2026-11317 | v3.1 7.5 | CWE-404, Improper Resource Shutdown or Release | A single crafted CIP message crashes CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570 and GuardLogix 5570 controllers into a major nonrecoverable fault |
The first is a credential-bypass flaw that CIP Security's authentication model was designed to prevent — Rockwell's own advisory names CIP Security's TLS/DTLS transport as the compensating control, since the underlying verification-key mechanism itself could not be patched. The second and third are not authentication failures at all: a debug interface left exposed outside CIP messaging, and a packet-parsing bug triggered by a malformed but otherwise-valid CIP message. Spanning 2021 to 2026 and multiple Logix and adapter product lines, this is a recurring pattern in how the platform handles both its own security model and the messages it was built to process — not an isolated defect in one model.
CIP Security's four profiles: what each actually adds
Per ODVA's CIP Security page and its 2021 press release on resource-constrained devices, CIP Security forms Volume 8 of the EtherNet/IP specification and comprises:
EtherNet/IP Confidentiality Profile— the core profile, securing endpoint-to-endpoint communication for data integrity and confidentiality using TLS (RFC 5246) over TCP-based traffic and DTLS (RFC 6347) over UDP-based traffic, with endpoints authenticated via X.509 certificates or pre-shared keys. This is the profile Rockwell's advisory points to as mitigating CVE-2021-22681. CIP User Authentication Profile— adds authentication of the human or application user initiating CIP communication, including support for OpenID Connect, layered on top of the device-level trust the Confidentiality Profile establishes. Resource-Constrained CIP Security Profile(added 2021) — lets smaller embedded EtherNet/IP devices implement DTLS alone, without the overhead of full TLS, so low-power or low-memory field devices can still participate in CIP Security rather than being left unsecured for cost reasons. Pull Model Profile— supports automated, certificate-based provisioning and ongoing credential management rather than manual configuration per device.
None of these profiles are mandatory for a device to carry EtherNet/IP certification — a vendor chooses whether to implement them, and a site chooses whether to deploy them on a given network. ODVA also publishes material tying CIP Security to IEC 62443-4-2 component requirements, which this guide could not independently verify in detail since the relevant PDF could not be rendered as extractable text; treat that alignment as a direction to confirm against ODVA's own certification documentation, not a substitute for IEC 62443-4-2's own component requirements.
A workable starting point
Treat CIP messaging as unauthenticated unless CIP Security is confirmed deployed on both endsThe base protocol has no credential check; the Confidentiality Profile only protects a connection once both the controller or adapter and its peer implement it. Patch to the firmware versions named in CISA's advisories firstCVE-2026-10577 and CVE-2026-11317 are device- and implementation-layer bugs that no CIP Security configuration substitutes for — only the vendor-fixed firmware closes them. Segment before anything elseKeep EtherNet/IP traffic inside the control network, behind an industrial DMZ, with no path from business IT or the internet — see the Purdue Model for OT/ICS network architecture for the segmentation pattern this implements. Restrict CIP's known ports specificallyWhere a managed switch or firewall can filter at this level, limit TCP/UDP 44818 and UDP 2222 to the engineering workstations and HMI systems that genuinely need CIP access, and block inbound CIP traffic from any untrusted segment. Deploy CIP Security on new and replacement hardwareFor the credential and transport-layer gaps it was built to close — the class CVE-2021-22681 falls into — CIP Security is the direct fix; for debug-port and packet-parsing bugs like the 2026 CVEs, network-layer controls and vendor patches remain the real security model.
CIP's authentication gap is not something any one profile can retroactively close across an installed base that has not deployed it, and the 2026 advisories show the newer problem is not authentication at all — it is implementation bugs in debug interfaces and message parsing that only a firmware update fixes. NIST SP 800-82's OT security guidance and IEC 62443-3-3's system security requirements both treat these layered, network-level compensating controls as the baseline for industrial protocols generally, EtherNet/IP and CIP included, alongside Modbus, DNP3, BACnet and PROFINET. SoftWSP's OT Snapshot builds a passive, factual picture of which devices on a shop floor are actually speaking EtherNet/IP, and to whom, from a mirror port, without touching production traffic: see OT Snapshot.
This guide draws on ODVA's own CIP Security page and press release (fetched directly) and CISA's three published ICS advisories (fetched directly), cross-checked against each other where ODVA's underlying specification PDFs could not be rendered as extractable text. This guide is not a substitute for ODVA's own CIP Security specification volumes, CISA's or Rockwell Automation's own advisories, or an engineer's assessment of a specific network.
Sources
- ODVA: CIP Security — EtherNet/IP Confidentiality Profile, CIP User Authentication Profile, Resource-Constrained profile, TLS/DTLS
- ODVA: "CIP Security Enhanced to Support Resource-Constrained EtherNet/IP Devices" (press release, April 2021)
- ODVA: "CIP Security At a Glance" technology overview (PUB00319R2, PDF)
- CISA ICS Advisory ICSA-21-056-03 (Update A): Rockwell Automation Logix Controllers — CVE-2021-22681
- CISA ICS Advisory ICSA-26-195-04: Rockwell Automation 1715-AENTR EtherNet/IP Adapter — CVE-2026-10577
- CISA ICS Advisory ICSA-26-167-03: Rockwell Automation Logix Controllers — CVE-2026-11317
- NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security (September 2023)
- CISA: Recommended Practices (control systems network segmentation, defense-in-depth, minimizing network exposure)
Frequently asked questions
Does EtherNet/IP have authentication built in?
Not in the base protocol. EtherNet/IP is the Ethernet-based network that carries the Common Industrial Protocol (CIP) — the application-layer protocol ODVA (Open DeviceNet Vendors Association, now operating simply as ODVA) standardized in 2000 from a joint effort with Rockwell Automation. CIP's core messaging — the explicit and implicit messages a controller, HMI or I/O adapter exchanges over TCP/UDP port 44818 and UDP port 2222 — carries no credential, certificate or session key unless a device and its peer have both implemented ODVA's separate CIP Security extension. Per ODVA's own CIP Security page, the specification exists specifically because CIP and EtherNet/IP devices were otherwise exposed to attack: without it, any station that can reach that port can send CIP messages a device will act on.
What does CIP Security actually add?
Per ODVA's published CIP Security materials, CIP Security is not one feature but a set of profiles layered onto EtherNet/IP as Volume 8 of the EtherNet/IP specification. The EtherNet/IP Confidentiality Profile secures endpoint-to-endpoint communication for data integrity and confidentiality using TLS (RFC 5246) for TCP-based traffic and DTLS (RFC 6347) for UDP-based traffic, authenticating endpoints with X.509 certificates or pre-shared keys. The CIP User Authentication Profile adds user-level authentication (including OpenID Connect) on top of that device-level trust. ODVA added a Resource-Constrained CIP Security Profile in 2021 so smaller embedded devices can implement DTLS alone, without the overhead of full TLS, and a Pull Model Profile supports automated, certificate-based provisioning. None of these profiles are mandatory for a device to carry the EtherNet/IP name — a vendor has to choose to implement and a site has to choose to deploy them.
What do real, documented CIP/EtherNet/IP security failures look like?
CISA's ICS advisory archive shows a recurring pattern across Rockwell Automation's EtherNet/IP product lines, spanning five years. CVE-2021-22681 (CISA ICSA-21-056-03, CVSS v3 10.0, CWE-522 Insufficiently Protected Credentials) let an unauthenticated attacker bypass the verification key Studio 5000 Logix Designer uses to authenticate with Logix controllers, enabling unauthorized configuration or application-code changes across RSLogix 5000, Studio 5000 and multiple ControlLogix/CompactLogix/GuardLogix/DriveLogix/SoftLogix families — Rockwell's own advisory states patching the key mechanism itself was infeasible, and names CIP Security's TLS/DTLS transport as the compensating control. CVE-2026-10577 (CISA ICSA-26-195-04, published 14 July 2026, CVSS v3.1 and v4.0 both 10.0, CWE-306 Missing Authentication for Critical Function) is a network-reachable debug port on the 1715-AENTR EtherNet/IP adapter with no authentication at all, letting a remote attacker read or delete files, stop tasks, modify memory and change I/O states — fixed in firmware 3.011. CVE-2026-11317 (CISA ICSA-26-167-03, published 16 June 2026, CVSS v3.1 7.5, CWE-404 Improper Resource Shutdown or Release) shows a different failure mode: a single crafted CIP message crashes CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570 and GuardLogix 5570 controllers into a major nonrecoverable fault requiring a program download to recover, with lower-memory devices worse affected.
Would CIP Security have stopped all three of those CVEs?
No — and that distinction matters for prioritizing fixes. CVE-2021-22681 is explicitly a credential/authentication weakness, which is exactly what CIP Security's TLS/DTLS transport and endpoint authentication are built to close, per Rockwell's own advisory. CVE-2026-10577, by contrast, is an unauthenticated debug interface outside CIP messaging entirely — a device-level design flaw that only a firmware update removes; CIP Security secures CIP traffic, not an unrelated debug port left open on the same device. CVE-2026-11317 is a parsing/resource-handling bug triggered by a malformed but otherwise-valid CIP message — encrypting and authenticating the channel with CIP Security does not stop a legitimately-authenticated engineering workstation, or an attacker who has already reached one, from sending a message that crashes the controller's packet-handling code. Only the vendor-patched firmware versions close that specific hole, matching the same pattern documented across Modbus, DNP3, BACnet and PROFINET: cryptographic security and implementation-bug patching are separate problems, and a protocol extension that solves the first does nothing for the second.
What actually reduces EtherNet/IP and CIP risk today?
The same layered approach NIST SP 800-82 Revision 3 and CISA's recommended practices describe for every industrial protocol with optional security: segment EtherNet/IP traffic behind an industrial DMZ so controllers and adapters are never reachable from business IT or the internet; restrict TCP/UDP 44818 and UDP 2222 to the engineering workstations and HMI systems that actually need CIP access; patch to the vendor-fixed firmware named in each CISA advisory, since no amount of network segmentation closes a debug-port or packet-parsing bug by itself; and deploy CIP Security — at minimum the EtherNet/IP Confidentiality Profile — on new and replacement hardware that supports it, since it is the one control here that directly closes credential and transport-level gaps like CVE-2021-22681.
In this cluster
