CIP Security Explained: TLS, X.509, and OT Cybersecurity

Ten years ago, OT cybersecurity meant “air gap the control network.” That model failed. Modern industrial systems need controllers talking to MES systems, drives reporting to cloud analytics, engineering tools accessing devices remotely. The air gap is gone — and with it, the security model that depended on physical isolation. CIP Security is the ODVA-defined answer for CIP networks: a security architecture built on standard IETF cryptographic protocols (TLS, DTLS, X.509) that protects CIP communications against unauthorized access, tampering, and eavesdropping.

This article explains how CIP Security works: what it protects against, how it integrates standard internet security protocols into CIP, how device authentication and certificate management function, and what engineers need to consider when deploying it. CIP Security is the foundation for IEC 62443-compliant CIP installations and a critical component of modern OT/ICS cybersecurity strategy.

For broader CIP context, see the CIP Protocol Complete Guide and our Industrial Cybersecurity Pillar. For complementary CIP architecture coverage, see the CIP Object Model Explained article.

What CIP Security is in one paragraph

CIP Security is ODVA’s specification for securing CIP communications on industrial networks. Defined in Volume 8 of the CIP Networks Library (first published 2015 and continuously revised), CIP Security provides three security capabilities: device authentication (each device proves its identity using X.509 certificates), data integrity (every CIP message is cryptographically protected against tampering), and confidentiality (CIP traffic can be encrypted to prevent eavesdropping). CIP Security uses TLS (Transport Layer Security) for TCP-based CIP communications on port 44818, DTLS (Datagram TLS) for UDP-based cyclic I/O traffic on port 2222, and X.509 certificates for device identity. It is the security foundation for modern CIP networks targeting IEC 62443 compliance.

Why CIP Security exists

For decades, industrial control networks relied on physical isolation — the air gap — for security. Plant networks didn’t connect to corporate IT, and corporate IT didn’t connect to the internet. If an attacker couldn’t physically reach the network, the network was secure.

That model is gone. Modern industrial systems need:

• MES and ERP integration — production data flows to enterprise systems
• Cloud analytics and remote support — vendors monitor and service equipment over WANs
• Engineering access — programmers connect remotely to maintain code
• Operator interfaces — HMIs and SCADA on commodity Windows machines
• Cybersecurity standards compliance — IEC 62443, NIST CSF, NERC CIP, NIS2 directive in Europe

Each of these breaks the air gap. The result: industrial control systems that were never designed for hostile network environments are exposed to attackers who can now reach them. Historical attacks (Stuxnet, BlackEnergy, Triton) targeted exactly these systems.

CIP Security exists because ODVA recognized this shift and designed a security architecture built on the protocol layer — rather than relying on perimeter security alone. The principles:

1. Defense in depth — multiple security layers, not just network perimeter
2. Trust no one by default — every CIP message authenticates the sender
3. Use standard cryptography — TLS, DTLS, X.509 — not proprietary mechanisms
4. Backward compatibility — secure and non-secure devices can coexist during migration
5. IEC 62443 alignment — fits within the ISA/IEC 62443 security framework

The result is a security architecture that integrates seamlessly with existing IT security practices (certificate management, TLS handshakes) while protecting CIP-specific traffic at the protocol level.

For more on IEC 62443, see our IEC 62443 Explained article.

The three security objectives

CIP Security addresses three classic security objectives often called the CIA triad:

Authentication (who is talking?)

Every CIP Security-enabled device has an X.509 certificate that cryptographically proves its identity. When devices establish a CIP Security session, they exchange certificates and verify them against a trusted certificate authority. A PLC connecting to a drive can confirm “this is actually drive serial number XYZ from Vendor A” — not an attacker pretending to be that drive.

Integrity (has the message been tampered with?)

Every CIP message in a CIP Security session carries a cryptographic Message Authentication Code (MAC) — a value computed using a shared secret derived during the TLS/DTLS handshake. If an attacker modifies a message in transit, the MAC fails verification and the recipient drops the message. This protects against man-in-the-middle modifications without necessarily requiring encryption.

Confidentiality (can anyone read this?)

