Login
Book a demo

IEC 62443 for product vendors: obligations across the industrial supply chain

IEC 62443 for product vendors: obligations across the industrial supply chain

IEC 62443 is a supply chain standard as much as it is a product standard. It does not just define what industrial systems must do to be considered secure. It defines who in the supply chain is responsible for what, and it places specific, distinct obligations on product vendors that differ from those placed on system integrators and asset owners.

For OEMs and component manufacturers in the industrial automation space, this matters practically. The obligations that apply to a PLC manufacturer are different from those that apply to the operator that deploys the PLC. Understanding which part of the standard applies to your organisation, and what it requires you to demonstrate, is the necessary starting point for any IEC 62443 compliance programme.

This guide explains the IEC 62443 obligations that apply specifically to product vendors, how the development process requirements and component security requirements work together, and what compliance evidence looks like in practice.

How IEC 62443 Defines Supply Chain Roles

IEC 62443 structures its requirements around three supply chain roles: product vendors, system integrators, and asset owners. Each role has distinct obligations, and the obligations are not interchangeable.

Product vendors are the organisations that design, develop, and maintain the components that make up industrial automation and control systems. This includes manufacturers of PLCs, RTUs, HMIs, protection relays, industrial networking equipment, safety instrumented systems, and the software applications and firmware that run on those devices. Product vendor obligations are defined primarily in IEC 62443-4-1 and IEC 62443-4-2.

System integrators are the organisations that design, build, and commission IACS systems using components from product vendors. They select components, configure systems, integrate subsystems, and deliver a complete operational system to the asset owner. System integrator obligations are defined primarily in IEC 62443-2-4 and IEC 62443-3-3.

Asset owners are the organisations that operate IACS systems in production. They define the security requirements for their operational environment, manage the security of deployed systems over their operational life, and are accountable for the security of the infrastructure they operate. Asset owner obligations are defined primarily in IEC 62443-2-1 and IEC 62443-3-2.

The supply chain distinction means that a product vendor cannot satisfy its IEC 62443 obligations by pointing to the security practices of the system integrator or asset owner. The standard places specific obligations on the product vendor as the organisation responsible for the security of the components they produce. Those obligations exist regardless of how the component is deployed or configured downstream.

The Obligations That Apply to Product Vendors

Product vendor obligations under IEC 62443 fall into two categories: development process obligations and component security obligations.

Development process obligations are defined in IEC 62443-4-1. They require that the product vendor’s development lifecycle meets defined security requirements across eight practice areas: security management, security requirements specification, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines documentation.

Component security obligations are defined in IEC 62443-4-2. They require that specific products meet defined technical security requirements at a stated security level, supported by empirical testing evidence.

Both sets of obligations require third-party assessment and certification to demonstrate compliance formally. A product vendor that claims IEC 62443-4-1 or IEC 62443-4-2 compliance without third-party certification is making an assertion that customers and procurement teams increasingly require to be backed by an accredited certification body assessment.

The driver for product vendors engaging with IEC 62443 is most commonly one of three things: a direct customer requirement in a procurement contract specifying that supplied components must meet IEC 62443-4-2 at a stated security level, a certification requirement from an industrial sector regulator or certification scheme, or a competitive requirement in a market where IEC 62443 certification is becoming a baseline procurement criterion.

IEC 62443-4-1: The Development Process Requirements

IEC 62443-4-1 defines the security requirements for the product development process. It does not certify any specific product. It certifies that the development lifecycle used to produce products meets defined security requirements, assessed against a four-level maturity model.

The eight practices each address a distinct area of the secure development lifecycle. Practice 1 covers security management: the organisational policies, responsibilities, and processes that govern security across development activities. Practice 2 covers security requirements specification: how security requirements are defined, documented, and traced through development. Practice 3 covers secure by design: the architecture and design practices that build security into components from the outset. Practice 4 covers secure implementation: the coding practices, tooling, and review processes that govern how components are built.

