Skip to content
Guide · IEC 62443

IEC 62443 and the CRA: a mapping for industrial product makers

Teams that work with IEC 62443 start well prepared for much of the EU Cyber Resilience Act (CRA), but not for all of it. This guide summarises, from public sources, which parts of the series match CRA Annex I, where gaps remain and what is changing in standardisation.

This guide is for information only and is not legal advice. The texts published in the Official Journal are binding.

01The short answer

  • IEC 62443 is not a harmonised standard under the CRA today. Applying 62443 therefore does not on its own give a presumption of conformity with the CRA (Article 27).
  • It is still a strong foundation: according to the 2024 JRC and ENISA mapping, 62443-4-1 for the development process and 62443-4-2 for the technical properties of a component cover many CRA Annex I requirements partly or largely.
  • Obligations such as the SBOM, coordinated vulnerability disclosure, Article 14 reporting, the support period and free security updates are missing from 62443 or only partly there.
  • CENELEC is preparing CRA-aligned amendments to EN IEC 62443-4-1 and 4-2. The draft amendment to 4-2 states that its aim is to be offered for citation under the CRA.

02The parts of IEC 62443 that matter to manufacturers

IEC 62443 is a family of standards for the security of industrial automation and control systems (IACS). Its parts address different roles: asset owner, integrator, service provider and product supplier. For the product manufacturer, who is the CRA's addressee, the two key parts are 4-1 and 4-2.

PartSubjectFor whom
62443-4-1Secure product development lifecycle: security requirements, secure design and coding, verification, defect and patch management, end of lifeThe manufacturer who develops and maintains the product
62443-4-2Technical security requirements for components, grouped under seven foundational requirements (FR), with the component's security capability level (SL-C)Makers of embedded devices, network devices, software applications and host components
62443-3-3System-level security requirements and security levelsSystem integrators, products sold as systems
62443-3-2Risk assessment using zones and conduitsSystem designers, integrators
62443-2-4Security programme requirements for automation service providersIntegrators and maintenance service providers

The seven foundational requirements in 62443-4-2 are identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability. Security levels run from 1 to 4, from casual violation up to targeted attacks with extensive resources.

IEC standard texts are sold. This guide relies only on public summaries from IEC, CEN-CENELEC and EU bodies and does not quote the standards.

03Mapping to CRA Annex I

In 2024 the European Commission's Joint Research Centre (JRC) and ENISA compared the CRA's essential requirements with existing standards. The table below summarises, in our own words, what that mapping found for 62443. The mapping was done against the CRA proposal; the numbering changed in the final text, so we name the requirements instead of numbering them.

CRA requirement62443 partAssessment in the mapping
Risk-based secure design and development (Annex I Part I)4-1Covered, but written for IACS products only
Placed on the market without known exploitable vulnerabilities4-1The only selected standard that also covers fixing test findings
Secure by default configurationNone62443 is not listed for this requirement
Security updates can be applied4-2Partly; notifying users of updates is not covered
Authentication and access control4-2Covered
Confidentiality and integrity of data4-2Covered
Data minimisationNone62443 is not listed for this requirement
Availability and resilience against denial-of-service attacks4-2Covered
Minimal negative impact on other devices and networksNone62443 is not listed for this requirement
Minimal attack surface4-2Named as an exception with concrete requirements
Logging and monitoring of security-relevant events4-2Covered
SBOM (Annex I Part II)None62443 does not ask for an SBOM
Addressing vulnerabilities through updates4-1Partly; vulnerability classification and full patch management are missing
Public disclosure of fixed vulnerabilities4-1Covered
Coordinated vulnerability disclosure policy and contact addressNone62443 is not listed for these requirements
Secure distribution of updates4-1Partly; flagged as a gap in the mapping
Security updates without delay and free of charge4-1Partly; no free-of-charge requirement

The mapping's overall finding: no single standard covers all of Annex I. The 62443 family offers good coverage but is specific to industrial control systems. If you make a consumer product or a general-purpose IoT device, you need to assess separately how the requirements fit your product.

04CRA obligations that 62443 does not cover

Beyond Annex I, the CRA places further obligations on manufacturers that have no counterpart in 62443:

  • SBOM: a machine-readable list of the components in the product, covering at least the top-level dependencies (Annex I Part II). See What is an SBOM? for details.
  • Coordinated vulnerability disclosure: a written policy and a contact address for vulnerability reports.
  • Article 14 reporting: a 24-hour early warning, a 72-hour notification and a final report for actively exploited vulnerabilities and severe incidents. It has applied since 11 September 2026; see the Article 14 guide.
  • Support period: a period reflecting the product's expected use, at least five years unless the product's lifetime is shorter, with free security updates throughout (Article 13).
  • Documents and marking: Annex VII technical documentation, user information (Annex II), the EU declaration of conformity and the CE marking.

