IEC 62443-4-1: Secure Development Lifecycle Requirements Explained

This page is part of the IEC 62443 compliance hub.

IEC 62443-4-1 is the part of the standard that governs how industrial automation and control system products are built. Where IEC 62443-4-2 defines what a component must do technically, IEC 62443-4-1 defines the processes a vendor must follow to develop, test and maintain it securely throughout its lifecycle.

For UK product vendors supplying into regulated industrial markets, IEC 62443-4-1 compliance is increasingly a procurement requirement. Customers and certification bodies want assurance not just that a product meets its current security requirements, but that the processes used to build it are capable of maintaining that assurance as the product evolves.

This guide explains what IEC 62443-4-1 requires, how its eight practices and four maturity levels work, and how structured security testing with ProtoCrawler supports the verification and validation practice at the heart of the standard.

What Is IEC 62443-4-1?

IEC 62443-4-1 defines the requirements for a secure product development lifecycle for IACS components. Published in 2018, it covers the processes that product vendors must put in place to build security into their products consistently and repeatably, from initial design through to decommissioning.

The standard is process-focused rather than technically prescriptive. It does not tell vendors exactly how to implement security features. Instead it defines the practices and activities that a secure development programme must include, and uses a maturity level framework to assess how well those practices are embedded in the organisation.

IEC 62443-4-1 is the foundation on which IEC 62443-4-2 component certification is built. Achieving ISASecure Component Security Assurance certification requires that the vendor’s development process meets IEC 62443-4-1 requirements. A product can meet every technical requirement in IEC 62443-4-2 but still fail certification if the development process that produced it cannot demonstrate IEC 62443-4-1 alignment.

---

Who IEC 62443-4-1 Applies To

IEC 62443-4-1 applies to product vendors and suppliers who develop IACS components for deployment in industrial automation and control system environments. This includes manufacturers of embedded devices such as PLCs and IEDs, developers of SCADA and HMI software, vendors of industrial network devices, and any organisation that develops firmware or software incorporated into components used in IACS environments.

In the UK, the practical pressure to demonstrate IEC 62443-4-1 compliance is growing through two channels. Formal certification requirements are appearing in regulated sector procurement contracts and supply chain security programmes, particularly in energy, water and critical national infrastructure. Customer-led assessments of supplier development practices are becoming more common as asset owners and system integrators seek to manage supply chain risk more rigorously.

If you develop products that are deployed in IACS environments and your customers are themselves subject to regulatory security obligations, IEC 62443-4-1 is likely to appear in your next significant tender or contract renewal.

---

The Eight Secure Development Practices

IEC 62443-4-1 defines eight practices that together form a complete secure development lifecycle. Each practice covers a distinct phase or function within the development process, and compliance requires evidence that all eight are implemented at an appropriate maturity level.

Security Management covers the governance structures, policies, resources and accountability mechanisms that support secure development across the organisation. This is the overarching practice that enables all others and is assessed first in any IEC 62443-4-1 evaluation.

Security Requirements Specification requires that security requirements are identified and documented early in the development process, based on threat modelling, use cases and applicable standards including IEC 62443-4-2. These requirements become the baseline against which testing in Practice 6 is measured.

Secure by Design requires that architectural and design decisions incorporate security principles including least privilege, defence in depth, attack surface reduction and secure defaults. Design reviews and threat model updates are expected as the product evolves.

Secure Implementation covers secure coding practices, code review requirements, and the use of static analysis tools to detect coding errors and deviations from secure coding standards. IEC 62443-4-1 is explicit that secure coding standards must be defined, applied and enforced.

Security Verification and Validation (SVV) is the testing practice and the most directly relevant to the evidence requirements that assessors review in detail. It is covered separately below.

Management of Security-Related Issues covers the processes for identifying, tracking and resolving security vulnerabilities discovered after release, including vulnerability disclosure, patch management and customer notification. This practice has become increasingly important as post-market security obligations have grown.