Practice 5 covers security verification and validation testing: the testing activities that verify security requirements are correctly implemented and identify vulnerabilities not anticipated during design. This practice requires security requirements testing, threat mitigation testing, and vulnerability testing including robustness testing and fuzzing. At higher maturity levels, tester independence requirements apply.

Practice 6 covers management of security-related issues: the processes for identifying, analysing, and resolving security vulnerabilities discovered through testing, external research, or customer reports. Practice 7 covers security update management: how patches and updates are developed, validated, and delivered. Practice 8 covers security guidelines documentation: the security-relevant documentation delivered to customers.

IEC 62443-4-1 is assessed against four maturity levels. Most product vendors targeting compliance begin at Maturity Level 2, which requires that each practice is applied according to a defined, documented process consistently across projects. Maturity Level 3 requires measurement and formal review. Maturity Level 4 requires continuous optimisation.

Note: a draft amendment to IEC 62443-4-1 is in development, targeted for late 2026. The draft amendment changes the prerequisite for IEC 62443-4-2 certification from the current requirement to CCS3 (software development lifecycle maturity) and adds Appendix A to the standard. CyTAL is tracking this amendment and will update guidance when it is published.

IEC 62443-4-2: The Component Security Requirements

IEC 62443-4-2 defines the technical security requirements for specific components. Unlike IEC 62443-4-1, which certifies the development process, IEC 62443-4-2 certifies a specific product version against specific component requirements at a stated security level.

The standard organises requirements into seven foundational requirement categories covering identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Within each category, specific component requirements define the security capabilities a component must provide.

The requirements most directly relevant to product vendors with protocol-based components are CR 3.5 input validation and CR 7.1 denial-of-service protection. CR 3.5 requires that the component correctly validates inputs from all external interfaces before processing them. CR 7.1 requires that the component is protected against denial-of-service conditions. Both requirements can only be demonstrated through empirical testing: they require showing that the component behaves correctly under invalid and adverse input conditions, not just that it has been designed to do so.

Security levels determine which requirements apply and which enhancements are required. Most industrial components are assessed at SL 2, which requires the base requirements for each applicable component requirement plus the SL 2 enhancements. The security level is determined by the security level of the system or zone in which the component is deployed.

How 4-1 and 4-2 Work Together

IEC 62443-4-1 and IEC 62443-4-2 are complementary and both are typically required as part of a complete product vendor compliance programme.

IEC 62443-4-1 process certification provides the assurance that the development practices used to produce a component are capable of producing components with the security properties they claim. Without process certification, the component certification provided by IEC 62443-4-2 is less credible because there is no assurance about the reliability of the security properties across the product’s lifecycle.

IEC 62443-4-2 component certification provides the product-specific assurance that a specific version of a specific component meets defined technical security requirements at a stated security level. Without component certification, process certification alone does not demonstrate that any specific product meets the requirements that customers and procurement teams specify.

In practice, the sequencing is to establish IEC 62443-4-1 process compliance first. The process foundation reduces the cost and effort of each subsequent IEC 62443-4-2 component assessment because the testing and documentation practices required for component certification are already embedded in the development process.

The draft amendment to IEC 62443-4-1, in development and targeted for late 2026, changes the prerequisite for IEC 62443-4-2 certification to CCS3 and adds Appendix A. CyTAL is tracking this amendment. Product vendors planning IEC 62443-4-2 certification programmes that extend into 2027 should monitor the amendment’s progress and factor it into their planning.

What Compliance Evidence Looks Like

The compliance evidence that IEC 62443-4-1 and IEC 62443-4-2 certification requires differs in structure and purpose but shares the requirement for specificity, traceability, and document control.

For IEC 62443-4-1, the evidence is primarily process documentation and records of process application. A certification body assessing IEC 62443-4-1 compliance will examine defined process documents for each practice, interview development and security staff to verify that processes are understood and followed, and review records showing that the processes have been applied to real products. The maturity level claimed must be evidenced by the documentation and records, not just asserted.

