From IEC 62443 to EU Cyber Resilience Act Compliance

Julian Meroi · Published 5 October 2026 · Last reviewed 5 October 2026

If your products are developed under IEC 62443-4-1 or your components are assessed against IEC 62443-4-2, you probably hold detailed records of how they were designed, tested and maintained. Some of those records may support your EU Cyber Resilience Act (CRA) work. The task is to establish which records apply to which product and version, what they actually show, and which CRA obligations need their own assessment.

This page connects specific IEC 62443 requirements to specific CRA provisions, states what each can contribute as evidence, and states where it stops.

Who this is for, and what it assumes

You manufacture industrial automation hardware, software or firmware and place products with digital elements on the EU market, wherever your company is established. Your development organization works to IEC 62443-4-1, and some of your components have been assessed against IEC 62443-4-2. The page assumes the processes actually operate and that records exist for the product version in question. A certificate, or a policy that names the standard, is where the review starts.

Two things the standards do not decide:

• Whether the CRA applies, and to whom. The CRA applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Article 2). Article 3 defines the product, including its remote data processing solutions, and the manufacturer. The exclusions in Article 2 need their own check. IEC 62443-4-1 applies to the developer and maintainer of a product and not to its integrator or user (Clause 1, p.11). Whether you are the CRA manufacturer of a given product is a separate legal question.
• Which category the product falls into, which decides the conformity assessment route (Article 7, Article 8 and Article 32, with Annexes III and IV). Category follows the product’s core functionality. IEC 62443 security levels describe capability against threats of increasing sophistication (IEC 62443-4-2, 3.3, p.26) and are not CRA categories. Under Article 7(1), integrating a component that has the core functionality of an Annex III category does not in itself subject the final product to the procedures for important products.

Which editions this maps

• IEC 62443-4-1:2018, edition 1.0, January 2018: secure product development lifecycle requirements.
• IEC 62443-4-2:2019, edition 1.0, February 2019: technical security requirements for IACS components. CENELEC adopted it as EN IEC 62443-4-2:2019 without modification. Corrigendum 1 (2022) corrects the French text only.
• Page numbers below are the printed page numbers of the IEC text.
• Both parts refer to other documents, notably IEC 62443-3-3, from which the 4-2 requirements are derived and to which several of them point. Those referenced requirements are not mapped here.
• Regulation (EU) 2024/2847, the CRA, as published in the Official Journal.

Read the assessment’s scope first

Before reusing any IEC 62443 result, write down what it actually covers:

• The standard part, edition and, if certified, the scheme and scheme version.
• For IEC 62443-4-1: the organization and the documented process that was assessed. A process assessment describes how products are meant to be developed. Product records show whether that happened for a given release. IEC 62443-4-1 also defines maturity levels that describe how thoroughly the requirements are met (4.2, p.19). Record the level stated.
• For IEC 62443-4-2: the component, its version and its component type. The types are software application, embedded device, host device and network device. A component can meet more than one definition, and is then expected to meet the requirements for each (3.3, p.26). Record the capability security level achieved for each foundational requirement.
• Assumed external countermeasures. Where a 4-2 requirement can only be met with help from a compensating countermeasure outside the component, the component documentation has to describe it (4.3, CCSC 2, p.27). IEC 62443-4-1 SG-2 documents the defense-in-depth measures expected from the environment (12.3.1, p.45).

That last point matters for the CRA. The Commission’s guidance explains that the risk assessment covers risks originating outside the product, and that the CRA does not require manufacturers to control the external environment. Manufacturers identify such risks and mitigate them through the design of the product itself, and, where necessary, through information and instructions to users (C(2026) 5252, paragraph 168, p.59). An assumption that the plant network provides a firewall is therefore an input to your risk assessment, and the product-level treatment of that risk needs its own evidence.

Most 4-2 requirements are stated as capabilities: the component “shall provide the capability” to do something. A capability does not show how the product ships or how it is configured. Evidence for the delivered configuration comes from your product records.

What your IEC 62443-4-1 evidence can contribute

Each group below names the 4-1 requirements, the CRA provision the evidence speaks to, and the part the requirement does not reach. Treat every link as potential reuse. It still depends on the product in scope, the release, whether the process actually ran, and the quality of what it produced.

Security context and threat model

IEC 62443-4-1: SR-1 (6.2.1, p.27), SR-2 (6.3.1, pp.27-28).

