Product team testing a smart-speaker-style device with microphones in an anechoic chamber

Cyber Resilience Act

IEC 62443-4-2 vs the Cyber Resilience Act and EN 18031: what overlaps, what doesn't

Last updated: 2026-11-10

IEC 62443-4-2 is the technical standard that PLC, HMI, gateway and other industrial component makers already use, organizing its component requirements under seven foundational requirements — from authentication and use control through data confidentiality, restricted data flow and resource availability. The Cyber Resilience Act (CRA) and EN 18031 are EU legal instruments with their own, independently written requirements: their technical mechanisms overlap a great deal with those seven, but their legal weight does not — applying IEC 62443-4-2 today does not, by itself, give you a presumption of conformity with either EU instrument, though it is a genuine head start on the engineering work both of them demand.

By SoftWSP Regulation Desk10 min read

Key takeaways

For each FR, the standard defines component-level security capability levels (SL-C), which let a manufacturer state the capability a component provides rather than a target the system around it must reach.
Not today. Under the EU's standardisation framework, presumption of conformity with a regulation's essential requirements comes from harmonised standards published with their reference in the Official Journal.
The table below compares what each document asks for at the mechanism level.
IEC 62443-4-2 describes what a component can do: its security capability level.

What IEC 62443-4-2 actually requires

IEC 62443-4-2:2019, "Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components," sets detailed component requirements (CRs) organised under seven foundational requirements (FRs):

#	Foundational requirement
FR1	Identification and authentication control
FR2	Use control
FR3	System integrity
FR4	Data confidentiality
FR5	Restricted data flow
FR6	Timely response to events
FR7	Resource availability

For each FR, the standard defines component-level security capability levels (SL-C), which let a manufacturer state the capability a component provides rather than a target the system around it must reach. Part 4-2 is one piece of a larger series: 4-1 covers the secure product development lifecycle, 3-3 covers system-level security requirements and security levels, and 2-4 covers requirements for service providers. A device or component maker working toward IEC 62443-4-2 is, in practice, only addressing the 4-2 slice of that series.

The IEC catalogue entry lists edition 1.0, published 27 February 2019, with the August 2022 corrigendum included, and states that target and achieved security levels (SL-T, SL-A) are out of scope. The ISASecure CSA scheme applies the standard to four component types: software application, embedded device, host device and network device. See IEC 62443-4-2 component requirements for those types.

Does IEC 62443-4-2 give CRA presumption of conformity?

Not today. Under the EU's standardisation framework, presumption of conformity with a regulation's essential requirements comes from harmonised standards published with their reference in the Official Journal. The CRA's harmonised standards are still being drafted by CEN, CENELEC and ETSI under a Commission standardisation request, and their Official Journal publication dates were unconfirmed as of 21 October 2026. IEC 62443-4-2 is an IEC/ISA industrial standard, not one of the EU-adopted harmonised standards referenced for the CRA. The practical effect: applying IEC 62443-4-2 in full is good engineering evidence for your CRA risk assessment and technical documentation, but it does not let you skip the CRA's own conformity assessment route.

The same is true in the other direction for radio equipment. EN 18031-1/-2/-3, cited in Implementing Decision (EU) 2025/138, does give a presumption of conformity with the RED's cybersecurity essential requirements under Delegated Regulation (EU) 2022/30, but only for radio equipment in scope of that delegated act, and only where none of the restrictions published alongside the standard apply. See EN 18031 explained for firmware teams for the restrictions and exclusions. IEC 62443-4-2 plays no formal role in that presumption either.

Is a European version of IEC 62443-4-2 being adapted for the CRA?

Yes, as a supporting deliverable. CEN, CENELEC and ETSI accepted the CRA standardisation request M/606 on 3 April 2025. Their M/606 work programme (version V1, 2 April 2025) lists an amendment, EN IEC 62443-4-2:2019/prAA, under "Broad vertical supporting OT deliverables." It is assigned to CLC/TC 65X WG 3, with 30 October 2026 as the deadline for adoption. Matching amendments are listed for 62443-4-1 and 62443-3-3.

What this means in practice. Under CRA Article 27, presumption of conformity comes from harmonised standards whose references appear in the Official Journal, from Commission common specifications or from EU cybersecurity certification schemes. An amended EN version would need that Official Journal citation first; the international IEC 62443-4-2:2019 text you may have bought is not a harmonised standard. Track the dates in our M/606 guide.

Where the technical mechanisms line up

The table below compares what each document asks for at the mechanism level. It is a practical reading aid, not a legal equivalence table: no regulator or standards body has published an official crosswalk between these three documents.

