This page is part of the CyTAL IEC 62443 compliance hub.
Most product security standards focus on what a product must do. IEC 62443-4-1 focuses on how it must be built. It defines the security requirements for the development process itself: the practices, disciplines, and verification activities that a product vendor must embed into their development lifecycle to produce components that can credibly claim a given security level.
For OEMs and product vendors, IEC 62443-4-1 is the part of the IEC 62443 series that applies most directly to how they work. It does not describe the technical security requirements of the finished product. That is IEC 62443-4-2. It describes the security requirements for the process that produces it.
This guide explains what IEC 62443-4-1 covers, how it is structured, what each practice requires, and where security testing fits into the compliance picture.
In This Guide
- What Is IEC 62443-4-1?
- Who IEC 62443-4-1 Applies To
- How IEC 62443-4-1 Is Structured
- The Eight Security Practices
- Practice 6: Security Testing — What It Actually Requires
- Maturity Levels and How They Work
- IEC 62443-4-1 vs IEC 62443-4-2: How They Relate
- Integrating IEC 62443-4-1 Into an Existing Development Process
- How ProtoCrawler Supports IEC 62443-4-1 Compliance
- Common Questions About IEC 62443-4-1
What Is IEC 62443-4-1?
IEC 62443-4-1 is the part of the IEC 62443 series that defines security requirements for the product development process used to create industrial automation and control system components. It is published by the International Electrotechnical Commission and developed in collaboration with the International Society of Automation.
Where the rest of the IEC 62443 series addresses the security of deployed systems, networks, and components, IEC 62443-4-1 addresses the security of the engineering practices used to develop those components. Its premise is that a component cannot reliably achieve a stated security level if the development process that produced it does not meet defined security requirements.
The standard defines eight security development practices, each covering a distinct area of the product development lifecycle. These range from security management and requirements specification through to incident response and patch management after product release. Each practice is assessed against a maturity model with four levels, from initial ad hoc processes at Maturity Level 1 through to continuous improvement and optimisation at Maturity Level 4.
IEC 62443-4-1 certification is increasingly required by customers, procurement frameworks, and certification bodies as evidence that a vendor’s development process meets the standard’s requirements. It is also a prerequisite for meaningful IEC 62443-4-2 component certification, because the process assurance it provides is the foundation on which component security claims rest.
Who IEC 62443-4-1 Applies To
IEC 62443-4-1 applies to product vendors and component manufacturers in the industrial automation and control system supply chain. This includes manufacturers of PLCs, RTUs, HMIs, industrial networking equipment, safety instrumented systems, and any other hardware or software components that are integrated into IACS environments.
It also applies, by extension, to software vendors whose products are embedded in or integrated with industrial components, and to organisations that develop firmware for embedded devices deployed in OT environments.
The standard does not apply to system integrators or asset owners directly, though both groups have strong reasons to understand it. Asset owners increasingly require that components they purchase comply with IEC 62443-4-1 as a condition of procurement. System integrators need to verify the IEC 62443-4-1 status of the components they select when designing systems to a stated security level.
For product vendors, the practical trigger for IEC 62443-4-1 engagement is usually one of three things: a customer requirement in a procurement contract, a certification requirement from a third-party assessment body, or a regulatory expectation in a target market. The EU Cyber Resilience Act, which comes into full effect in 2027, creates regulatory pressure for industrial product vendors that aligns closely with IEC 62443-4-1 requirements.
How IEC 62443-4-1 Is Structured
IEC 62443-4-1 is organised around eight security development practices. Each practice covers a distinct area of the development lifecycle and is defined through a set of requirements that must be met to achieve a given maturity level.
The standard is not prescriptive about implementation. It defines what must be achieved, not how. A vendor that meets the requirements for a given practice through documented processes, tooling, and evidence of application satisfies the standard regardless of which specific tools or methodologies they use. This gives vendors flexibility to implement the practices in ways that fit their existing development workflows, while providing assessors with clear criteria to evaluate against.
Assessment against IEC 62443-4-1 is conducted by third-party certification bodies. The assessment examines the vendor’s documented processes, interviews development and security staff, reviews evidence of practice application in real products, and verifies that the claimed maturity level is genuinely achieved rather than aspirationally documented. The output is a certification that states which practices have been assessed and at what maturity level.
The Eight Security Practices
Each of the eight practices addresses a distinct area of the secure development lifecycle. Understanding what each requires gives product vendors a framework for identifying where their existing processes already satisfy IEC 62443-4-1 requirements and where gaps exist.
Practice 1: Security management defines the organisational requirements for managing product security. It covers the security policies that govern development activities, the assignment of security responsibilities within the development organisation, and the processes for maintaining and improving security practices over time. At higher maturity levels it requires defined security metrics, formal review processes, and evidence of continuous improvement.
Practice 2: Specification of security requirements covers how security requirements are identified, documented, and maintained throughout the development lifecycle. It requires that security requirements are derived from a threat model, documented in a form that can be verified, and traced through the development process from specification to implementation to test. This is the practice that connects security intent to security evidence.
Practice 3: Secure by design addresses the security architecture and design practices that govern how components are designed. It requires that security considerations are built into design decisions, that the attack surface of the component is minimised, that defence in depth principles are applied, and that design decisions are documented with their security rationale.
Practice 4: Secure implementation covers the coding practices, tooling, and review processes that govern how the product is implemented. It requires the use of secure coding guidelines, the application of static analysis tools, code review processes that include security review, and the avoidance of known insecure functions and patterns.
Practice 5: Security verification and validation covers functional security testing: verifying that the security requirements specified in Practice 2 have been correctly implemented. This practice is about confirming the positive case: does the product do what the security requirements say it should?
Practice 6: Management of security-related issues covers the identification, analysis, and resolution of security vulnerabilities discovered through testing, external research, or customer reports. It is distinct from Practice 7 (which covers the patching and update process) in that it addresses the workflow for managing individual findings rather than the mechanics of delivering fixes to deployed products.
Practice 7: Security update management defines the processes for managing security patches and updates throughout the product’s supported lifecycle. It covers how vulnerabilities are disclosed, how patches are developed and validated, how updates are delivered to customers, and how end-of-life decisions are communicated.
Practice 8: Security guidelines documentation requires that security-relevant documentation is produced, maintained, and delivered to customers. This includes installation hardening guidance, secure configuration documentation, known limitations and residual risks, and documentation of the security functions the product provides.
Practice 6: Security Testing — What It Actually Requires
Practice 6 of IEC 62443-4-1 is the practice most directly relevant to product security testing programmes and the one most commonly cited in the context of protocol fuzz testing and vulnerability assessment.
Practice 6 is titled Security Verification and Validation Testing. It defines five specific security verification and validation activities, referenced as SVV-1 through SVV-5, that product vendors must conduct and document.
SVV-1 requires that the vendor conducts security testing to verify that the security requirements defined in Practice 2 have been correctly implemented. This is requirements-tracing: verifying that what was specified has been built.
SVV-2 requires threat mitigation testing: verifying that the mitigations defined in the product’s threat model have been correctly implemented and are effective. This connects directly to the threat modelling work that Practice 2 requires.
SVV-3 is the requirement that drives most of the interest in protocol fuzz testing. It requires vulnerability testing: systematic testing to identify vulnerabilities in the product that were not anticipated during design and development. The standard specifically includes robustness testing and fuzz testing as methods applicable to SVV-3. At higher security levels, SVV-3 requires that testers have a defined level of independence from the development team.
SVV-4 requires penetration testing at security level 3 and above. It defines the scope, independence requirements, and documentation expectations for penetration testing, and requires that findings are tracked through to resolution.
SVV-5 requires that all security testing activities are documented, that findings are recorded with sufficient detail to reproduce them, and that the testing evidence is maintained as part of the product’s security record.
The practical implication of Practice 6 for product vendors is that having a penetration test conducted on a finished product is not sufficient for IEC 62443-4-1 compliance. The standard requires a structured, documented testing programme that covers requirements verification, threat mitigation verification, vulnerability testing including fuzzing, and, at higher security levels, independent penetration testing. Each activity must produce documented evidence that satisfies SVV-1 through SVV-5.
Maturity Levels and How They Work
IEC 62443-4-1 assesses each practice against four maturity levels. The maturity level achieved for each practice reflects how systematically and repeatably the practice is applied, not simply whether it exists.
Maturity Level 1 represents an initial or ad hoc approach. The practice may be applied, but not consistently or according to a defined process. There is little documentation and outcomes are not predictable.
Maturity Level 2 requires a managed approach. The practice is applied according to a defined process, the process is documented, and there is evidence that it is followed consistently across projects. This is the minimum level that most customers and certification schemes require.
Maturity Level 3 requires a defined approach. The process is standardised across the organisation, measured against defined metrics, and subject to formal review. The organisation can demonstrate not just that the practice is applied but that it is applied consistently and effectively.
Maturity Level 4 requires an optimising approach. The organisation actively measures the effectiveness of the practice, uses that measurement to drive improvement, and can demonstrate that the practice improves over time. This level is appropriate for organisations where security assurance is a core business function rather than a compliance requirement.
Most product vendors pursuing IEC 62443-4-1 certification target Maturity Level 2 as a starting point, particularly for the practices where they are building capability from scratch. The certification assessment evaluates each practice independently, so a vendor can achieve different maturity levels for different practices based on where their processes are strongest.
IEC 62443-4-1 vs IEC 62443-4-2: How They Relate
IEC 62443-4-1 and IEC 62443-4-2 are the two parts of the IEC 62443 series that apply directly to product vendors, and they address different but complementary questions.
IEC 62443-4-1 addresses the development process. It asks: does the vendor’s development lifecycle meet defined security requirements? A vendor certified to IEC 62443-4-1 has demonstrated that their process for designing, implementing, testing, and maintaining products meets the standard’s requirements. It does not certify any specific product.
IEC 62443-4-2 addresses the finished component. It asks: does this specific component meet the defined technical security requirements for its claimed security level? A component certified to IEC 62443-4-2 has been assessed against specific component requirements, including input validation (CR 3.5), denial-of-service protection (CR 7.1), authentication requirements, and many others.
The relationship between the two is significant. A component cannot credibly claim IEC 62443-4-2 certification if it was not developed through a process that meets IEC 62443-4-1 requirements, because the component certification relies on the process assurance that IEC 62443-4-1 provides. In practice, organisations pursue both certifications as part of a combined programme rather than treating them as alternatives.
For product vendors, the sequencing is typically to establish IEC 62443-4-1 process compliance first, then pursue IEC 62443-4-2 component certification for specific products, because the process foundation reduces the effort required for each component assessment.
Integrating IEC 62443-4-1 Into an Existing Development Process
Most product vendors do not start IEC 62443-4-1 compliance from a blank slate. They have existing development processes, existing security practices, and existing documentation. The practical question is how to identify what already satisfies the standard’s requirements, what needs to be formalised or documented more rigorously, and what genuinely needs to be built from scratch.
A gap assessment against each of the eight practices is the standard starting point. For each practice, the assessment maps existing activities to the practice requirements, identifies where existing activities satisfy the requirements at a given maturity level, and surfaces genuine gaps where new processes or documentation need to be established.
The most common findings from IEC 62443-4-1 gap assessments in practice are the following. Security requirements are defined informally rather than being documented, traced, and maintained as first-class artefacts. Threat modelling is either absent or conducted once at the beginning of a project rather than maintained as the design evolves. Security testing, particularly SVV-3 robustness and vulnerability testing, is absent or limited to basic penetration testing without the systematic, documented coverage that the standard requires. Security update and patch management processes exist but are not documented in a form that satisfies the standard’s requirements for customer communication and lifecycle management.
None of these gaps are unusual and none are insurmountable. The path from gap assessment to IEC 62443-4-1 certification typically takes between six months and two years depending on the starting point, the number of practices that need significant work, and the resources the organisation can dedicate to the programme.
How ProtoCrawler Supports IEC 62443-4-1 Compliance
ProtoCrawler addresses the SVV-3 requirement in Practice 6 directly. SVV-3 requires systematic vulnerability testing that includes robustness testing and fuzzing, documented at a level that provides audit-ready evidence of the testing methodology, scope, and findings.
ProtoCrawler generates that evidence. For each protocol implementation tested, it produces a structured test record that documents which protocol was tested, which test cases were generated and why, what the target’s response was to each test case, and which findings were identified with the specific input that triggered each one. This is the SVV-3 evidence record that IEC 62443-4-1 auditors look for and that generic penetration testing reports do not provide.
For product vendors building a compliant secure development lifecycle, ProtoCrawler fits into the Practice 6 testing programme as the automated vulnerability testing component. It does not replace penetration testing or requirements verification testing, but it covers the SVV-3 robustness and fuzzing requirement at a scale and depth that manual testing cannot match, and it produces the documented, traceable evidence that the standard requires.
The protocols supported by ProtoCrawler that are most commonly relevant to IEC 62443-4-1 product testing include DNP3 Modbus, IEC 61850 , DLMS , and MQTT. For the full list of supported protocols, see the protocol models page.
For a broader explanation of how IEC 62443 testing requirements are structured across the standard series, see the IEC 62443 compliance hub.
Common Questions About IEC 62443-4-1
Is IEC 62443-4-1 certification mandatory?
Not universally. IEC 62443-4-1 certification is required where customers, procurement frameworks, or regulatory requirements specify it. In practice, it is increasingly demanded by asset owners and system integrators in critical infrastructure sectors, and the EU Cyber Resilience Act creates regulatory pressure that aligns closely with IEC 62443-4-1 requirements for industrial product vendors selling into European markets.
How long does IEC 62443-4-1 certification take?
The timeline depends on how mature the vendor’s existing processes are. Organisations with well-documented development processes and existing security practices typically take six to twelve months from gap assessment to certification. Organisations building security practices from scratch typically take eighteen months to two years. The assessment itself, once the vendor is ready, typically takes several weeks depending on the certification body and the scope of the assessment.
Which certification bodies offer IEC 62443-4-1 assessments?
Several internationally recognised certification bodies offer IEC 62443-4-1 assessments, including exida, TÜV SÜD, TÜV Rheinland, UL Solutions, Intertek, and SGS. The choice of certification body affects the timeline, cost, and geographic recognition of the certification. For vendors with customers in specific markets, choosing a certification body that is well-recognised in those markets is worth considering.
Does IEC 62443-4-1 certification cover specific products?
No. IEC 62443-4-1 certifies the development process, not a specific product. A vendor certified to IEC 62443-4-1 has demonstrated that their development lifecycle meets the standard’s requirements. Products developed through that process can then be assessed for IEC 62443-4-2 component certification, which does certify specific products against specific security level requirements.
What is the difference between IEC 62443-4-1 Maturity Level 2 and Maturity Level 3?
Maturity Level 2 requires that each practice is applied according to a defined, documented process consistently across projects. Maturity Level 3 requires that the process is standardised across the organisation, measured against defined metrics, and subject to formal review processes that demonstrate effective application rather than just consistent application. The practical difference is the level of measurement, governance, and demonstrable effectiveness that the organisation must maintain.
How does IEC 62443-4-1 relate to ISO 27001?
ISO 27001 is an information security management system standard that applies to an organisation’s information security risk management broadly. IEC 62443-4-1 is a product development process standard that applies specifically to how industrial components are designed, built, tested, and maintained. ISO 27001 certification does not satisfy IEC 62443-4-1 requirements, though some of the governance and process documentation work done for ISO 27001 provides a useful foundation for IEC 62443-4-1 practice implementation.