05Harmonised standards and 62443

  • The CRA standardisation request M/606 covers horizontal and product-specific (vertical) standards. One vertical standard covers firewalls and intrusion detection and prevention systems; the request names those for industrial use explicitly and asks for consistency with machinery legislation (decision C(2025) 618).
  • CENELEC committee TC 65X is preparing an amendment (prAA) to EN IEC 62443-4-2:2019. The draft aligns the requirements with the CRA's essential requirements, adds new requirements for the gaps, and adds an Annex ZZ on the relationship with the CRA and an annex mapping threats to the CRA requirements. The enquiry on the draft closed on 5 June 2026.
  • The same committee is amending EN IEC 62443-4-1:2018 to align it with the cyber resilience principles standard drafted in CEN-CENELEC JTC 13, in particular on documenting the intended use and security context (CEN-CENELEC).
  • A standard gives a presumption of conformity only once its reference is published in the Official Journal of the EU (Article 27). Even when the amendments are published and cited, the presumption will be limited to the requirements listed in Annex ZZ.
  • For the timeline and the latest Official Journal status, see the EU CRA status page, which we check every month.

06What is 62443 certification worth under the CRA?

ISASecure certifies development processes against 62443-4-1 (SDLA) and components against 62443-4-2; IEC's IECEE system also runs conformity assessment for the series. These certificates have no legal effect under the CRA, but they help:

  • Risk assessment, secure development process and test records make up a large part of the Annex VII technical documentation.
  • Where a third-party assessment is required (Class I without a harmonised standard applied, Class II and critical products), they strengthen the evidence you give the notified body. The product classes guide explains which product takes which route.
  • If your customers are in scope of NIS2, they give you ready answers to supplier security questionnaires.

A 62443 certificate does not prove or guarantee CRA conformity. Conformity with the CRA rests on documentation showing that the product meets Annex I and that the obligations in Articles 13 and 14 are fulfilled.

07Steps for a team working with 62443

  1. Map your existing 4-1 process records and 4-2 requirement matrix against the table above; for each CRA requirement, note where the evidence lives.
  2. Fill the gaps: an SBOM for every release, a published vulnerability disclosure policy and contact address, secure-by-default configuration, data minimisation.
  3. Set up the Article 14 reporting process: who decides, how the 24-hour deadline is met, who files on ENISA's Single Reporting Platform.
  4. Define the support period and plan the infrastructure to distribute updates securely and free of charge throughout it.
  5. Determine the product's CRA class; the class check shows the likely class in a few questions.
  6. Follow the 62443 amendments at CENELEC and the JTC 13 standards; update your requirement matrix when they are published.

The industrial automation and electronics page explains how the CRA applies to industrial products. For wireless products, see also the RED and EN 18031 guide.

08Frequently asked questions

Is IEC 62443 a harmonised standard under the CRA?

Not today. No harmonised standard under the CRA has had its reference published in the Official Journal yet. CENELEC is preparing amendments that align EN IEC 62443-4-1 and 4-2 with the CRA; once published and cited, they could give a presumption of conformity for the requirements they cover.

If I hold a 62443-4-1 certificate, do I comply with the CRA?

No, not on its own. The certificate documents your secure development process and is valuable evidence in the technical documentation. But obligations such as the SBOM, coordinated vulnerability disclosure, Article 14 reporting, the support period and free updates are missing from 62443 or only partly there.

Which 62443 part is closest to the CRA?

For a manufacturer, the two together: 62443-4-1 covers the process side (secure design, vulnerability and patch management), 62443-4-2 the product's technical properties (access control, confidentiality and integrity of data, logging, availability).

Does the CRA require a particular security level (SL 2, SL 3)?

The CRA itself does not refer to 62443 security levels; the product's security properties follow from the manufacturer's risk assessment. The 4-2 amendment at CENELEC defines acceptance criteria based on security levels; the details will be clear once the standard is published.

Is 62443 only for industrial products?

The series was written for industrial automation and control systems, and the JRC/ENISA mapping notes this as a limitation. It is used in other fields too, but for consumer or general-purpose products you need to assess separately whether the requirements fit.

Let's talk about this process for your product

Our enterprise pilot generates the SBOM of your firmware, prioritises vulnerabilities and tracks Article 14 deadlines.