IEC 62443-4-1 is the standard that is cited most often and evidenced least often. Almost every manufacturer that supplies field devices to industrial plants has a process manual that refers to it. Far fewer can show in an audit that the described process actually took place for a specific product.
This article explains what the standard requires, how its maturity levels should be read, and where the transition from document to evidence breaks down in practice.
Process, not product
62443-4-1 does not describe a property of a device. It describes the development process a manufacturer uses to produce security systematically: how requirements are created, and how the product is designed, implemented, tested, released and maintained over its lifetime.
The technical properties of the device are defined in the sister standard 62443-4-2, where the seven Foundational Requirements and the Security Levels live. The two standards interlock: 4-1 ensures that the requirements from 4-2 are not met by chance, but reproducibly. Anyone who confuses the two ends up arguing past the question actually being asked in the audit. How the two perspectives differ in concrete terms is shown in the article on the maturity gap between 4-1 and 4-2.
The eight practices
The standard structures the secure development lifecycle into eight practices. They are the framework every assessment follows:
| # | Practice | What it covers |
|---|---|---|
| 1 | Security Management (SM) | Roles, competencies, process anchoring, supplier components |
| 2 | Specification of Security Requirements (SR) | Security requirements including the operating environment and threat model |
| 3 | Secure by Design (SD) | Architecture, defense in depth, design reviews |
| 4 | Secure Implementation (SI) | Secure coding guidelines, implementation reviews |
| 5 | Security Verification & Validation Testing (SVV) | Functional testing, vulnerability and penetration testing |
| 6 | Management of Security-related Issues (DM) | Handling of reported and discovered vulnerabilities |
| 7 | Security Update Management (SUM) | Provision, qualification and delivery of updates |
| 8 | Security Guidelines (SG) | Documentation for secure integration, operation and decommissioning |
The order is not a sequence of phases. SM, DM, SUM and SG run continuously; SR, SD, SI and SVV are tied to the respective development project. This distinction explains a large share of findings in practice: the product-related practices are usually well evidenced, while the continuous ones lose their trail after launch.
Four maturity levels, and what they really measure
Each practice has a maturity level. The scale follows the logic familiar from CMMI:
- ML 1 — Initial: The activity takes place, but ad hoc and dependent on individuals.
- ML 2 — Managed: There is a defined procedure, carried out by trained staff, with results that someone can trace.
- ML 3 — Defined (Practiced): The procedure is mandatory across the organization and is applied consistently across products.
- ML 4 — Improving: The process is measured and improved based on that measurement.
The jump where most organizations get stuck is ML 1 → ML 2, and it is not a documentation problem. ML 2 does not require a procedure to be described, but its result to exist for a specific product. A process manual does not create a maturity level — the artifacts do.
The three gaps that surface in audits
The process applies, but not to this product. The manual describes design reviews; for the product line in question, no review record exists. Formally ML 3, demonstrably ML 1.
The requirement exists, but without a trace to the measure. A security requirement is recorded, but no activity demonstrates that it made it into the product. This is the gap between 4-1 and 4-2 — and the one the TRA maturity check expresses as a metric.
The released version can no longer be identified. After release, the analysis was edited further, the requirements list extended, the document renamed. Two years later it is no longer possible to show which version the release was based on.
All three findings share the same root: the process is described, but its results are not bound to the product and its version.
Further reading in this series
- The maturity gap: what 4-1 requires and what 4-2 proves in the device
- SBOM without a parallel process: the bill of materials from the same source as the build
- Concept and design phase: results and handovers that survive an audit
- CRA deadlines 11 Sept 2026 and 11 Dec 2027 — what must be evidenced by when
The link to the Cyber Resilience Act
The CRA does not mention IEC 62443-4-1. It does, however, require that a cybersecurity risk assessment is carried out, that it feeds into implementation across all lifecycle phases, and that the essential requirements of Annex I can be traced back to its results. This traceability is exactly what a process lived according to 4-1 produces.
Anyone already operating the process in a verifiable way does not need to build a second world for the CRA — above all, they need to show that the existing one is carried through all the way to evidence. For an overview of which obligation applies when, see the deadlines article.
This article is a technical assessment, not legal advice and not a certification statement. Please verify citations of standards against the original documents.
Sources
- IEC 62443-4-1:2018 Ed. 1.0 — Secure product development lifecycle requirements
- IEC 62443-4-2:2019 Ed. 1.0 — Technical security requirements for IACS components
- Cyber Resilience Act — Summary of the legislative text (European Commission)
This article was originally published in German on the Alsensio Cybersecurity Hub.
