CIP Security: A Certified Foundation for IEC 62443-4-2
At a Glance
TÜV Rheinland has certified the CIP Security™ Specification against IEC 62443-4-2:2019 Edition 1.0 up to Security Level Capability 3 (SL-C 3). The certificate was issued on 15 June 2026.
For vendors building products that implement CIP Security, this changes the economics of an IEC 62443-4-2 certification project. The communications security requirements of the standard — among the most technically demanding and expensive to design, implement and evidence — have now been independently assessed by an accredited certification body. Vendors inherit that work rather than repeating it.
With the EU Cyber Resilience Act (CRA) applying from December 2027, and with it highly likely that the European standardization work for industrial products will build on IEC 62443-4-2, that inheritance stands to become more valuable, not less.
An Independent Assessment of the Protocol Itself
Product certification against IEC 62443-4-2 is a substantial undertaking. A vendor must demonstrate, requirement by requirement, that a component provides the technical security capabilities the standard defines at the claimed security level. Where those requirements concern secure communications — user and device authentication, authorization enforcement and access rights, cryptographic key and certificate management, integrity and confidentiality of transmitted data, session management — the vendor has traditionally had to design the mechanisms, justify the cryptographic choices, document the behavior and defend all of it to an assessor.
TÜV Rheinland has now assessed CIP Security against IEC 62443-4-2 requirements. The assessment covered CIP Networks Library, Volume 8, CIP Security Specification Editions 1.19 to 1.21. It was performed under Certification Program CERT CS1 V3.0:2021.
The assessment concluded that CIP Security Specification Editions 1.19 to 1.21 meet the applicable requirements of IEC 62443-4-2:2019 Edition 1.0 up to Security Level Capability 3, and that the specification can be used in the development of components to secure communication up to SL-C 3.
The practical consequence for a product supplier is straightforward. The requirements that CIP Security addresses no longer must be argued from first principles. The vendor implements the specification, demonstrates conformance through ODVA, and brings a certified foundation into their own certification project.
The comparison that matters is not between what CIP Security covers and what the standard contains in total. It is between CIP Security and alternative security protocols. A vendor implementing a proprietary or uncertified secure communications mechanism receives no credit for any of the communications-related requirements. Every one of them must be designed, documented and defended from scratch. A vendor implementing CIP Security starts from an independent assessment by an accredited body.
| What this certificate is — and what it is not
It is an accredited certification body’s assessment that the CIP Security protocol specification fulfils the IEC 62443-4-2 requirements applicable to a security communication protocol, up to SL-C 3. It is not a certification of any product. A device that implements CIP Security is not thereby certified to IEC 62443-4-2. The product supplier must still certify their own product. It is not a substitute for a secure product development lifecycle. No full assessment against IEC 62443-4-1 was performed, because the object under inspection is a specification rather than a product developed under a lifecycle process. Vendors still need their own product assessment. |
A Short Introduction to IEC 62443
IEC 62443 is the leading international standard series for the security of industrial automation and control systems (IACS). Rather than a single document, it is a family of standards organized into four groups, addressing different audiences and different components of the industrial automation security.
The General group establishes concepts, terminology and models. The Policies and Procedures group addresses the security program requirements of asset owners and service providers. The System group covers system-level security requirements and security levels for a system under consideration. The Component group addresses those who build the products from which systems are assembled.
The series distributes responsibility across three roles. Asset owners operate the installation and are accountable for its security program. System integrators design and commission the automation solution. Product suppliers develop the components. Security is achieved when all three do their part; no single role can deliver comprehensive defense alone.
The two parts most relevant to product suppliers are IEC 62443-4-1 and IEC 62443-4-2.
IEC 62443-4-1 and IEC 62443-4-2: Process and Product
These two parts of the standard are frequently confused, and the difference is fundamental.
IEC 62443-4-1 specifies requirements for the secure product development lifecycle. It is about how a product is developed: security requirements definition, secure design, secure implementation practices, verification and validation testing, defect and vulnerability management, patch management and product end-of-life. It assesses an organization’s development process, and its results are expressed as maturity levels. It says nothing about what security features the resulting product contains.
IEC 62443-4-2 specifies the technical security requirements for IACS components. It is about what the product does: whether it can authenticate users, enforce authorization, protect the integrity and confidentiality of data, resist denial of service, and so on. It assesses the product itself, and its results are expressed as security levels.
Both are needed. A rigorous development process that produces a product without security capabilities helps nobody; a product with capabilities that were developed carelessly cannot be trusted to have implemented them correctly. This is why the two parts are normally pursued together, and why IEC 62443-4-2 certification schemes generally expect evidence of a secure development lifecycle alongside the technical assessment.
The TÜV Rheinland assessment of CIP Security did not include a lifecycle assessment. The object under inspection is a security protocol specification, not a device developed by a manufacturer following a standardized security development lifecycle process, and IEC 62443-4-1 was therefore out of scope of the assessment. Relevant extracts from IEC 62443-4-1 were taken into account where they applied to the functional assessment.
This point deserves emphasis because it is the most likely source of misunderstanding. IEC 62443-4-1 applies to product suppliers developing products. The protocol specification is not a product, and ODVA is not a product supplier. Vendors implementing CIP Security must still establish and maintain their own secure product development lifecycle — whether certified to IEC 62443-4-1, aligned to it, or built on an equivalent framework such as NIST SP 800-218. The CIP Security certificate does not and cannot substitute for it.
Where the CIP Security Certification Fits
IEC 62443-4-1 assesses the development process. IEC 62443-4-2 assesses the product. The CIP Security certification addresses IEC 62443-4-2 only.
IEC 62443-4-1 was out of scope of the assessment, because the object under inspection is a protocol specification rather than a product developed under a lifecycle process. Vendors implementing CIP Security still need their own secure product development lifecycle, whether certified to IEC 62443-4-1 or built on an equivalent framework.
Understanding Security Level Capability
IEC 62443 defines four security levels, distinguished by the nature of the threat each is intended to withstand. The levels are cumulative: each builds on the one below.
| Level | Protects against | Attacker profile |
| SL 1 | Casual or coincidental violation | No particular intent, skill or resources |
| SL 2 | Intentional violation using simple means | Low resources, generic skills, low motivation |
| SL 3 | Intentional violation using sophisticated means | Moderate resources, IACS-specific skills, moderate motivation |
| SL 4 | Intentional violation using sophisticated means with extended resources | Extended resources, IACS-specific skills, high motivation |
The standard applies these levels in three distinct ways, and the distinction matters when reading any certificate.
Security Level Capability (SL-C) describes what a component or system is capable of when properly configured. It is a property of the product or, in this case, of the specification. It says nothing about how a particular installation is set up.
Security Level Target (SL-T) is the level an asset owner requires for a given zone or conduit, determined by risk assessment.
Security Level Achieved (SL-A) is the level a specific installation actually reaches once deployed, configured and operated.
The TÜV Rheinland certificate addresses SL-C. It states that the mechanisms defined in CIP Security are capable of meeting the applicable requirements up to security level capability 3. Whether a given plant achieves SL 3 depends on the products selected, the architecture, the configuration and the operational practices around them.
“Up to SL-C 3” also warrants precision. IEC 62443-4-2 assigns individual requirements and requirement enhancements to specific security levels; a component does not meet a security level by satisfying a single blanket criterion. A claim of SL-C 3 means the applicable requirements at levels 1 through 3 have been satisfied. It does not mean that every requirement in the standard has been assessed, nor that requirements assigned only to SL 4 have been met.
CIP Security and the Scope of the Assessment
CIP Security is the network extension that provides security services for EtherNet/IP™ and CIP™ networks. It defines how devices establish trust, authenticate one another, and protect the data they exchange.
The assessment covered the CIP Security capabilities as defined in Volume 8 of the CIP Networks Library, including:
- The EtherNet/IP Confidentiality Profile, which protects communications using TLS and DTLS with authentication by X.509 certificates or pre-shared keys.
- The CIP Security User Authentication Profile, which provides identification and authentication of human users, software processes and devices, with role-based access control and integration with external identity providers via OpenID Connect and OAuth 2.0.
- Certificate and key management, including public key infrastructure support through X.509 certificates and Enrolment over Secure Transport (EST), and symmetric key authentication using standard TLS and DTLS cipher suites.
- Device and configuration capabilities relevant to the standard, including the Ingress Egress Object for controlling incoming and outgoing communications, and machine-readable reporting of current security settings through the CIP Security objects.
Because the object under inspection is a protocol specification rather than a device, cybersecurity testing and threat modelling were determined not to be applicable and were not performed.
The certificate covers the editions listed in the currently valid Revision List, which ODVA maintains in cooperation with the certification body. This mechanism allows subsequent editions of the specification to remain within the scope of the certificate.
Foundational Requirements and Assessment Results
IEC 62443-4-2 organizes its requirements under seven foundational requirements, together with a set of Common Component Security Constraints. The results of the assessment across these categories are shown below.
| Reading this table correctly
“Not applicable” here has a specific and limited meaning. It signifies that the requirement lies outside what a communications protocol can address — it belongs to the device, the application or the system architecture rather than to the protocol. The report is explicit: requirements addressing embedded devices, host devices, network devices or software applications are not applicable to a protocol specification. These requirements remain fully applicable to any product a vendor certifies. They cannot be carried over as “not applicable” into a product assessment. |
| Category | Covered by CIP Security | Not applicable to a protocol | Where the remaining requirements are addressed |
| Common Component Security Constraints 1 | 2 | 9 | Device platform, system context |
| FR 1 — Identification and authentication control | 14 | 9 | Device hardware, wireless interfaces, local user interface |
| FR 2 — Use control | 8 | 14 | Audit and logging subsystem, time source, device interfaces |
| FR 3 — System integrity | 7 | 14 | Device platform: secure boot, firmware update, tamper resistance, input validation |
| FR 4 — Data confidentiality | 2 | 3 | Storage and memory management (data at rest) |
| FR 5 — Restricted data flow | 0 | 6 | Network architecture, zones and conduits, network devices |
| FR 6 — Timely response to events | 0 | 3 | Device logging, monitoring and reporting functions |
| FR 7 — Resource availability | 4 | 7 | Device resource management, backup and recovery, power design |
| Table footnotes:
1 – The Common Component Security Constraints are assessed as a separate category alongside the seven foundational requirements. Excluding them, the assessment covered 91 requirements and requirement enhancements, of which 35 were determined to be within the scope of the protocol. |
|||
Each category was concluded with a positive result. For every category containing applicable requirements, the assessment found that the mechanisms defined in CIP Security fulfil the requirements of IEC 62443-4-2 at Security Level Capability 3.
What CIP Security Covers
The requirements within scope cluster where a communications security protocol naturally operates.
Identification and authentication control (FR 1) is the most extensively covered category. CIP Security provides identification and authentication for human users, software processes and devices. Authentication mechanisms include passwords, tokens and biometrics, with integration into external identity providers or local account storage. Password complexity, lifetime parameters and limits on unsuccessful login attempts are configurable, and locked accounts require administrator intervention to release. Public key infrastructure is supported through X.509 certificates and Enrolment over Secure Transport, and symmetric key authentication through standard TLS and DTLS cipher suites.
Use control (FR 2) is addressed through role-based authorization enforcement applied consistently to human users, software processes and devices. Roles are defined for security-related operations, and vendors may define additional roles and permissions. The protocol supports remote session termination, concurrent session control, configurable session timeouts, and temporary privilege escalation of defined duration for emergency scenarios.
System integrity (FR 3) is addressed for transmitted information and communication sessions. TLS 1.2 and DTLS provide message authentication codes based on the SHA-2 family, protecting against insertion, deletion, delay, re-sequencing and replay. The protocol authenticates the origin of received data, and supports root-of-trust capabilities through vendor certificates, including provisioning of both product supplier and asset owner roots of trust.
Data confidentiality (FR 4) is addressed for data in transit. The EtherNet/IP Confidentiality Profile protects communication channels using TLS and DTLS with confidentiality-based cipher suites.
Resource availability (FR 7) is addressed to the extent a protocol can. CIP Security supports closing unused TCP and UDP ports and IANA protocols such as ICMP, separates messaging and I/O communication onto distinct ports to reduce attack surface, and allows all interfaces to require authentication and authorization. The Ingress Egress Object enables rules controlling incoming and outgoing communications, including restricting or disabling unnecessary functions, ports and protocols. Security settings and their defaults are documented, and current settings can be retrieved in machine-readable form.
What Remains the Vendor’s Responsibility
The requirements determined not applicable to CIP Security are not gaps in the protocol. They are requirements that belong to the product. A communications protocol has no boot process to protect, no firmware to update, no enclosure to make tamper-resistant, and no audit log to retain.
The “not applicable” determinations in this assessment do not transfer to products. A requirement marked not applicable to a communications protocol remains fully applicable to the device that uses it.
These fall into recognizable groups.
Device platform security. Integrity and authenticity of the boot process, support for authenticated and integrity-protected updates, physical tamper resistance and detection, protection from malicious code, security functionality verification, software and information integrity, input validation, deterministic output, and hardware security for authenticators and keys.
Audit, logging and monitoring. Auditable events, audit storage capacity and threshold warnings, response to audit processing failures, protection of audit information, audit log accessibility, continuous monitoring, timestamps and time source integrity, and non-repudiation. Together these account for the whole of FR 6 and a substantial share of FR 2.
Data at rest. Information persistence, erasure of shared memory resources, and erase verification.
Resource and availability management. Denial of service protection and communication load management, resource management, backup and recovery, emergency power, and component inventory.
Network architecture. Network segmentation, zone boundary protection, and general purpose person-to-person communication restrictions. These constitute FR 5 and are properties of the system design and of network devices rather than of an application protocol.
Interfaces outside the protocol. Wireless access management, use control for portable and mobile devices, session lock, authenticator feedback, system use notification, access via untrusted networks, and physical diagnostic and test interfaces.
For FR 5 and FR 6, where no requirements fell within the protocol’s scope, the assessment reached a specifically positive conclusion: use of CIP Security does not violate or hinder an application in fulfilling these requirements, and no deviations or non-conformities were identified. The protocol stays out of the way of the architecture the asset owner and integrator establish.
What This Means for a Product Certification Project
A vendor certifying a product that implements CIP Security follows a clear path.
Implement CIP Security according to the specification. The certificate applies to the specification as published in the editions listed in the Revision List. The certificate’s own conditions note that it is valid within the dedicated security context documented in the associated specification documents and user guides, and that the instructions in those guides must be followed. An implementation that diverges from the specification does not inherit the assessment.
Demonstrate conformance through ODVA. The ODVA Conformance Authority issues a conformance certificate and a detailed conformance report identifying exactly which CIP Security capabilities the product supports. This is the evidence a vendor provides to their own assessor, and it establishes that the product genuinely implements the specification that was certified.
Reference the TÜV Rheinland certification for the protocol’s contribution. The certificate is publicly available and can be verified directly with TÜV Rheinland. Where an assessor requires the underlying assessment detail, ODVA members may request the full report.
Address the remaining requirements in the product. The categories listed in the previous section as being not applicable to the protocol still belong to the vendor. Nothing about the CIP Security certification reduces or alters them.
Maintain a secure product development lifecycle. IEC 62443-4-2 certification schemes expect evidence of secure development practices. This remains the vendor’s responsibility.
Monitor for vulnerabilities. The certificate specifies that ODVA’s support portal should be monitored periodically for product-related security vulnerabilities.
Relevance to the EU Cyber Resilience Act
The EU Cyber Resilience Act applies to all products with digital elements placed on the European market. From 11 September 2026, manufacturers must have vulnerability and incident reporting processes in place. From 11 December 2027, every digital product made available in the EU must meet the CRA’s requirements, regardless of when it was developed. Any manufacturer selling into Europe is affected, wherever they are based.
The CRA is a legal framework rather than a technical specification. Its essential requirements are given effect through harmonized standards, which confer a presumption of conformity. Under standardization request M/606, accepted by CEN, CENELEC and ETSI in April 2025, a substantial program of harmonized standards is being developed. For industrial automation, that work builds directly on the IEC 62443 series: CENELEC is adapting EN IEC 62443-4-2:2019 and EN IEC 62443-4-1:2018 to the CRA framework, and the 62443 series is emerging as the central technical reference for CRA compliance in industrial settings.
That work is still in progress, and the final form of the harmonized standards and their citation in the Official Journal remain ahead. What is already clear is the direction of travel. For manufacturers of industrial devices, capability against IEC 62443-4-2 is becoming the practical technical baseline for demonstrating CRA compliance.
The CIP Security certification therefore arrives at a useful moment. Several of the CRA’s product requirements — secure by default configuration, protection against unauthorized access, and the confidentiality and integrity of transmitted data — align closely with the areas CIP Security addresses, and are now backed by an accredited certification body’s assessment against the standard the European work is built upon. Vendors implementing CIP Security are building on a foundation that has already been independently evaluated against IEC 62443-4-2.
The CRA’s remaining obligations — technical and end-user documentation, secure development practices, vulnerability handling, and SBOM management — remain with the manufacturer. CIP Security is a valuable tool for CRA compliance, not a route around it.
Summary
TÜV Rheinland has certified the CIP Security Specification, Editions 1.19 to 1.21, against IEC 62443-4-2:2019 Edition 1.0 up to Security Level Capability 3. Certificate No. 968/CSP 1074.00/26 was issued on 15 June 2026.
What was certified is a protocol specification, not a product. IEC 62443-4-2 is a product standard, and a communications protocol is one layer within a product. CIP Security covers the applicable protocol layers — identification and authentication, authorization enforcement, communication integrity, confidentiality of data in transit, and the configuration capabilities that support least functionality — and it has been independently assessed as meeting those requirements at SL-C 3. The requirements outside that scope belong to the device, the application and the system architecture, and remain the responsibility of the product supplier.
The value to vendors is concrete. The communications security requirements of IEC 62443-4-2 are among the most demanding in the standard to design, implement and prove. A vendor implementing CIP Security inherits an accredited assessment of the protocol. A vendor implementing an uncertified network does not. Combined with an ODVA conformance certificate identifying exactly what a product supports, this gives vendors a substantially shorter path to their own IEC 62443-4-2 certification.
As the CRA’s application date approaches and the European harmonized standards for industrial products take shape around the IEC 62443 series, that advantage grows. Manufacturers selling into the European market will need to demonstrate the technical security capabilities of their products against a recognized baseline. CIP Security offers a foundation for doing so that has already been evaluated against that baseline by an accredited certification body.
The 968/CSP 1074.00/26 certificate is publicly available from TÜV Rheinland, https://fs-products.tuvasi.com/certificates?keywords=968%2FCSP%201074&productcategory_id=1#prodid_14316. ODVA members may request the full assessment report.
CIP, CIP Security, and EtherNet/IP are trademarks of ODVA, Inc.
Trademarks not belonging to ODVA, Inc. are the property of their respective companies
CIP Security: A Certified Foundation for IEC 62443-4-2 (Pub 365)