What is IEC 62443-4-1?
IEC 62443-4-1 is the international standard that specifies how suppliers of industrial automation and control products set up a secure development lifecycle (SDL), from requirements and design through to releasing security updates. The standard was published in 2018 and is part of the IEC 62443 series. Where IEC 62443-4-2 describes what a product must be able to do technically, 4-1 describes how the development process must be organised to achieve that reliably.
🧠 Who is IEC 62443-4-1 intended for?
The standard targets product suppliers: manufacturers of PLCs, HMIs, switches, field devices, and SCADA and DCS software. System integrators who develop their own software use it too. For asset owners, 4-1 is mainly a procurement criterion: a supplier with a certified development process delivers secure products and updates more predictably.
🔧 What are the eight practices of IEC 62443-4-1?
| Practice | Abbreviation | Content |
|---|---|---|
| Security management | SM | Roles, competencies, securing the development environment, managing third-party components |
| Specification of security requirements | SR | Threat model and product security context, deriving requirements |
| Secure by design | SD | Layers of defence (Defense in Depth), reducing the attack surface |
| Secure implementation | SI | Coding guidelines, static code analysis, code reviews |
| Security verification and validation testing | SVV | Requirements testing, penetration tests, fuzzing, vulnerability scans |
| Management of security-related issues | DM | Reporting, assessing and fixing vulnerabilities (Responsible Disclosure) |
| Security update management | SUM | Timely testing, documenting and delivering patches |
| Security guidelines | SG | Documentation for secure installation, configuration and hardening |
📊 What maturity levels does the standard define?
IEC 62443-4-1 uses four maturity levels derived from CMMI:
| Level | Name | Characteristic |
|---|---|---|
| 1 | Initial | Ad hoc, dependent on individuals |
| 2 | Managed | Process documented and repeatable, but not yet applied everywhere |
| 3 | Defined (Practiced) | Process demonstrably applied in all projects |
| 4 | Improving | Process is measured and continuously improved |
In practice, certification expects at least level 3: the process must not only exist but must demonstrably have been followed.
🔄 How does 4-1 relate to other parts and to legislation?
- IEC 62443-4-2 — technical requirements for components; 4-1 is the process that delivers them
- IEC 62443-3-3 — requirements for the system as a whole
- IEC 62443-2-4 — requirements for service providers and integrators
- Cyber Resilience Act — requires, among other things, vulnerability handling, an SBOM and security updates throughout the support period; a 4-1 process covers much of this
🏅 How do you certify a development process?
Certification is carried out by an accredited body, for example through the ISASecure SDLA programme (Security Development Lifecycle Assurance) or through IECEE. An auditor assesses the process descriptions as well as evidence from real projects, such as threat models, test reports and vulnerability reports. A 4-1 certificate is also a prerequisite for CSA product certification against 4-2.
🛠️ How do you implement IEC 62443-4-1?
- Gap analysis — compare the current development process with the eight practices and determine the maturity level for each practice
- Roles and responsibilities — appoint a product security officer and provide security training for developers
- Threat modelling — create a threat model for each product and derive security requirements from it
- Tools in the pipeline — static code analysis, dependency scanning and an SBOM per release
- Vulnerability process — a public reporting point (PSIRT), fixed response times and security advisories
- Collect evidence — record per project that every step was carried out; no evidence, no certificate
| Artefact | Belongs to practice |
|---|---|
| Threat model | SR – specification of security requirements |
| Coding guidelines and review records | SI – secure implementation |
| Test reports and pentest results | SVV – verification and validation |
| Security advisories and patch notes | DM and SUM |
| Hardening guide for customers | SG – security guidelines |
❓ Frequently asked questions
What is the difference between IEC 62443-4-1 and IEC 62443-4-2?
IEC 62443-4-1 describes the development process: how a supplier securely designs, builds, tests and maintains products. IEC 62443-4-2 describes the technical requirements for the product itself, such as authentication, encryption and logging. Both are needed for a product certificate.
Is IEC 62443-4-1 mandatory?
IEC 62443-4-1 is a voluntary standard. However, more and more customers and tenders ask for a certified development process, and the Cyber Resilience Act imposes similar requirements on vulnerability handling and updates. As a result, a 4-1 process has become essential in practice for many suppliers.
How long does IEC 62443-4-1 certification take?
IEC 62443-4-1 certification typically takes six to eighteen months, depending on the maturity of the existing development process. Most of the time goes into setting up missing processes and collecting evidence from real projects. The audit itself usually takes a few days to weeks.
Does IEC 62443-4-1 apply to system integrators?
IEC 62443-4-1 targets product suppliers, but integrators who develop their own software or standard solutions can apply it too. For integrators’ services, such as designing and maintaining installations, IEC 62443-2-4 is the more relevant standard.
What role does a PSIRT play in IEC 62443-4-1?
A PSIRT (Product Security Incident Response Team) carries out the DM and SUM practices of IEC 62443-4-1: it receives vulnerability reports, assesses their severity, coordinates a fix and publishes security advisories and patches. Without a working PSIRT process, certification against 4-1 is not achievable.
📌 In summary
IEC 62443-4-1 defines the secure development lifecycle for suppliers of industrial products, in eight practices ranging from security management to security updates. It is the process foundation beneath IEC 62443-4-2 and aligns closely with the requirements of the Cyber Resilience Act.