When confidentiality is needed, CIP Security can encrypt the traffic using AES (or other negotiated ciphers). Process data, configuration parameters, and any other CIP content becomes unreadable to anyone without the session keys. The encryption is optional — many CIP Security deployments use authentication + integrity without encryption when network bandwidth and compute resources are tight.

These three objectives can be applied selectively per connection. A configuration session might require full encryption; a cyclic I/O connection might use authentication + integrity only; a discovery broadcast might be unprotected.

The protocol stack — where CIP Security fits

CIP Security sits between the EtherNet/IP encapsulation layer and the CIP application layer:

┌─────────────────────────────────────────────────────┐
│         CIP Application Objects                     │
│   (Identity, Assembly, Connection Manager, etc.)    │
├─────────────────────────────────────────────────────┤
│         CIP Security Layer                          │
│   (Authentication, Integrity, Confidentiality)      │
├─────────────────────────────────────────────────────┤
│   TLS (TCP 44818)         DTLS (UDP 2222)           │
├─────────────────────────────────────────────────────┤
│   TCP                     UDP                       │
├─────────────────────────────────────────────────────┤
│   IP                                                │
├─────────────────────────────────────────────────────┤
│   Ethernet                                          │
└─────────────────────────────────────────────────────┘

CIP messages flow through TLS (for TCP-based traffic) or DTLS (for UDP-based traffic) before reaching the network. The application layer doesn’t change — CIP services and objects work the same way. The security is below the application, transparent to most application code.

This architectural choice has important consequences:

• No CIP application code changes required to add security
• Same Forward_Open, same Identity Object, same Assembly Object — security wraps them
• Same port numbers — TLS uses TCP 44818, DTLS uses UDP 2222
• Same engineering tools — Studio 5000 etc. work over CIP Security transparently

For more on the underlying CIP transport, see our EtherNet/IP Encapsulation Protocol Explained and EtherNet/IP I/O Messaging on UDP Port 2222 articles.

TLS for TCP messaging

CIP Security uses standard IETF TLS (Transport Layer Security, RFC 5246 / RFC 8446) for TCP-based CIP communications on port 44818. This is the same TLS that protects HTTPS websites, secure email, and most internet traffic. CIP Security doesn’t define a new cryptographic protocol — it uses the same standard the entire internet uses.

The TLS handshake:

1. Client sends ClientHello — proposes cipher suites, sends client certificate
2. Server sends ServerHello — selects cipher suite, sends server certificate
3. Mutual authentication — both sides verify each other’s certificates against trust authorities
4. Key exchange — both sides derive shared session keys
5. Application data flows — protected by negotiated cipher suite

Once the TLS session is established, all subsequent CIP encapsulation traffic flows over the TLS connection. Forward_Open, explicit messaging, ListIdentity, RegisterSession — everything that normally rides over TCP 44818 now rides over TLS over TCP 44818.

Common cipher suites for CIP Security TLS:

• AES-128-GCM with ECDHE — modern, efficient, widely supported
• AES-256-GCM with ECDHE — stronger encryption, higher compute cost
• TLS_NULL_WITH_NULL_NULL — no encryption (integrity + authentication only)

The “null encryption” suites are critical for industrial use — they provide authentication and integrity without the compute and bandwidth cost of encryption. Many CIP Security deployments use null encryption with strong MAC for cyclic I/O traffic, then full encryption for occasional configuration sessions.

DTLS for UDP I/O traffic

TLS works only over reliable transports (TCP). For cyclic I/O on UDP port 2222 (where reliability is provided by CIP’s connection management, not the transport), CIP Security uses DTLS (Datagram Transport Layer Security, RFC 6347 / RFC 9147).

DTLS is essentially TLS adapted for unreliable, packet-oriented transports. It provides the same security guarantees as TLS but works on UDP:

• DTLS handshake — completed during connection establishment (often piggy-backed onto Forward_Open)
• Per-packet protection — each UDP datagram is independently authenticated/encrypted
• Replay protection — sequence numbers prevent attackers from replaying captured packets
• Connection migration handling — IP address changes don’t break the DTLS session

DTLS is essential for cyclic motion control or fast I/O where TCP’s reliability mechanisms would add unacceptable latency. The CIP Sync / CIP Motion architecture (see our CIP Sync Explained and CIP Motion Explained articles) relies on UDP — and CIP Security protects those UDP packets via DTLS.

