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.
| Part | Subject | For whom |
|---|---|---|
| 62443-4-1 | Secure product development lifecycle: security requirements, secure design and coding, verification, defect and patch management, end of life | The manufacturer who develops and maintains the product |
| 62443-4-2 | Technical 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-3 | System-level security requirements and security levels | System integrators, products sold as systems |
| 62443-3-2 | Risk assessment using zones and conduits | System designers, integrators |
| 62443-2-4 | Security programme requirements for automation service providers | Integrators 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 requirement | 62443 part | Assessment in the mapping |
|---|---|---|
| Risk-based secure design and development (Annex I Part I) | 4-1 | Covered, but written for IACS products only |
| Placed on the market without known exploitable vulnerabilities | 4-1 | The only selected standard that also covers fixing test findings |
| Secure by default configuration | None | 62443 is not listed for this requirement |
| Security updates can be applied | 4-2 | Partly; notifying users of updates is not covered |
| Authentication and access control | 4-2 | Covered |
| Confidentiality and integrity of data | 4-2 | Covered |
| Data minimisation | None | 62443 is not listed for this requirement |
| Availability and resilience against denial-of-service attacks | 4-2 | Covered |
| Minimal negative impact on other devices and networks | None | 62443 is not listed for this requirement |
| Minimal attack surface | 4-2 | Named as an exception with concrete requirements |
| Logging and monitoring of security-relevant events | 4-2 | Covered |
| SBOM (Annex I Part II) | None | 62443 does not ask for an SBOM |
| Addressing vulnerabilities through updates | 4-1 | Partly; vulnerability classification and full patch management are missing |
| Public disclosure of fixed vulnerabilities | 4-1 | Covered |
| Coordinated vulnerability disclosure policy and contact address | None | 62443 is not listed for these requirements |
| Secure distribution of updates | 4-1 | Partly; flagged as a gap in the mapping |
| Security updates without delay and free of charge | 4-1 | Partly; 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
- 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.
- Fill the gaps: an SBOM for every release, a published vulnerability disclosure policy and contact address, secure-by-default configuration, data minimisation.
- Set up the Article 14 reporting process: who decides, how the 24-hour deadline is met, who files on ENISA's Single Reporting Platform.
- Define the support period and plan the infrastructure to distribute updates securely and free of charge throughout it.
- Determine the product's CRA class; the class check shows the likely class in a few questions.
- 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.
Sources
- Regulation (EU) 2024/2847: Articles 13, 14, 27, Annex I and Annex VII (EUR-Lex)
- JRC and ENISA: Cyber Resilience Act Requirements Standards Mapping (2024)
- Commission decision C(2025) 618: standardisation request M/606
- CEN-CENELEC: From EN IEC 62443 to the CRA (9 September 2025)
- IEC: cyber security and IEC 62443
- IEC 62443-4-1:2018 (IEC Webstore abstract)
- IEC 62443-4-2:2019 (IEC Webstore abstract)
- ISASecure certification programmes
Related guides
- CRA Article 14: vulnerability and incident reportingWhen, to whom and how fast to report. 24 hours, 72 hours and the final report, with a free deadline calculator.
- CRA product classes, conformity assessment and CE markingDefault, important (Class I and II) and critical products; which module applies and when you need a notified body.
- EN 18031 and RED: how they relate to the CRACybersecurity requirements for radio equipment in force since 1 August 2025, and the move to the CRA.
- CRA readiness guideFor every manufacturer selling into the EU: roles, timeline, extra points for non-EU manufacturers and a step-by-step checklist.
- What is an SBOM? A guide for firmware teamsWhat goes into an SBOM, SPDX and CycloneDX, why firmware makes it hard, what the CRA and BSI TR-03183-2 expect, and VEX.
- ENISA SRP: before your first reportEU Login and representatives, choosing the coordinating CSIRT, the platform's counters, closing a submitted notification and a short checklist.
- EU CRA: current status and timelineTimeline, harmonised standards, Commission acts, the ENISA SRP and notified bodies; checked against the official sources every month.
- CRA guide: overviewScope, timeline, Annex I essential requirements, product classes, reporting and fines on one page.
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.