Fast Facts
IEC 62443 certification is the main yardstick for industrial cybersecurity, but the badge only proves what it was issued for. On October 22, TÜV Rheinland certified ODVA’s CIP Security specification for EtherNet/IP to IEC 62443-4-2 at Security Level Capability 3. That certifies the specification, not any individual product.
This guide explains the standard’s parts, the difference between capability and target levels, and six questions to ask a vendor. It also covers where certification stops, including its relationship to the EU Cyber Resilience Act.
Procurement teams now see “IEC 62443” in nearly every industrial IoT datasheet. Without context, it reads as a pass mark. IEC 62443 certification is really a set of different certificates for suppliers, components and systems, and mixing them up is the most common buying error.
What IEC 62443 Certification Covers
According to TruvoCyber’s explainer, the standard splits by role. Part 4-1 covers a supplier’s secure development lifecycle, rated for process maturity. Part 4-2 sets technical requirements for components: embedded devices, host devices, network devices and software applications. Part 3-3 sets requirements for whole systems, which integrators deliver. Asset owners divide the plant into zones and conduits under part 3-2 and assign target levels.
Levels run from SL 1 to SL 4, matching countermeasures to adversary strength. Capability (SL-C) is what a component or system can deliver when configured as intended. Target (SL-T) is what the asset owner needs for a given zone. Certificates state capability, so a high SL-C does not mean your zone reaches its target. ISASecure offers SDLA for the development process, CSA for components, ICSA for IIoT components and SSA for control systems, run by ISO/IEC 17065 accredited bodies.
SL-C 3 | specification, not products | CRA main duties Dec 11, 2027
ODVA’s announcement covers the CIP Security specification, per ODVA. CRA dates per TruvoCyber: reporting from September 11, 2026 and main obligations from December 11, 2027.
What ODVA’s CIP Security Certificate Means
ODVA says the certification covers CIP Security, an application-layer extension of EtherNet/IP, and rates SL-C 3 as protection against attackers with moderate resources, industrial-control skills and moderate motivation. It covers data integrity, authentication, authorization and encryption through TLS and DTLS. ODVA says it lowers the barrier for manufacturers seeking their own certification. It names no certified products.
“Does not establish EU Cyber Resilience Act compliance on its own.”
— Red Tiger Security, on the CIP Security certificate
Red Tiger Security adds that the certificate covers the specification, not individual products or firmware, that the product-level certificate is the one that matters, and that CIP Security protects traffic only when it is enabled and configured. The CRA point matters now. See our analysis where we explain why CRA reporting obligations are live and most IIoT vendors aren’t ready. Red Tiger is a vendor advisory summarizing a press item, so treat its detail as commentary.
Six Questions to Ask Before You Trust the Badge
1. Which certificate is it? Process (4-1), component (4-2) or system (3-3)? Ask for the document, not the logo. 2. Which product and firmware version? A specification certificate does not travel to a device.
3. What SL-C, for which requirements? A level is a vector with a value per foundational requirement, per TruvoCyber. Ask for the vector. 4. Is the feature on by default? Security that must be enabled needs certificate and key management you must plan. See our analysis where we explain why industrial IoT protocol fragmentation hides a real lock-in cost.
5. Who certified it? Consultants prepare evidence but do not certify. 6. What is the update path? A certificate covers a release, and fixes change that. See our analysis where we explain why device lifecycle management is IIoT’s coming bill.
Where IEC 62443 Certification Stops
Certification does not replace segmentation or monitoring. Red Tiger recommends keeping zones, conduits and alerts for unexpected controller changes, since authentication alone does not stop a stolen credential. Lab results show why. See our analysis where we explain how the AI OT attack test went from firewall to controller in 16 minutes. TruvoCyber also notes the standard is voluntary and should not be assumed to satisfy the CRA.
Audits are driving adoption in many plants. See our analysis where we explain why audit-driven IIoT adoption is a crisis.
⚠️ Hypothetical scenario: A Lagos packaging plant buys a new drive because the datasheet says “IEC 62443.” The badge refers to the vendor’s development process, not the drive’s firmware, and the security feature ships switched off. A stolen engineering laptop reaches the line unchecked. The plant learns that IEC 62443 certification names a document, not a guarantee.
💡 CreedTec Analyst’s Note by Daniel Ikechukwu
Strategic Impact
The CIP Security result is a real step, because specification-level certification shortens the path for many EtherNet/IP vendors. But IEC 62443 certification will stay a vocabulary problem until buyers insist on product-level documents and configuration evidence.
Stop / Start / Watch
- Stop: accepting “IEC 62443 compliant” without a certificate number, scope and firmware version.
- Start: inventorying which devices support CIP Security and which firmware they run, then requiring product-level certificates in new specs.
- Watch: which vendors publish product certificates against the CIP Security specification, and CRA harmonised-standards guidance.
ROI Outlook
No cost or timeline figures were published for certification, so none are defensible here. For buyers, the saving from IEC 62443 certification evidence is avoiding an uncertifiable fleet that fails an audit or a CRA review later.
— Daniel Ikechukwu