Security Update Management covers the processes for developing, testing and distributing security patches and updates throughout the product lifecycle. IEC 62443-4-1 requires that updates can be delivered securely and that their integrity can be verified.

Security Guidelines covers the requirement to produce security-related documentation for customers, including guidance on secure installation, configuration, operation and maintenance of the product.

---

Maturity Levels Explained

IEC 62443-4-1 assesses the implementation of each practice against four maturity levels. Unlike IEC 62443-4-2 which uses security levels to measure what a product does, IEC 62443-4-1 uses maturity levels to measure how well development processes are embedded and managed.

Maturity Level 1 (Initial) means that practices are performed but are not documented or managed consistently. Activities happen on an ad hoc basis and depend on individual knowledge rather than defined processes.

Maturity Level 2 (Managed) means that practices are planned, tracked and documented. There is evidence that activities are performed consistently and that results are reviewed. This is the minimum maturity level required for IEC 62443-4-1 compliance across all eight practices.

Maturity Level 3 (Defined) means that practices are standardised across the organisation, documented in defined processes, and supported by appropriate tooling and training. Process performance is measured and improvements are made systematically.

Maturity Level 4 (Optimising) means that practices are continuously improved based on quantitative performance data and lessons learned. This level is not required for certification but represents best practice for mature security development organisations.

For most UK product vendors pursuing IEC 62443-4-1 compliance for the first time, reaching Maturity Level 2 across all eight practices is the initial target. Many organisations find that their development processes already include elements of several practices informally and that the primary work is documenting, formalising and consistently applying what already happens.

---

Practice 6: Security Verification and Validation

Practice 6 is the testing practice within IEC 62443-4-1 and the one most directly connected to the empirical evidence requirements that assessors focus on. It defines four types of testing that must be conducted before a product is released.

SVV-1 Security Requirements Testing verifies that the product’s security functions meet the security requirements defined in Practice 2. This includes functional testing of authentication, access control, communication integrity and other security features, as well as performance and scalability testing, boundary condition testing, and malformed or unexpected input tests.

SVV-2 Threat Mitigation Testing verifies that the specific threats identified in the threat model have been addressed effectively. Test cases are derived directly from the threat model and assess whether mitigation measures are effective in practice rather than just in design.

SVV-3 Vulnerability Testing focuses on identifying and characterising potential vulnerabilities in the product. IEC 62443-4-1 explicitly cites fuzzing as a method within SVV-3, alongside checking against public vulnerability databases and identifying security rule violations. This is the requirement that makes protocol fuzz testing a direct compliance obligation rather than an optional extra.

SVV-4 Penetration Testing requires that the product is subjected to penetration testing to validate vulnerabilities and test the effectiveness of security controls. The independence requirements for penetration testing are more stringent than for other SVV activities, with IEC 62443-4-1 requiring that penetration testers are independent of the development team and, for higher security levels, independent of the development organisation entirely.

Practice 6 also requires that security testing is repeated as part of regression testing whenever significant changes are made to the product. This ongoing obligation is what makes automated, repeatable testing tools essential rather than optional for a sustainable IEC 62443-4-1 compliance programme.

---

Tester Independence Requirements

IEC 62443-4-1 defines specific independence requirements for security testers that affect how organisations structure their testing programmes and when they need to engage external specialists.

For SVV-1 and SVV-2 testing, an independent person is required. The tester must not be one of the developers of the product but can be from the same team or organisation.

For SVV-3 vulnerability testing, an independent department is required. The tester must not report to the same first-line manager as the developers. A quality assurance team or a separate internal security function can satisfy this requirement.

For SVV-4 penetration testing at higher security levels, an independent organisation is required. The tester must not be part of the same legal entity as the development team. This is the requirement that most commonly leads vendors to engage external penetration testing specialists.

Understanding these independence requirements early helps organisations plan their testing programme realistically and avoid discovering late in a certification process that testing evidence needs to be regenerated by a suitably independent party.

---

IEC 62443-4-1 vs IEC 62443-4-2: How They Work Together

