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

IEC 62443-4-2 is the technical standard that PLC, HMI, gateway and other industrial component makers already use. 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; 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, but it is a genuine head start on the engineering work both of them demand.

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.

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 are not yet confirmed. 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.

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.

Practical use for component and machine makers

1. Treat IEC 62443-4-2 as a technical baseline, not a compliance shortcut. If 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.
2. Add the process pieces separately. SBOM, 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.
3. Watch for the CRA harmonised standards. Once 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.
4. Classify each product first. PLCs, 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.

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.