Defense in depth, threat modeling, penetration tests and more — learn what IEC 62443-4-1 requires from the development process. This article summarizes the main concepts, requirements and how the standard relates to other regulations.
Concepts and structure of IEC 62443-4-1
The IEC 62443-4-1 is based on the concept of “security by design“. The goal is to integrate cybersecurity from the very beginning into all development phases — from requirements analysis through design and implementation to testing, release and maintenance.
The standard’s requirements are grouped into eight main practices:
- Security management (Security Management)
- Specification of security requirements (Specification of Security Requirements)
- Secure design (Secure Design)
- Secure implementation (Secure Implementation)
- Security verification and validation (Security Verification and Validation)
- Management of security-related issues (Management of Security-Related Issues)
- Security update management (Security Update Management)
- Security guidelines (Security Guidelines)
Each of these practices contains multiple detailed requirements that describe processes and activities for secure product development.
Defence in depth
A central concept in IEC 62443-4-1 is “Defence in Depth” (defense in depth). This principle requires implementing multiple layers of security to protect a system. The idea is that if one security measure fails or is bypassed, additional protective layers remain in place.
In practice, this means developers should not rely on a single security measure but combine different mechanisms across various system layers. Examples include network segmentation, access control, encryption and logging.
Maturity level
IEC 62443-4-1 introduces the concept of maturity levels. These describe how well an organization implements the standard’s requirements. There are four levels:
- Initial: Processes are ad hoc and often undocumented.
- Managed: Processes are documented and applied consistently.
- Defined: Processes are standardized and applied across the organization.
- Improving: Processes are continuously improved based on metrics and feedback.
These levels allow companies to measure their progress in implementing a secure development process and to improve step by step.
In the context of certifications under IEC 62443-4-1 these maturity levels are assessed and indicated on certificates.
Requirements of IEC 62443-4-1
The IEC 62443-4-1 organizes requirements into the eight practices listed above:
Security management (Security Management)
This practice forms the foundation for the entire secure development process. It includes establishing and maintaining an overarching security management approach within the organization. This covers defining roles and responsibilities for security tasks, ensuring sufficient security expertise in the team, setting security policies and processes, and continuously improving those processes. Protecting the development environment itself and securely handling cryptographic material also fall under this area.
Specification of security requirements (Specification of Security Requirements)
This practice focuses on defining clear and comprehensive security requirements for the product to be developed. It includes creating a threat model that identifies potential attacks and vulnerabilities, as well as defining the security context in which the product will be used. Based on this, specific security requirements are formulated that the product must meet. These requirements undergo thorough review to ensure completeness and feasibility.
Secure design (Secure Design)
This practice is about applying security principles in product design. A key concept is the “defense in depth” strategy that provides multiple protection layers. The design must consider all product interfaces and define security aspects for each interface such as access control and data validation. Regular security reviews of the design help ensure all security requirements are properly implemented and that no new vulnerabilities are introduced.
Secure implementation (Secure Implementation)
This practice deals with securely turning the design into code. It includes defining and applying secure coding standards that avoid known vulnerabilities and unsafe practices. Regular code reviews and the use of static code analysis tools are intended to ensure these guidelines are followed and that no security flaws exist in the code.
Security verification and validation (Security Verification and Validation)
This practice aims to verify the effectiveness of implemented security measures. It includes different types of security tests, such as functional tests of security requirements, tests to verify threat mitigations, vulnerability testing and penetration tests. An important aspect is the independence of testers from developers to ensure an objective assessment.
Management of security-related issues (Management of Security-Related Issues)
This practice establishes processes for handling security issues discovered during development or after product release. It includes procedures for receiving and tracking security reports, assessing and prioritizing security issues, and developing and delivering fixes. Responsible disclosure of security issues to users is also part of this practice.
Security update management (Security Update Management)
This practice focuses on the secure management of product updates. It includes processes to qualify security updates to ensure they fix the intended issues and do not introduce new problems. Secure delivery of updates to users and documentation of changes are also covered. Timely provision of critical security updates is an important aspect.
Security guidelines (Security Guidelines)
The final practice deals with creating comprehensive security documentation for product users. These materials, such as manuals, should enable secure integration, configuration, operation and maintenance of the product. They include information on secure setup, system hardening, user and account management, and secure decommissioning of the product. Regular reviews ensure these guidelines remain up to date and complete.
When mapped into a logical overview, the requirements of the individual practices can be represented as follows:
Contents of IEC 62443-4-1
Relationship with IEC 62443-4-2
While IEC 62443-4-1 describes the process for secure development, IEC 62443-4-2 defines the concrete technical security requirements for IACS components. The two standards complement each other:
- IEC 62443-4-1 specifies how products should be developed securely.
- IEC 62443-4-2 specifies which security functions the products must ultimately provide.
A product developed according to IEC 62443-4-1 should be able to meet the requirements of IEC 62443-4-2. The processes from IEC 62443-4-1 ensure that the technical requirements from IEC 62443-4-2 are implemented and tested systematically.
Relationship between IEC 62443-4-1 and the Cyber Resilience Act
IEC 62443-4-1 plays a central role in implementing the European Cyber Resilience Act (CRA). While the CRA sets broad requirements for the cybersecurity of products with digital elements, IEC 62443-4-1 provides a detailed framework for a secure product development lifecycle.
The process-related requirements of the CRA are largely covered by IEC 62443-4-1, since the standard addresses aspects such as security management, requirements analysis, secure design and implementation, as well as handling of vulnerabilities and updates. Although IEC 62443-4-1 does not explicitly require a Software Bill of Materials (SBOM), its consistent application often leads to collecting the information needed for an SBOM.
For the CRA’s technical requirements, IEC 62443-4-1 alone is not sufficient and must be complemented by other standards such as ETSI EN 303 645 and EN 18031 to cover all aspects. Overall, IEC 62443-4-1 provides a solid foundation for companies to meet the CRA’s process-related requirements and to follow a structured approach to developing cyber-secure products.
More on this is available in our article IEC 62443 as a basis for implementing the Cyber Resilience Act.
Templates for implementing IEC 62443-4-1
Implementing a secure development lifecycle according to IEC 62443-4-1 can be significantly eased by using appropriate templates. Such templates provide a structured basis for various aspects of security management, from requirements analysis to vulnerability management. They can help companies save time and resources by providing best practices and structures. However, it is important to find the right balance between standardized templates and company-specific adaptations. For a detailed overview of available template packages, their pros and cons, and recommendations for selection and use, see our in-depth article “IEC 62443-4-1 templates a market overview and our offering”.
Conclusion
IEC 62443-4-1 offers a comprehensive framework for developing secure products. By consistently applying the requirements and achieving higher maturity levels, manufacturers can significantly improve and demonstrate the security of their products. Together with IEC 62443-4-2, IEC 62443-4-1 forms a solid basis for developing products that meet the increasing demands in industry.