A documented product security context speaks to Article 13(2) and 13(3), as does a threat model that covers data flows, trust boundaries, interfaces, physical and debug ports, external dependencies, and threats with their severity and mitigations. Both belong in the technical documentation under Annex VII(3). SR-2 also requires threat models of released products to be reviewed at least once a year and updated if required in response to new threats, even if the design has not changed.

What to check:

• Minimum content. Article 13(3) sets the minimum content of the risk assessment: intended purpose, reasonably foreseeable use, conditions of use such as the operational environment and the assets to be protected, taking into account the length of time the product is expected to be in use.
• Applicability. The assessment must also state whether and how each requirement in Annex I Part I(2) applies and how it is implemented, and how Part I(1) and the Part II vulnerability handling requirements are applied. Where a requirement does not apply, Article 13(4) requires a clear justification in the technical documentation.
• Methodology and scope. The Commission’s FAQ confirms that no particular methodology is mandated (section 4.1.2, p.27), and that the assessment must cover the entire product, including remote data processing when in scope (section 4.1.1, p.26). An IEC threat model can contribute to that risk assessment. Whether the assessment as a whole covers the entire product and the Article 13(3) contents still needs to be checked.
• Review clock. The annual review interval comes from IEC. The CRA requires the assessment to be documented and updated as appropriate during the support period (Article 13(3)).

Secure design and implementation

IEC 62443-4-1: SD-1 (7.2.1, p.30), SD-2 (7.3.1, p.31), SI-1 (8.3.1, p.33), SI-2 (8.4.1, p.34).

This evidence speaks to Annex I Part I(1), to Part I(2)(j) on limiting attack surfaces, including external interfaces, and to Part I(2)(k) on exploitation mitigation. It also supports the design and architecture description in Annex VII(2)(a). It includes:

• a characterization of every interface, covering external or internal access, trust boundaries, users and assets, safeguards including input validation, and third-party products used;
• layered defenses assigned on the basis of the threat model;
• implementation reviews, including static code analysis of all source code changes and new code, performed with a tool where one is available for the language;
• maintained secure coding standards.

What to check: SI-1 and SI-2 apply to the product’s own components. Externally provided components fall under SM-9 instead (8.2, p.33). The static analysis and tool requirements come from IEC 62443-4-1. Annex I does not name analysis methods or tools. Design and review records support a CRA requirement only for the version they describe.

Externally provided components and the SBOM

IEC 62443-4-1: SM-9 (5.11.1, p.24), SM-10 (5.12.1, p.24), DM-4 (10.5.1, p.40).

SM-9 requires a process to identify and manage the security risks of all externally provided components. Its supplemental guidance discusses both open-source and commercial components. SM-10 requires custom components developed by third-party suppliers, where they meet its criteria, to follow lifecycle processes that conform to 4-1. Records from both speak to Article 13(5) on due diligence for integrated components. That due diligence expressly includes free and open-source components not made available in the course of a commercial activity.

Three points to check:

• The SBOM itself. Annex I Part II(1) requires you to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. IEC 62443-4-1 recommends an inventory of third-party components in its supplemental guidance (5.11.2, p.24). It does not specify an SBOM format or depth. IEC 62443-4-2 CR 7.8 (11.10, p.62) is a capability to support a control system component inventory, and it is not an SBOM.
• Upstream reporting. DM-4 requires you, in all cases, to inform third parties when problems are found in included third-party source code. Article 13(6) requires you to report a vulnerability identified in any integrated component to the person or entity manufacturing or maintaining it. Where you have developed a fix, you share the relevant code or documentation with them, where appropriate in a machine-readable format. Check that your records cover both steps, and components delivered without source code.
• Publication. The CRA does not require you to publish your SBOM. Annex VII(2)(b) places it in the technical documentation, Annex VII(8) covers providing it to a market surveillance authority following a reasoned request, and Annex II(9) applies if you decide to make it available to users.

Verification and validation testing

IEC 62443-4-1: SVV-1 (9.2.1, p.35), SVV-2 (9.3.1, p.35), SVV-3 (9.4.1, p.36), SVV-4 (9.5.1, p.36), Table 3 (p.37).

This test evidence speaks to Annex I Part II(3), which requires effective and regular tests and reviews of the product’s security. It also speaks to Annex VII(6), which asks for reports of the tests carried out to verify conformity. It covers:

