Mandatory or voluntary? We explain when IEC 62443 certification is genuinely useful for manufacturers, what 62443-4-1 provides and how to get started.
Eine IEC 62443 certification is the confirmation from an independent, accredited body that you meet a specific part of the standard series. It is important to distinguish something that is often overlooked in practice: IEC 62443-4-1 does not certify your product but your development process. It describes 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 whether the product meets the basic requirements; a notified body is not required.
At this point a clarification of terms is useful, because the CRA and the standard refer to two different actors. The notified body is the state‑notified testing body that the CRA prescribes for certain product classes. The accredited body 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.
Added to that is 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 path works without an external testing body. A notified body is only enforced where the CRA explicitly demands it: for important class I products if the relevant harmonized standards are not or only partially applied or are missing, and generally for important class II and critical products.
The VDMA guide for mechanical and plant engineering places this voluntariness in historical context: orientation on standards has so far been a quality seal for market differentiation, not an obligation. With the new regulations this shifts, because standards move from a quality feature to a minimum requirement for marketability. Nevertheless, certification is still not prescribed as a general obligation.
| Product category | Conformity route under the CRA | External body needed? |
|---|---|---|
| Standard product (normal case) | Internal control procedure (Module A), presumption of conformity via harmonized standards | No |
| Important product, class I | Only without a notified body if harmonized standards are applied in full; otherwise Module B+C or Module H | Conditionally |
| 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, fallback to the class II procedures | Yes |
The CRA assigns these categories via its product lists. Whether your product counts as important or critical is determined before that, not by choosing a standard.
From our point of view a clear consequence follows: an IEC 62443 certificate is for the majority of products primarily a market and trust signal. It differentiates you from competitors and builds confidence with operators and purchasers who ask for reliable evidence. It is usually not a legal obligation under the CRA. Pursuing certification solely because of the CRA is often based on the wrong premise.
Why IEC 62443-4-1 still pays off
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 in daily work? In many companies security processes exist on paper, documented in manuals and policies. Under project pressure, however, nobody consistently follows them. This exact gap is made visible by IEC 62443-4-1, because it distinguishes between a defined process and a practiced one.
The standard measures the development process using a maturity model (English: Maturity Level). At Maturity Level 2 (Managed) the processes are documented and staff are trained, so the organization can act according to written procedures. The standard explicitly names a typical problem here: an organization may have adapted its procedures to the standard without having fully implemented them in practice. It even allows for a significant 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 to at least one product development, and that this is repeatable across the organization. The standard’s first practical aim — a documented and enforced development process — targets lived procedures, not mere documentation.
Here lies the underestimated benefit: the audit pressure of certification makes process compliance verifiable. What is certified must be demonstrated, and what must be demonstrated is more likely to be followed in daily work. Even those who ultimately forgo the formal certificate gain a development process aligned to Maturity Level 3 that delivers security rather than just promising it.
What does IEC 62443-4-1 have to do with the CRA?
IEC 62443-4-1 describes exactly the secure development process the CRA expects from manufacturers. The CRA’s essential requirements include, among other things, planned vulnerability handling, secure default settings, risk assessment and security updates over the support period. Many of these process requirements are already covered by IEC 62443-4-1. A detailed relationship between the standard and the CRA is discussed in a separate article titled IEC 62443 as a basis for the CRA.
However, an important note: whether IEC 62443 and its adaptation are formally listed as harmonized standards under the CRA is not yet decided. As long as the reference is not published in the Official Journal, the standard does not create an automatic presumption of conformity. 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 and explicitly aims to align 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 comment period, with a deadline in 2026. Content may therefore still change before final publication.
What does the adaptation add? In its current draft state it aligns existing requirements to the CRA, introduces new requirements and expands risk management. It also introduces a process for an applicability assessment along with a documented declaration of applicability. This 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 align the practices of the standard with the horizontal CRA standards of the EN 40000 series, specifically parts 1-2 and 1-3. These EN 40000 standards are themselves still drafts.
How to start — the gap analysis that covers both
If you are looking to get started, don’t begin by asking about the certificate but by asking about the current state. We recommend starting with a gap analysis. The most sensible approach is to compare your development processes against IEC 62443-4-1 in its CRA‑adapted draft version and to capture the CRA gaps at the same time. This way you close standard conformance and CRA requirements in one go, instead of running two separate projects.
The practical anchor for this recommendation is twofold. The CRA requires a self‑conducted conformity assessment by the manufacturer. And the draft version of IEC 62443-4-1 already provides an instrument for that self‑assessment with the applicability assessment process and the declaration of applicability. Bringing both together is logical, but remains our interpretation, not a normative rule.
A rough sequence for getting started:
- Record the current state of development processes. Capture how you actually handle requirements, design, implementation, tests and vulnerability handling today, not how the manual states it.
- Compare against IEC 62443-4-1. Match the current state with the practices of the standard, preferably against the CRA‑adapted draft, and determine the maturity level for each practice.
- Map CRA gaps in parallel. Note 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 to raise 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 confirmed at the end by an accredited body.
This order ensures that any certification at the end reflects a clean process and is not pursued at the beginning as an end in itself.
Certification is a means to an end, not a requirement
For most manufacturers IEC 62443 certification is a strategic option, not something imposed by the CRA. Whether you need the certificate depends on your product class and market positioning, not on a legal obligation. The lasting gain is created on the way there: a Maturity Level 3 process that measurably delivers 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.