Mechanism	IEC 62443-4-2 (FR)	CRA Annex I Part I	EN 18031
Authentication, no shared default passwords	FR1 – identification and authentication control	Secure by default, protect against unauthorised access	Access control and authentication (all three parts, subject to the "no password" OJ restriction)
Secure update delivery	FR3 – system integrity	Fixable through security updates, automatic by default	Secure, authenticated update mechanism
Confidentiality of data and credentials	FR4 – data confidentiality	Protect confidentiality of data, commands and configuration	Secure storage and communication
Network and resource resilience	FR7 – resource availability	Protect availability, including against denial of service	Resilience and network behaviour
Logging and incident response	FR6 – timely response to events	Log security-relevant activity	Logging and user notification (EN 18031-2)
Restrict data flow / attack surface	FR5 – restricted data flow	Limit attack surface	Closing unused services and ports
Use/access control	FR2 – use control	Ship without known exploitable vulnerabilities; protect against unauthorised access	Parental/guardian access control (EN 18031-2, where applicable)

What IEC 62443-4-2 does not cover at all: the CRA's vulnerability-handling process duties under Annex I Part II, such as the SBOM, the coordinated vulnerability disclosure policy, publishing advisories, and the 24-hour reporting of actively exploited vulnerabilities. Those sit outside a component technical standard; see CRA Annex I explained and firmware SBOM for how device makers meet them in practice.

Which Annex I wording goes beyond a component capability?

IEC 62443-4-2 describes what a component can do: its security capability level. Several Annex I Part I points of the CRA describe the state of the product on the day it is placed on the market, or a default setting. Check your 4-2 evidence against this exact wording:

Annex I Part I point	CRA wording (shortened)	Why capability evidence may not cover it
(a)	made available "without known exploitable vulnerabilities"	A state of each release; needs a vulnerability scan of the shipped build, repeated for every release
(b)	"secure by default configuration" with reset to the original state	Covers the factory configuration, not only the presence of a control
(c)	automatic security updates "enabled as a default setting," with opt-out, notification and postponement	Specific defaults and user options
(g)	process only data that is "adequate, relevant and limited" to the intended purpose	Data minimisation is a design decision, not a component control
(i)	minimise the negative impact on "services provided by other devices or networks"	Outbound behaviour towards third parties
(l)	record and monitor relevant internal activity, "with an opt-out mechanism for the user"	The opt-out is a CRA-specific user right

Source: Regulation (EU) 2024/2847, Annex I Part I. The right-hand column is SoftWSP's reading, not an official mapping.

Where does IEC 62443-4-2 evidence go in the CRA technical file?

Into Annex VII, mainly as a "relevant technical specification." Until a harmonised standard is cited, Annex VII point 5 of the CRA asks for "descriptions of the solutions adopted to meet the essential cybersecurity requirements," including "a list of other relevant technical specifications applied." That is the natural place to name IEC 62443-4-2 and the SL-C you claim.

Annex VII point	What it asks for	IEC 62443-4-2 evidence that fits	Still needed
2(a)	Design and system architecture	Component architecture and the security functions per FR	Product-specific diagrams
2(b)	Vulnerability handling processes, including the SBOM and CVD policy	Little; this is process evidence (closer to 62443-4-1)	SBOM, CVD policy, contact address, update distribution
3	Cybersecurity risk assessment, including how Part I applies	Threat and capability analysis per FR	A point-by-point Part I applicability statement
5	Standards applied, or solutions adopted	IEC 62443-4-2 named as a technical specification applied	Solutions for Part I points it does not reach
6	Test reports for Part I and Part II	Functional security and vulnerability test results, for example from an ISASecure CSA assessment	Tests of the vulnerability handling process

Source: Regulation (EU) 2024/2847, Annex VII. Evidence columns are SoftWSP's reading.

Which conformity assessment route applies?

It depends on the product's class, and IEC 62443-4-2 does not change the class. Under Article 32 of the CRA, a product's route follows from Annex III and IV. A product is "important" when it has the core functionality of an Annex III category (Article 7(1)).

Product (examples from the Annex)	Class	Route when no harmonised standard is applied in full
Industrial component with no Annex III or IV core functionality, such as many PLCs and sensors	Default	Internal control (module A)
Routers, modems for internet connection, switches; physical and virtual network interfaces; network management systems	Annex III class I	EU-type examination (module B + C) or full quality assurance (module H)
Firewalls, intrusion detection and prevention systems	Annex III class II	Module B + C or H, even with harmonised standards, or a certification scheme at assurance level "substantial"
Hardware devices with security boxes; smart meter gateways; smartcards and secure elements	Annex IV critical	Article 32(4) procedures, including certification where required

Source: Regulation (EU) 2024/2847, Articles 7, 32 and Annexes III and IV.

Article 32(2) is the key point for OT makers: for class I, applying IEC 62443-4-2 is not "applying harmonised standards," so the self-assessment route stays closed. See CRA conformity assessment and Annex III and IV categories for details.

