When IEC 62443 Certification Makes Sense under the CRA

Many manufacturers assume that the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, forces them to get IEC 62443 certification. It does not. For a large share of products, the CRA requires no external body at all, and IEC 62443 does not impose any certification obligation of its own. Certification can still be worth it, but for a different reason than many people think.

IEC 62443 certification is the confirmation by an independent, accredited body that you meet a specific part of the series. One distinction often gets lost in practice: IEC 62443-4-1 does not certify your product, it certifies your development process. It describes the secure product development lifecycle, that is, how you plan, build, test, and maintain secure products over their lifecycle. Other parts of the series address the technical properties of a specific product, for example IEC 62443-4-2 for components and IEC 62443-3-3 for systems.

Contents

1. Do you need IEC 62443 certification at all?
2. Why IEC 62443-4-1 is still worth it: processes that are actually followed
3. How does IEC 62443-4-1 relate to the CRA?
4. How to start: a gap analysis that covers both
5. Certification is a means to an end, not an obligation

Do you need IEC 62443 certification at all?

For most manufacturers, the honest answer is no, at least not as a legal requirement. The CRA requires manufacturers to carry out a conformity assessment, but for default products it allows internal control (module A) under Article 32. The manufacturer assesses itself whether its product meets the essential cybersecurity requirements. No notified body is involved.

Two terms need to be kept apart here, because the CRA and the standard refer to different bodies. A notified body is the testing body that a Member State has notified and that the CRA requires for certain product categories. An accredited body is the certification body that issues an IEC 62443 certificate. Certification against the standard is therefore something different from involving a notified body under the CRA.

Then there is the presumption of conformity through harmonized standards. If a manufacturer applies a harmonized standard whose reference has been published in the Official Journal, conformity with the requirements it covers is presumed. This route works without an external body. The CRA makes a notified body mandatory only where it says so explicitly:

• for important products of class I, if the manufacturer has not applied the relevant harmonized standards, has applied them only in part, or if none exist,
• for all important products of class II, and
• for critical products.

For class I, common specifications and European cybersecurity certification schemes at assurance level “substantial” or higher count in the same way as harmonized standards.

Historically, applying standards was a quality label that set a product apart in the market, not a must. New regulation is changing this: standards are turning from a quality feature into a minimum requirement for market access. Even so, certification is still not mandatory.

Product category	Conformity route under the CRA	External body required?
Default product (the normal case)	Internal control (module A), presumption of conformity through harmonized standards	No
Important product, class I	Without a notified body only if harmonized standards (or common specifications or a certification scheme) are applied in full; otherwise module B+C or module H	Depends
Important product, class II	Module B+C, module H, or a European cybersecurity certification scheme	Yes
Critical product	European cybersecurity certification scheme under the conditions set for it; only if these are not met, the class II procedures instead	Yes

The CRA assigns products to these categories through its product lists in Annexes III and IV. Whether your product counts as important or critical is decided before that, not by your choice of standard.

In our view, the consequence is clear. For most products, an IEC 62443 certificate is primarily a market and trust signal. It sets you apart from competitors and builds trust with asset owners and buyers who ask for reliable evidence. As a rule, though, it is not a legal obligation under the CRA. If you seek certification only because of the CRA, you are often using the wrong argument.

Why IEC 62443-4-1 is still worth it: processes that are actually followed

The real value of IEC 62443-4-1 lies not in the certificate but in a question every head of development knows: are the defined processes actually followed day to day? In many companies, security processes exist on paper, neatly documented in manuals and policies. Under project pressure, nobody follows them consistently. IEC 62443-4-1 exposes exactly this gap, because it distinguishes between a defined process and a process that is practiced.

The standard measures the development process with a maturity model. At Maturity Level 2 (Managed), processes are documented and staff are trained, so they can act according to written rules. The standard explicitly names a typical problem at this level: an organization may already have adapted its procedures to the standard without having put them into practice throughout. It even acknowledges a considerable delay between defining a process and actually executing it.

