Mandatory or voluntary? We explain when IEC 62443 certification is truly useful for manufacturers, what 62443-4-1 achieves, and how to get started.
An IEC 62443 certification is the confirmation from an independent, accredited body that you meet a specific part of the standard series. An important distinction often lost in practice is that IEC 62443-4-1 does not certify your product but your development process. It defines the secure product development lifecycle — how you plan, build, test and maintain secure products. The technical properties of a concrete product are addressed by other parts of the series, for example IEC 62443-4-2 for components and IEC 62443-3-3 for systems.
For most manufacturers the honest answer is: no, at least not mandatory. The CRA requires a conformity assessment from the manufacturer, but for standard products it allows the internal control procedure (Module A). In that case the manufacturer assesses themselves whether their product meets the essential requirements; a notified body does not have to be involved.
At this point a clarification of terms is useful, because the CRA and the standard refer to two different actors. The notified body (benannte Stelle) is the state-notified testing body that the CRA prescribes for certain product classes. The accredited body (akkreditierte Stelle) is the certification body that issues an IEC 62443 certificate. A certification under the standard is therefore different from involving a notified body under the CRA.
There is also the presumption of conformity through harmonized standards. If a manufacturer applies a harmonized standard whose reference is published in the Official Journal, conformity with the covered requirements is presumed. This route works without an external testing body. A notified body is required only where the CRA explicitly demands it: for important Class I products when the relevant harmonized standards are not or only partially applied or are missing, and generally for important Class II and critical products.
The VDMA guidance for mechanical and plant engineering puts this voluntariness in historical context: relying on standards has so far been a quality seal for market differentiation, not an obligation. With the new regulations that shifts, because standards change from a quality feature to a minimum requirement for marketability. However, certification is still not mandated by law.
| Product category | Conformity route under CRA | External body required? |
|---|---|---|
| Standard product (normal case) | Internal control procedure (Module A), presumption of conformity via harmonized standards | No |
| Important product, Class I | Without a notified body only when the harmonized standards are fully applied; otherwise Module B+C or Module H | Conditional |
| Important product, Class II | Module B+C, Module H or European certification scheme | Yes |
| Critical product | European certification scheme under the specified conditions; only if these are not met, alternatively the Class II procedures | Yes |
The CRA determines this categorization through its product lists. Whether your product is considered important or critical is decided beforehand, not by the choice of a standard.
From our point of view this leads to a clear consequence: an IEC 62443 certificate is for the vast majority of products primarily a market and trust signal. It differentiates you from competitors and builds confidence with operators and purchasers who demand reliable evidence. It is, in most cases, not a legal requirement under the CRA. Pursuing certification solely because of the CRA is therefore often argued on the wrong basis.
Why IEC 62443-4-1 is still worthwhile — processes that are actually practiced
The real value of IEC 62443-4-1 is not the certificate itself but a question every development manager knows: are the defined processes actually practiced day to day? In many companies security processes exist on paper, neatly documented in manuals and policies. Under project pressure nobody always follows them consistently. This gap is exactly what IEC 62443-4-1 exposes, because it differentiates between a defined and a practiced process.
The standard measures the development process using a maturity model (English: Maturity Level). At Maturity Level 2 (Managed) processes are documented and staff are trained, i.e. they can act according to written procedures. The standard explicitly names a common problem here: an organization can have already aligned its procedures to the standard without having fully implemented them in practice. It even allows for a considerable delay between defining a process and actually executing it.
Only at Maturity Level 3 (Practiced) is the process demonstrably practiced. There is evidence that the procedures have actually been applied in at least one product development and that this is repeatable across the organization. The first practical aim of the standard — a documented and enforced development process — targets practiced procedures, not mere documentation.
Here lies the underestimated benefit: the audit pressure of a certification makes process adherence verifiable. What is certified must be demonstrated, and what must be demonstrated is more likely to be followed in daily work. Even organizations that ultimately waive the formal certificate benefit from aligning to Maturity Level 3: a development process that delivers security, not just promises it.
What does IEC 62443-4-1 have to do with the CRA?
IEC 62443-4-1 describes exactly the secure development process that the CRA expects from manufacturers. The CRA requires, among other basic requirements, a planned vulnerability handling procedure, secure default settings, a risk assessment and security updates over the support period. Many of these process requirements are already covered by IEC 62443-4-1. The detailed relationship between the standard and the CRA is examined in a separate article titled IEC 62443 as a basis for the CRA.
However, one important note: whether IEC 62443 and its adaptation are formally listed as a harmonized standard under the CRA has not yet been decided. As long as the reference is not published in the Official Journal, the presumption of conformity does not automatically apply via this standard. Consistent application helps to meet the requirements; whether it is formally sufficient remains open until listing.
The remaining gap to the CRA is intended to be closed by an adaptation of the standard. The EN IEC 62443-4-1:2018/prAA:2026 is a planned amendment to the existing standard explicitly aimed at aligning the standard with the CRA’s essential requirements. It is intended as a normative reference for the CRA-adapted version of IEC 62443-4-2 as well. Important: this adaptation is a draft. It is currently in the enquiry stage, i.e. a public consultation with a deadline in 2026. Content may therefore still change until final publication.
What does the adaptation introduce? Based on the current draft it aligns existing requirements with the CRA, introduces new requirements and expands the topic of risk management. It also introduces a process for the applicability assessment along with a documented statement of applicability. That makes it possible to plausibly justify and demonstrate which requirements apply to a specific product and which do not. The draft also contains mapping tables that relate the practices of the standard to the horizontal CRA norms of the EN 40000 series, specifically parts 1-2 and 1-3. These EN 40000 standards themselves are still drafts.
How to start — the gap analysis that covers both
If you are looking for an entry point, start not with the question of certification but with the question of the current state. We recommend beginning with a gap analysis. The most sensible approach is to compare your development processes against IEC 62443-4-1 in the CRA-adapted draft and to capture CRA gaps at the same time. This way you close norm conformance and CRA requirements in one pass, instead of running two separate projects.
There are two factual anchors for this recommendation. The CRA requires a manufacturer-performed conformity assessment. And the draft version of IEC 62443-4-1 already provides a tool for exactly this self-assessment with the applicability assessment process and the statement of applicability. Combining both is therefore obvious, but it remains our interpretation, not a normative prescription.
A rough workflow to get started:
- Record the current state of development processes. Capture how you actually handle requirements, design, implementation, testing and vulnerability handling today, not how it is described in the manual.
- Compare against IEC 62443-4-1. Assess the current state against the practices of the standard, preferably against the CRA-adapted draft, and determine the maturity level for each practice.
- Map CRA gaps. At the same time record which essential CRA requirements are not yet evidenced and use the mapping between the standard and the CRA as a bridge.
- Action plan. Prioritize gaps by effort and impact and decide which processes you will elevate from defined to practiced.
- Optional: certification as a conclusion. If a market or customer signal justifies the effort, have the process elevated to Maturity Level 3 finally confirmed by an accredited body.
This sequence ensures that any eventual certification stands at the end of a sound process and not at its beginning as an end in itself.
Certification is a means to an end not an obligation
For most manufacturers an IEC 62443 certification is a strategic option, not a CRA-imposed must. Whether you ultimately need the certificate depends on your product class and market positioning, not on a legal obligation. The lasting gain is produced along the way anyway: a Maturity Level 3 process that delivers measurable security, and a gap analysis that efficiently incorporates CRA requirements.
How mature is your development process according to IEC 62443-4-1?
The free Readiness Check shows you in 15 questions where you stand today and immediately provides concrete recommendations for the next steps.