A critical consideration: DTLS adds per-packet overhead (typically 13-25 bytes per packet for MAC + IV + padding). For tightly-loaded high-speed networks, this overhead must be factored into bandwidth calculations.

X.509 certificates in CIP

CIP Security uses standard X.509 certificates (RFC 5280) for device identity — the same certificate format used throughout the internet, in HTTPS, in S/MIME email, in VPN authentication.

An X.509 certificate contains:

• Subject — who this certificate identifies (typically the device’s CIP Identity)
• Issuer — who signed this certificate (the trust authority)
• Public key — the cryptographic public key
• Serial number — unique within the issuer’s namespace
• Validity period — Not Before / Not After dates
• Extensions — additional metadata (key usage, alternative names, etc.)

Two cryptographic algorithms dominate for CIP Security certificates:

• RSA-2048 or RSA-3072 — classic public-key crypto, slower but well-understood
• ECDSA P-256 or P-384 — elliptic curve crypto, smaller signatures, better performance on embedded devices

ECDSA is becoming the preferred choice for embedded industrial devices because of its smaller key sizes (256-bit ECC ≈ 3072-bit RSA in security strength) and lower compute requirements.

Vendor certificate (also called Birth Certificate)

Many CIP Security devices ship with a vendor-installed certificate — a unique X.509 certificate provisioned at manufacturing time. This certificate identifies the device uniquely and can be used to bootstrap trust during initial commissioning. It’s analogous to the IEEE 802.1AR “DevID” concept (Secure Device Identity, also called IDevID).

When you receive a new CIP Security device, its birth certificate is already inside it. You don’t need to provision identity from scratch — you just need to enroll the device into your specific trust domain (typically by getting a domain-specific certificate signed by your organization’s CA, which then becomes the device’s operational certificate).

The CIP Security object classes

CIP Security introduces several new CIP object classes to manage security policies, certificates, and authentication. The key objects:

CIP Security Object (Class 0x5D)

The central security configuration object. Holds general security policies for the device:

• Security profile in use
• Enable/disable per-protocol security
• Trust authority configuration
• General-purpose security attributes

Engineers configure overall device security behavior through this object’s attributes.

EtherNet/IP Security Object (Class 0x5F)

EtherNet/IP-specific security configuration:

• TLS and DTLS settings
• Cipher suites enabled
• Active sessions
• Per-protocol security policies

This object specifically handles the EtherNet/IP adaptation of CIP Security. CIP networks running over other transports (DeviceNet, ControlNet) have their own security adaptation objects in their respective volumes.

Certificate Management Object (Class 0x5E)

X.509 certificate lifecycle management:

• Certificate storage
• Certificate enrollment
• Certificate renewal
• Certificate revocation list (CRL) processing

This object exposes services for installing new certificates, retrieving existing certificates, and managing the certificates’ lifecycles.

File Object (Class 0x37)

The pre-existing CIP File Object is heavily used by CIP Security to store certificate files. Certificates are large binary objects (often 1-2 KB each), so they’re stored as files rather than as attribute values directly. The File Object provides upload/download operations for these files.

For more on the broader CIP object framework, see our CIP Object Model Explained article.

Certificate provisioning — Pull, Push, and EST

Getting certificates installed on devices is the most operationally challenging part of any PKI deployment. CIP Security supports three approaches:

Pull provisioning

The device requests its certificate from a provisioning server. The device knows its own birth certificate, knows the address of the provisioning server, and asks: “Please give me an operational certificate for this domain.”

Pull provisioning works well when the device can be configured with the provisioning server address before being deployed. It minimizes manual handling during commissioning — the device just connects to the server and gets enrolled.

Push provisioning

A configuration tool pushes the certificate to the device. The engineer generates or obtains a certificate, then uses an engineering tool (Studio 5000, vendor-specific tool) to write the certificate to the device’s Certificate Management Object.

Push provisioning works well for offline commissioning — the device doesn’t need network access to a provisioning server. The tradeoff: more manual handling per device.

EST (Enrollment over Secure Transport, RFC 7030)

The IETF standard protocol for certificate enrollment, adopted by CIP Security. EST defines:

• How a device requests certificates from a CA
• How the CA validates the request
• How certificates and CRLs are delivered
• How certificate renewals work