IEC 62443-4-1 and IEC 62443-4-2 address complementary dimensions of product security and are designed to be implemented together.

IEC 62443-4-1 is about process. It defines how a product is developed, tested and maintained. Compliance demonstrates that security is built into the development lifecycle consistently and repeatably, not just addressed when a specific audit or customer requirement demands it.

IEC 62443-4-2 is about the product. It defines the technical security capabilities that a component must demonstrate at a stated security level. Compliance demonstrates that the product itself meets specific, measurable security requirements.

The relationship between the two parts is that a compliant IEC 62443-4-1 process is the mechanism by which a vendor can confidently and consistently produce products that meet IEC 62443-4-2 requirements. Without the process foundation, technical compliance with 4-2 is fragile and difficult to sustain across product versions and updates.

For a detailed guide to IEC 62443-4-2 component requirements, security levels and the specific testing obligations that apply at the component level, see the IEC 62443-4-2 guide.

---

IEC 62443-4-1 Certification

IEC 62443-4-1 certification is a process assessment rather than a product test. It assesses whether the vendor’s development organisation has the practices, documentation and governance in place to develop secure products consistently.

The primary certification route is ISASecure Security Development Lifecycle Assurance certification, which assesses development processes against IEC 62443-4-1 requirements and awards certification at the maturity level achieved. SDLA certification is a prerequisite for ISASecure Component Security Assurance certification under IEC 62443-4-2.

IECEE CBTL laboratories also offer IEC 62443-4-1 process assessments as part of broader IEC 62443 certification programmes.

Customer-led assessments of supplier development practices against IEC 62443-4-1 are increasingly common, particularly in regulated UK sectors. The evidence required is essentially the same as for formal certification: documented processes, records of activities performed, testing evidence from Practice 6, and demonstration that processes are applied consistently across the development lifecycle.

For guidance on the full certification landscape including timelines and what to expect from the assessment process, see the IEC 62443 certification UK guide.

---

How ProtoCrawler Supports IEC 62443-4-1 Practice 6

ProtoCrawler supports IEC 62443-4-1 Practice 6 directly across SVV-1, SVV-2 and SVV-3, the three testing types where automated protocol fuzz testing is most directly applicable.

For SVV-1 security requirements testing, ProtoCrawler generates the malformed and unexpected input tests that the standard explicitly requires as part of security requirements verification. Its structured protocol models exercise the full range of input conditions that a compliant SVV-1 programme must address for protocol-implementing components.

For SVV-2 threat mitigation testing, ProtoCrawler can be configured to execute test cases derived directly from the threat model, verifying that specific threat scenarios do not produce exploitable outcomes. This allows threat model coverage to be demonstrated empirically rather than asserted.

For SVV-3 vulnerability testing, IEC 62443-4-1 explicitly names fuzzing as a required method. ProtoCrawler fulfils this requirement directly. Its intelligent test generation, automated execution and scoring matrix produce the vulnerability testing evidence that SVV-3 demands, including findings traceable to specific protocol fields and message types.

For regression testing, ProtoCrawler’s reusable test configurations mean that when firmware is updated or new protocol functionality is added, the relevant test set can be re-executed against the updated build quickly and efficiently. The results are directly comparable with previous runs, making it straightforward to demonstrate that regression testing has been performed and that no new vulnerabilities have been introduced.

ProtoCrawler integrates with CI/CD pipelines so that protocol fuzz testing can run automatically as part of the build process, embedding SVV-3 vulnerability testing into the development workflow rather than treating it as a separate activity performed only at release.

For the full list of protocols supported, see the protocol models page. For a broader view of what a complete IEC 62443 testing programme looks like, see the IEC 62443 compliance testing guide.

---

Ready to build a compliant IEC 62443-4-1 secure development lifecycle? Book a demo to see how ProtoCrawler supports Practice 6 and generates the testing evidence your programme requires.

Explore the full IEC 62443 compliance hub for the complete set of guides covering certification, component requirements and protocol security testing.