• security requirements testing, including error scenarios and invalid input;
• threat mitigation testing, including attempts to defeat each mitigation;
• vulnerability testing, including abuse cases, attack surface analysis, known-vulnerability scanning and, for compiled software, software composition analysis;
• penetration testing.

What to check:

• Both halves of VII(6). Annex VII(6) covers conformity of the product and of the vulnerability handling processes. A report that only exercises product features leaves the second half open.
• Regular testing. The Part II requirements apply throughout the support period (Article 13(8); Commission FAQ, section 4.1.3, p.27). A pre-release report shows one point in time. Plan the tests and reviews to recur across the support period.
• Scan limits. A clean known-vulnerability scan is one input to the Annex I Part I(2)(a) requirement that products are made available without known exploitable vulnerabilities. It does not establish it on its own.
• Test conditions and independence. Some SVV-3 activities apply only where tools exist. Table 3 sets tester independence by test type: none for static analysis and software composition analysis, an independent person for abuse-case, attack-surface and known-vulnerability testing, an independent department for SVV-1 and SVV-2, and an independent department or organization for penetration testing. Record the conditions and independence that actually applied.

Defect management and disclosure

IEC 62443-4-1: DM-1 (10.2.1, p.38), DM-2 (10.3.1, p.38), DM-3 (10.4.1, p.39), DM-4 (10.5.1, p.40), DM-5 (10.6.1, p.41), SM-11 (5.13.1, p.25).

This is the densest overlap. The records cover:

• intake of issues from testers, component suppliers, developers and users, including researchers;
• timely investigation;
• impact assessment, including severity, affected products and versions, and root cause;
• decisions on how to address each issue;
• informing users of reportable issues.

These speak to Article 13(7) and 13(8). They also speak to Annex I Part II(1), (2) and (4) to (6), and to the vulnerability handling description in Annex VII(2)(b).

Where the CRA adds specific requirements:

• Dispositions. DM-4 allows a fix to be deferred with stated reasons and risks, or not made where residual risk is below the level you have set as acceptable. SM-11 holds a release until its security-related issues are addressed and tracked to closure. Under the CRA, on the basis of the risk assessment and where applicable, products are made available without known exploitable vulnerabilities (Annex I Part I(2)(a)). Vulnerabilities are also addressed and remediated without delay in relation to the risks they pose (Part II(2)). A DM-4 record documents a decision. Whether that decision meets these requirements is assessed for each product.

• Disclosure. DM-5 covers issues you designate as reportable, and its note says timeliness is driven by market forces. Part II(4) requires you, once a security update is available, to share and publicly disclose information about fixed vulnerabilities. That information covers a description, how to identify the affected product, the impact, the severity, and information to help users remediate. In duly justified cases, where you consider the security risks of publication to outweigh its security benefits, you may delay making the information public until users have had the possibility to apply the patch. Check your reportability criteria against that.

• Policy and contact. Part II(5) requires a coordinated vulnerability disclosure policy, and Part II(6) a contact address for reporting vulnerabilities. Article 13(17) requires a single point of contact. Check the evidence for each explicitly.

• Regulatory reporting. No 4-1 requirement sets CRA recipients or deadlines. Those come from Article 14:

  • Early warning and notification run from the moment you become aware: each is due without undue delay, and in any event within 24 hours for the early warning and within 72 hours for the notification. The same two stages apply to an actively exploited vulnerability (Article 14(2)(a) and (b)) and to a severe incident having an impact on the security of the product (Article 14(4)(a) and (b)).
  • Final reports have different triggers. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). For a severe incident, it is due within one month after the incident notification was submitted (Article 14(4)(c)).
  • Already-provided information. The notification and the final report are not required where the relevant information has already been provided.
  • Channel. Notifications are submitted through the single reporting platform established under Article 16, to the CSIRT designated as coordinator, and are simultaneously accessible to ENISA.
  • Users. After becoming aware of either event, you also inform the impacted users, and where appropriate all users, including where necessary the mitigation and corrective measures they can deploy (Article 14(8)).
  • Your supplier criteria do not define these triggers.

• Which Member State receives your notifications. Article 14(7) decides this. A manufacturer with its main establishment in the Union notifies the CSIRT designated as coordinator in that Member State. The main establishment is where decisions related to the cybersecurity of its products are predominantly taken or, if that cannot be determined, where it has the establishment with the highest number of employees in the Union. A manufacturer with no main establishment in the Union follows a fixed order, based on the information available to it:

  • the Member State where the authorized representative acting for the largest number of its products is established;
  • failing that, the importer placing the largest number on the market;
  • then the distributor making the largest number available;
  • then the Member State with the largest number of users.

  Work out in advance which of these rules applies to you, and which Member State it points to.

