Two standards, two questions. 62443-4-1 asks: Does your process produce security systematically? 62443-4-2 asks: Can your device do what it needs to do? Both can be answered independently of each other — and that is exactly what makes the difference between the answers so revealing.
Two scales that have nothing to do with each other
The two standards measure on different scales, and that is no accident:
| IEC 62443-4-1 | IEC 62443-4-2 | |
|---|---|---|
| Subject | The manufacturer's development process | Technical properties of the component |
| Structure | Eight practices (SM, SR, SD, SI, SVV, DM, SUM, SG) | Seven Foundational Requirements (FR1–FR7) |
| Scale | Maturity level ML 1–4 | Security Level SL 0–4 |
| Typical evidence | Records, reviews, releases, process artifacts | Configuration, test evidence, architecture, mechanism in the device |
| Applies to | The organization and the project | The specific product in a specific version |
A high maturity level says nothing about the Security Level. A process run cleanly at ML 3 can produce a device that deliberately meets only SL 1 — because the risk assessment required nothing more. Conversely, a device can be technically very capable without anyone being able to prove why exactly these mechanisms were chosen.
Important for customer conversations: as a manufacturer, you talk about SL-C, the level your device is capable of. The target SL-T is set by the operator for their zone, and whether this becomes an achieved SL-A in the field depends on integration, configuration and operation.
Why the difference says more than any single value
Things get interesting when both sides are assessed for the same product and the difference is examined. In practice there are three recurring patterns.
Process high, implementation low. The most common case among manufacturers coming from a quality or functional safety background. Processes, reviews and releases are established, but the security requirements from the analysis have only partially made it into the product. In an audit, this shows up as requirements without an assigned measure. The process is not the problem — it just ends too early.
Implementation high, process low. Typical of technically strong teams: secure boot, signed updates, TLS with device identity — all present, but none of it derived from a documented requirement. The mechanisms are good; the rationale is missing. This is not just a formality: without derivation, there is also no way to show that nothing is missing.
Both low, but consistent. Uncomfortable, but honest — and a better starting point than a flattering picture. Here the order is clear: first the risk assessment, then the requirements, then the mechanisms.
The gap is a metric, not a feeling
The TRA maturity check captures exactly this difference: process maturity as a percentage versus implementation and evidence coverage as a percentage, with the difference in percentage points shown as a traffic light. Not because the number is a certification statement — it is a self-assessment — but because a number structures a discussion that otherwise ends as an exchange of opinions between engineering and quality management.
Two things matter when reading the gap:
A small gap is not automatically good. Two low values sit close together. The gap qualifies the state; it does not replace it.
A large gap shows the direction of the work. If the process is ahead, the link from requirement to measure is missing — that is evidence work. If the implementation is ahead, the derivation is missing — that is analysis work. These are completely different projects with different people involved.
What the bridge depends on in practice
The connection between the two worlds is the same in every case: a traceable chain from the identified threat via the derived requirement to the concrete activity in the product — and back. If this chain exists, the gap is small, because by construction it has to be.
In practice this means: every requirement from 4-2 that applies to your device should point back to an identified risk and forward to an activity. If either direction is missing, it is not evidence but a claim — and in an audit, it is the point where the follow-up questions start.
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
This article was originally published in German on the Alsensio Cybersecurity Hub.