What does this look like for an industrial gateway?

A hypothetical example: a managed industrial Ethernet switch with a web interface and its own firmware, already assessed against IEC 62443-4-2 at SL-C 2.

Classify twiceFor IEC 62443-4-2 it is a network device. For the CRA its core functionality matches "switches" in Annex III class I, point 12.
Pick the routeWith no CRA harmonised standard cited, Article 32(2) requires module B + C or module H. Budget for a notified body.
Reuse the FR evidenceMap FR1–FR7 test results to Annex I Part I points (d), (e), (f), (h), (j) and (l) using the mechanism table above.
Close the Part I gapsWrite the default-configuration, automatic-update and data-minimisation statements. Run an SBOM-based vulnerability scan of the release image for point (a).
Build the Part II processSBOM, CVD policy, advisories, secure update distribution and the Article 14 reporting path.
Assemble Annex VIIName IEC 62443-4-2 under point 5 and attach the test reports under point 6.

Practical use for component and machine makers

Treat IEC 62443-4-2 as a technical baseline, not a compliance shortcutIf you already assess components against it, you already have most of the evidence CRA Annex I Part I and EN 18031 ask for; reuse it rather than redoing the work from scratch.
Add the process pieces separatelySBOM, VEX, coordinated disclosure and 24-hour reporting are CRA duties that no version of IEC 62443-4-2 satisfies; build them alongside, not instead of, your component security work.
Watch for the CRA harmonised standardsOnce CEN, CENELEC and ETSI publish them and the Commission references them in the Official Journal, the self-assessment route for class I important products may become easier to document; until then, keep your IEC 62443-4-2 evidence and CRA risk assessment as separate, cross-referenced files.
Classify each product firstPLCs, HMIs and industrial gateways with digital elements fall under the CRA like any other connected product; some also fall under the EU Machinery Regulation. See Machinery Regulation cybersecurity for the machine-level duty to identify safety-relevant software.

Which mistakes cost time?

Waiting until December 2027 for everything. Article 71(2) of the CRA applies the Article 14 reporting duties from 11 September 2026 and the notified-body chapter from 11 June 2026. Reporting of actively exploited vulnerabilities already applies; see CRA 24h/72h reporting.
Treating an SL-C claim as a CRA class. Capability levels and CRA classes answer different questions. A switch at SL-C 4 is still Annex III class I.
Citing the IEC edition as if it were harmonised. Annex VII point 5 distinguishes harmonised standards with an Official Journal reference from other technical specifications.
Scanning once. Part I point (a) applies to each release placed on the market, so the SBOM and vulnerability scan belong in the release pipeline.

The CRA readiness check gives a first view of which of these duties apply to a product.

SoftWSP maps your existing IEC 62443-4-2 evidence against the CRA and produces the SBOM and vulnerability list the regulation requires on top of it: see machine builders and device firmware security.

This guide is general information, not legal advice.

Put this guide to work

ServiceDevice & Firmware SecurityFirmware SBOM, vulnerability match and fix.See the service

ComplianceCRA readiness self-checkA short self-assessment against the Cyber Resilience Act Annex I categories. Informational only, not a conformity assessment.Free

Frequently asked questions

Does complying with IEC 62443-4-2 automatically satisfy the Cyber Resilience Act?

No. CRA presumption of conformity comes from harmonised standards adopted through the EU's standardisation process. As of writing, CRA harmonised standards are still being drafted by CEN, CENELEC and ETSI under a Commission standardisation request, and IEC 62443-4-2 is not one of them. It can still serve as design evidence and a starting point for a CRA risk assessment, but it does not by itself grant self-assessment eligibility.

What are the seven foundational requirements in IEC 62443-4-2?

Identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. IEC 62443-4-2 sets detailed component requirements (CRs) under each one, plus component-level security capability levels (SL-C).

How is IEC 62443-4-2 different from EN 18031?

Scope and legal status differ. IEC 62443-4-2 is a voluntary IEC/ISA standard for industrial automation and control system (IACS) components such as PLCs, HMIs and gateways. EN 18031 is an EU harmonised standard that gives a presumption of conformity under the RED cybersecurity delegated act, but only for radio equipment. The technical mechanisms they describe, such as authentication, secure update and secure communication, overlap even though the two standards were written independently and there is no official crosswalk between them.

Does IEC 62443-4-2 cover the CRA's SBOM and vulnerability-reporting duties?

No. IEC 62443-4-2 sets technical requirements for a component, not process obligations. A secure development lifecycle is covered by a separate part of the series, IEC 62443-4-1, and even that does not map one-to-one onto the CRA's Annex I Part II duties such as the SBOM, the coordinated vulnerability disclosure policy, or 24-hour reporting of actively exploited vulnerabilities.