• Reporting already applies. Article 14 has applied since 11 September 2026 (Article 71(2)). Article 69(3) extends it to in-scope products placed on the market before 11 December 2027.

Security update management

IEC 62443-4-1: SUM-1 (11.2.1, p.42), SUM-2 (11.3.1, pp.42-43), SUM-3 (11.4.1, p.43), SUM-4 (11.5.1, p.43), SUM-5 (11.6.1, p.44).

The 4-1 update records cover:

• qualification that updates address the intended vulnerabilities and do not introduce regressions, including patches from component suppliers;
• user documentation for each update: affected versions, manual and automated installation, impacts such as reboots, how to verify installation, and the risks of not applying it;
• documentation of dependent component and operating system updates;
• delivery in a way that lets users verify authenticity;
• a documented policy on delivery timeframes.

They speak to Annex I Part II(2), (7) and (8), to Annex II(8)(c) on how security-relevant updates can be installed, and to the Annex VII(2)(b) description of the technical solutions chosen for the secure distribution of updates. SUM-1 states that qualification should confirm that an update does not contradict operational, safety or legal constraints. That is a recommendation in the standard, and it is listed apart from the mandatory items.

What to check:

• Timing. SUM-5 timeframes are set by your own policy. The CRA requires vulnerabilities to be remediated without delay in relation to the risks posed (Part II(2)). Available security updates must be disseminated without delay (Part II(8)).
• Update delivery. Part II(2) asks for new security updates to be provided separately from functionality updates where technically feasible. Part II(8) requires them, subject to the tailor-made business-user qualification, to be free of charge and accompanied by advisory messages. IEC 62443-4-1 does not address charging.
• Update behavior. Annex I Part I(2)(c) requires that vulnerabilities can be addressed through security updates. Where applicable, this includes automatic security updates installed within an appropriate timeframe and enabled as a default setting, with a clear and easy-to-use opt-out, notification to users of available updates, and the option to postpone them temporarily. SUM-2 documents manual and automated installation. It does not address these behaviors, so check the product itself.
• Component capability. IEC 62443-4-2 requires embedded, host and network devices to support updates. The enhancement for validating update authenticity and integrity before installation applies from SL-C 2 (EDR 3.10, 13.5, p.66; HDR 3.10, 14.5, pp.71-72; NDR 3.10, 15.7, pp.78-79). 4-2 has no update-support requirement written specifically for software applications: CR 3.10 refers to the component-specific clauses (7.12, p.52), and the software application clause (Clause 12) contains no SAR 3.10. This does not exempt software applications from update handling. 4-2 requires every component type to be developed and supported following the processes of IEC 62443-4-1 (4.5, CCSC 4, p.27), which include the SUM requirements above.

Security guidelines for users

IEC 62443-4-1: SG-1 to SG-7 (12.2.1 to 12.8.1, pp.44-47).

The 4-1 user documentation covers:

• the product’s defense-in-depth strategy and the measures expected from the environment;
• hardening guidelines, including configurable and default values;
• guidelines for removing the product from use, including secure removal of stored data;
• guidelines for secure operation;
• user and default account guidance;
• a process for tracking errors and omissions in the manuals.

This material is an input to the information and instructions to the user required by Annex II, which the technical documentation also contains (Annex VII(1)(d)). It is relevant in particular to:

• Annex II(4), the intended purpose, the security environment and the security properties;
• Annex II(5), circumstances that may lead to significant cybersecurity risks;
• Annex II(8)(a), measures for secure use;
• Annex II(8)(d), secure decommissioning, including secure removal of user data.

What to check:

• The rest of Annex II. It also requires:
  • the manufacturer’s name and contact details (1);
  • the single point of contact for vulnerability reporting and where the coordinated vulnerability disclosure policy can be found (2);
  • unique identification of the product (3);
  • where applicable, where the EU declaration of conformity can be accessed (6);
  • the type of technical security support and the end date of the support period (7);
  • how to turn off automatic security updates (8)(e);
  • information for integrators (8)(f).
• Documentation is not capability. Describing a capability does not demonstrate it.

Process records

IEC 62443-4-1: SM-1 (5.2.1, p.21), SM-12 (5.14.1, p.25).