Only at Maturity Level 3 (Defined, also called Practiced) is the process demonstrably practiced. There is evidence that the procedures were actually applied in at least one product development, repeatably across the organization. Even the first practice of the standard, a documented and enforced development process, aims at procedures that are followed, not at documentation alone.

In our view, this is the underrated benefit. The audit pressure of a certification makes process adherence verifiable. What gets certified must be demonstrated, and what must be demonstrated is more likely to be followed in daily work. Even if you skip the formal certificate in the end, aiming for Maturity Level 3 gives you a development process that delivers security instead of only promising it.

How does IEC 62443-4-1 relate to the CRA?

IEC 62443-4-1 describes the secure development process that the CRA expects from manufacturers. Among other things, the essential cybersecurity requirements of the CRA call for planned vulnerability handling, secure default settings, a risk assessment, and security updates throughout the support period. IEC 62443-4-1 already covers many of these process requirements. A separate article on IEC 62443 as a basis for the CRA explains the relationship between the standard and the CRA in detail.

One caveat matters here. Whether IEC 62443 and its amendment will be formally listed as harmonized standards under the CRA has not been decided yet. As long as the reference is not published in the Official Journal, applying the standard does not give an automatic presumption of conformity. Applying it consistently helps you meet the requirements. Whether that is formally sufficient remains open until the listing.

An amendment to the standard is meant to close the remaining gap to the CRA. EN IEC 62443-4-1:2018/prAA:2026 is a planned amendment to the existing standard and is explicitly designed to align it with the essential cybersecurity requirements of the CRA. It is intended as a normative reference for the CRA-aligned version of IEC 62443-4-2. Note that this amendment is a draft. It is at the enquiry stage, the public consultation, with a deadline in 2026. Its content may still change before final publication.

What does the amendment add? According to the current draft, it aligns existing requirements with the CRA, introduces new requirements, and adds risk management. It also introduces an applicability assessment process with a documented statement of applicability. This lets you justify and document which requirements apply to a specific product and which do not. The draft also contains mapping tables that map the practices of the standard to the horizontal CRA standards of the EN 40000 series, specifically to parts 1-2 and 1-3. These EN 40000 standards are also still drafts.

How to start: a gap analysis that covers both

If you want to get started, do not begin with the question of the certificate. Begin with your current state. We recommend starting with a gap analysis. The most efficient approach is to compare your development processes against the CRA-aligned draft of IEC 62443-4-1 and to capture the CRA gaps at the same time. This way, you address conformity with the standard and the CRA requirements in one step instead of running two separate projects.

This recommendation rests on two facts. The CRA requires a conformity assessment that the manufacturer carries out itself. And the draft of IEC 62443-4-1, with its applicability assessment process and statement of applicability, already provides a tool that structures exactly this self-assessment. Combining the two is the obvious step, but it remains our assessment, not a requirement of the standard.

A rough sequence for getting started:

1. Capture your current development processes. Record how you actually handle requirements, design, implementation, testing, and vulnerability handling today, not how the manual describes it.
2. Compare against IEC 62443-4-1. Compare your current state with the practices of the standard, preferably against the CRA-aligned draft, and determine the maturity level for each practice.
3. Map the CRA gaps as well. In parallel, record which essential cybersecurity requirements of the CRA you cannot yet demonstrate. Use the mapping between the standard and the CRA as a bridge.
4. Action plan. Prioritize the gaps by effort and impact, and decide which processes you will raise from defined to practiced.
5. Optional: certification as the final step. If a market or customer signal justifies the effort, have an accredited body confirm the process, now at maturity level 3, at the end.

This sequence ensures that any certification comes 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, IEC 62443 certification is a strategic option, not a requirement imposed by the CRA. Whether you need the certificate in the end depends on your product category and your market positioning, not on a legal obligation. The lasting gain comes on the way there: a maturity level 3 process that delivers measurable security, and a gap analysis that covers the CRA requirements efficiently.