For IEC 62443-4-2, the evidence is primarily testing documentation. Each component requirement must be mapped to the tests that address it, and the test results must demonstrate that the requirement is met. For CR 3.5 and CR 7.1 specifically, the evidence must include protocol security testing results that show the component handles invalid inputs correctly and remains available under adverse conditions. Generic testing summaries that do not map to specific component requirements do not satisfy the evidence expectation.

The testing evidence for CR 3.5 and CR 7.1 needs to document the specific protocols tested, the categories of malformed input generated, each finding with the exact reproducing input and observed behaviour, and the remediation status of each finding. This is the structured evidence format that certification assessors look for and that generic penetration test reports typically do not provide.

How ProtoCrawler Supports Product Vendor Compliance

ProtoCrawler addresses the testing evidence requirements for IEC 62443-4-1 Practice 5 SVV-3 and IEC 62443-4-2 CR 3.5 and CR 7.1, which are the requirements most consistently identified as gaps in product vendor compliance programmes.

For Practice 5 SVV-3, ProtoCrawler generates systematic protocol-aware vulnerability testing across the component’s external protocol interfaces. The output is a structured evidence record that documents the testing scope, methodology, findings with exact reproducing inputs, severity classifications, and coverage traceability. This is the SVV-3 evidence format that IEC 62443-4-1 assessors look for and that generic testing reports do not provide.

For CR 3.5 and CR 7.1, ProtoCrawler’s testing exercises the input validation and denial-of-service protection requirements directly. Findings are mapped to the specific component requirements they relate to, producing the requirement-traced evidence that IEC 62443-4-2 certification assessments require.

The protocols supported by ProtoCrawler that are most commonly relevant to IEC 62443-4-2 product vendor assessments include Modbus, DNP3, IEC 61850, DLMS, and MQTT. For the full protocol list see the protocol models page.

Common Questions

Does IEC 62443 apply to software-only products or only to hardware?

IEC 62443-4-2 applies to four component types: software applications, embedded devices, host devices, and network devices. Software applications that process industrial data, interface with control systems, or perform functions that affect operational security are within scope. The standard explicitly covers software-only components as well as hardware products.

Do smaller OEMs face the same IEC 62443 obligations as Tier 1 automation vendors?

The standard does not differentiate obligations by company size. A small OEM supplying components into IEC 62443-assessed environments faces the same component security requirements as a large automation vendor. In practice, smaller OEMs typically have less existing security process infrastructure and may need to invest more in building compliant practices from scratch, but the compliance requirements themselves are the same.

How does IEC 62443 product vendor compliance relate to the EU Cyber Resilience Act?

The CRA places security obligations on manufacturers of products with digital elements selling into the EU market. For industrial products, IEC 62443-4-1 and 4-2 are the most directly applicable standards for demonstrating CRA conformity. Product vendors that achieve IEC 62443 certification are building the technical foundation that CRA conformity assessment will require. The CRA comes into full effect in 2027, and product development cycles that are underway now will need to satisfy CRA requirements at launch.

What is the typical timeline from starting an IEC 62443-4-1 compliance programme to certification?

For organisations with established development processes and existing security practices, six to twelve months from gap assessment to certification is achievable. For organisations building security practices from a lower baseline, eighteen months to two years is more realistic. The IEC 62443-4-2 component certification timeline depends on the scope of the assessment and how prepared the testing evidence is before the assessment begins.

Ready to build the IEC 62443 testing evidence your product vendor compliance programme requires? Book a demo to see how ProtoCrawler generates Practice 5 SVV-3 and CR 3.5 and CR 7.1 evidence for industrial component certification.

Book a demo

This field is for validation purposes and should be left unchanged.

Book Your Free Demo

Complete the form and we will confirm your slot within 1 business day.

Consent

By submitting, you agree to Cytal storing your information to arrange this demo. We will never share your details with third parties. Privacy Policy. Unsubscribe at any time.