A documented and enforced development, maintenance and support process, and records showing that all applicable security processes were completed before release, speak to the process descriptions in Annex VII(2) and to the test reports in Annex VII(6).

What to check:

• Product-specific documentation. The technical documentation relates to the specific product. It has to contain the applicable Annex VII elements, be drawn up before placing on the market, and be continuously updated, where appropriate, at least during the support period (Article 31). Annex VII sets the minimum content and does not prescribe a document structure. One practical approach, which the CRA does not prescribe, is an index that traces each applicable Annex VII element to the evidence for the product version concerned.
• Separate from the declaration. A process record is not the EU declaration of conformity, which follows the model in Annex V (Article 28(2)).

What your IEC 62443-4-2 evidence can contribute

The rows below are selected evidence links, not a complete mapping of either document. “Levels” gives the capability security levels at which the base requirement and each enhancement apply.

A 4-2 assessment covers one component. A CRA product can combine several components, software and remote data processing solutions (Article 3(1)). The Commission’s guidance makes a related point about harmonized standards: a product’s scope may be broader than a standard’s, and the manufacturer should check whether the standard covers all of the product’s risks (C(2026) 5252, paragraph 150, p.52).

Assessing what you already have

The following example is hypothetical. It is written to show the questions that decide reuse. It is not a client engagement, an audit result or a claim about what any company’s records contain.

A manufacturer sells a programmable logic controller to EU machine builders and plant operators. The controller, running firmware version 3.2, was assessed against IEC 62443-4-2 as an embedded device and reached SL-C 2 for each foundational requirement. The manufacturer’s development process has been assessed against IEC 62443-4-1. Its engineering software is sold separately. For this example, assume the manufacturer’s own classification review found that the controller does not have the core functionality of an Annex III or Annex IV category. That conclusion is part of the example, not a finding about controllers generally.

The separately sold engineering software is a product in its own right (Article 3(1) includes software placed on the market separately) and needs its own review. An action table is a practical way to hold the output: artifact, CRA provision, reuse decision, missing work, owner. Those columns are an implementation suggestion, and the CRA does not prescribe them.

Cyber Resilience Act work still to verify or complete

The points below are where a CRA assessment has to reach, whatever your IEC 62443 records already contain. For several of them your records may hold real engineering and test evidence. The assessment is what establishes that.

1. Scope and role. Which products and versions, and whether you act as manufacturer (Articles 2 and 3).
2. Classification and conformity route. Default, important class I or II, or critical, and the procedure that follows (Articles 7, 8 and 32, with Annexes III and IV).
3. The product requirements. Every point of Annex I Part I(2), assessed against your risk assessment, working from the full text of each point and its qualifications.
4. Vulnerability handling. Every point of Annex I Part II, for the support period.
5. Reporting. Articles 14 and 16. Already applicable.
6. Support period and update availability. Article 13(8) requires a support period of at least five years, unless the product is expected to be in use for less. It must reflect the expected use time, and the information used to determine it goes into the technical documentation (Annex VII(4)). Article 13(19) requires the end date to be clearly specified at the time of purchase. Under Article 13(9), each security update made available during the support period remains available for at least ten years after it was issued, or for the rest of the support period, whichever is longer.
7. User information. Annex II, in full.
8. Conformity evidence. Technical documentation, the conformity assessment procedure, the EU declaration of conformity and CE marking (Article 13(12) and 13(13), Articles 28, 30, 31 and 32, and Annexes V and VII). Article 13(13) keeps the technical documentation and the declaration available to market surveillance authorities for at least ten years after placing on the market, or for the support period, whichever is longer.

A sequence that works

Start now, in parallel with everything else: establish the Article 14 reporting capability. It already applies, so it cannot wait for the steps below. That means named people with authority to submit, registration on the single reporting platform, and your Article 14(7) Member State worked out.

Then:

1. Fix the scope: product, entity, and the versions you will assess.
2. Classify the product and determine the conformity assessment route.
3. Collect the scope records of every IEC 62443 assessment you intend to reuse: part, edition, scheme, component, version, type, levels and assumed external countermeasures.
4. Run the Annex I Part I(2) applicability pass, requirement by requirement, against your risk assessment.
5. Map your existing evidence against the groups above, and mark each item reusable, reusable with work, or not applicable.
6. Close the gaps the applicability pass found.
7. Assemble the technical documentation to Annex VII and keep it current.