EST runs over HTTPS, so it can leverage existing IT infrastructure. ODVA aligned CIP Security with EST specifically because it lets industrial deployments use the same certificate management infrastructure that enterprise IT already uses. Engineers managing TLS certificates for the corporate website can use the same CA, same enrollment protocols, same tools for managing CIP Security certificates.

This is one of the strongest design choices in CIP Security — avoiding the trap of inventing a new industrial-specific certificate management protocol that would require dedicated tools and skills.

User authentication and role-based access

Beyond device-to-device authentication, CIP Security defines user authentication — verifying who is operating an engineering tool that’s accessing a device. This is critical because devices may need different access levels for different operators:

CIP Security can encode the user identity in the X.509 certificate used during the TLS/DTLS handshake. The certificate’s Subject field identifies the user, and the device validates against an internal role assignment.

This is what enables modern operational practices like:

• Engineering tools authenticate as the logged-in user — not as the generic “engineer” account
• Audit trails — devices log which user made which changes
• Role-based command authorization — operator-level access can’t change firmware; engineer-level can
• Privileged access management integration — the user’s role comes from corporate Active Directory

For a complementary discussion of OT security frameworks, see our OT Security Explained article.

Coexistence with non-secure devices

Few brownfield CIP installations can replace every device simultaneously. CIP Security recognizes this and supports mixed environments:

• CIP Security-enabled devices establish TLS/DTLS connections with each other
• Non-secure devices continue using unencrypted CIP — same TCP 44818 and UDP 2222 ports
• Security policy at each device decides whether to accept non-secure connections

A typical migration path:

1. Install CIP Security-capable controller and engineering tools
2. Replace or upgrade critical devices (drives, safety controllers) with CIP Security capability
3. Configure security policies to require CIP Security for the upgraded devices
4. Leave less-critical devices unencrypted until they’re replaced in normal life-cycle
5. Eventually transition the network to require CIP Security universally

The flexibility means CIP Security adoption can be phased — not all-or-nothing. A plant can secure its most critical assets first (controllers, safety systems) and progress over years.

That said, partial deployment doesn’t fully secure the network. An attacker who can reach the unsecured devices can still compromise those devices. The progression matters for the migration period, not as a permanent state.

Deployment considerations and IEC 62443 alignment

Real-world CIP Security deployment requires planning beyond just turning on TLS:

Certificate authority infrastructure

You need a trusted certificate authority (CA) to sign your devices’ operational certificates. Options:

• Use the corporate CA — leverages existing IT PKI infrastructure (best for IEC 62443 compliance)
• Use a vendor-provided CA — Rockwell, Siemens, and others offer industrial PKI services
• Use an internal industrial CA — dedicated to OT systems, managed by OT team

Each option has tradeoffs in operational complexity, IT/OT coordination, and audit requirements.

Network architecture impacts

CIP Security doesn’t replace network segmentation — it complements it. IEC 62443 still requires:

• Conduits between security zones
• Demilitarized zones (DMZ) between IT and OT
• Firewalls filtering traffic between zones

CIP Security secures traffic within zones; firewalls and DMZ structure define the zones themselves. The two layers work together.

Performance impact

TLS and DTLS add CPU overhead and bandwidth:

• TLS handshake — adds 100-500ms to connection establishment (one-time per connection)
• Per-packet overhead — typically 13-25 bytes per packet for DTLS
• Encryption/decryption CPU — varies by cipher suite and device CPU capability

On modern industrial devices (recent PLCs and drives), the overhead is manageable. On older devices retrofitted with CIP Security, performance may degrade noticeably — especially for high-speed I/O.

IEC 62443 alignment

CIP Security aligns with IEC 62443-3-3 (System Security Requirements) Security Levels 2-4:

For more on IEC 62443 mechanics, see our IEC 62443 Explained article.

CIP Security vs other industrial security protocols

How CIP Security compares to alternative industrial protocol security:

CIP Security’s strength is its alignment with standard IETF protocols (TLS, DTLS, EST) — meaning industrial security can use the same tools and skills as enterprise IT security. This reduces operational friction and accelerates adoption.

For PROFINET security comparison, see our PROFINET vs EtherNet/IP article.

Common CIP Security deployment issues

Frequently asked questions