Key takeaways
- A machine builder reading the Machinery Regulation's Annex III sections 1.1.9 and 1.2.1 finds two short, plain-language cybersecurity clauses with no technical detail underneath them.
- Full background on these two clauses, their dates and their relationship to the CRA is in our Machinery Regulation cybersecurity guide.
- Run the Annex III risk assessment first, and use IEC 62443-3-3's seven FRs as a checklist for what to test, not as a document to attach instead of the risk assessment itself.
A machine builder reading the Machinery Regulation's Annex III sections 1.1.9 and 1.2.1 finds two short, plain-language cybersecurity clauses with no technical detail underneath them. A control-system engineer who already works with IEC 62443 has a seven-category, clause-by-clause requirement set sitting on the shelf. The two were written independently, for different legal purposes, and the Regulation itself does not name IEC 62443 anywhere. This guide lines up what actually overlaps, and is explicit about the one thing neither document gives you: an automatic pass.
What the Machinery Regulation's own text requires
Regulation (EU) 2023/1230, applying from 20 January 2027, sets two cybersecurity-relevant clauses in Annex III:
- Section 1.1.9 (protection against corruption): safe connections, protected hardware interfaces with evidence of intervention, identified and protected safety-critical software and data, machine-readable software identification "at all times," and evidence of changes to installed software or configuration.
- Section 1.2.1 (safety and reliability of control systems): control systems must withstand "reasonably foreseeable malicious attempts from third parties" that could cause a hazard, and a tracing log of interventions and safety-software uploads must be kept for five years.
Full background on these two clauses, their dates and their relationship to the CRA is in our Machinery Regulation cybersecurity guide.
What IEC 62443-3-3 and 4-2 actually specify
IEC 62443-3-3 sets system requirements (SRs) for a control system as a whole, organised under seven foundational requirements (FRs): identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. IEC 62443-4-2 takes the same seven foundational requirements down to the level of a single component requirement (CR) — a PLC, HMI, gateway or embedded device — which is closer to where Annex III 1.1.9's hardware-interface and software-identification language actually operates. Full detail on each is in our IEC 62443-3-3 and IEC 62443-4-2 guides.
Where the two line up
| Machinery Regulation clause | What it asks for | Closest IEC 62443-3-3/4-2 foundational requirement |
|---|---|---|
| 1.1.9 — safe connections | Connecting another device must not cause a hazard | FR2 Use control, FR5 Restricted data flow |
| 1.1.9 — protected hardware interfaces, evidence of intervention | Tamper-evidence on interfaces carrying safety-relevant signals | FR3 System integrity, FR6 Timely response to events |
| 1.1.9 — identify the software, at all times | Machine-readable inventory of safety-relevant software | No direct FR equivalent; closer to an SBOM-style control than a 62443 requirement |
| 1.1.9 — evidence of changes | Log of legitimate/illegitimate software or configuration changes | FR3 System integrity, FR6 Timely response to events (audit logging) |
| 1.2.1(a) — withstand malicious attempts | Control system resists third-party attack attempts that could cause a hazard | All seven FRs, collectively — this is the broadest clause on either side |
| 1.2.1(f) — five-year tracing log | Retained log of interventions and safety-software uploads, for authority requests | FR6 Timely response to events (partial — retention period and purpose are Machinery Regulation-specific, not in 62443) |
Two gaps are worth calling out directly: the "identify the software at all times" duty in 1.1.9 reads more like a software-inventory or SBOM obligation than a classic 62443 technical control, and the five-year retention period in 1.2.1(f) is a Machinery Regulation-specific duty that IEC 62443's audit-logging requirements do not themselves define. Treat IEC 62443 as covering the technical mechanism (logging, access control, integrity checking); the retention period and inventory format are separate design decisions a machine builder still has to make.
Why this is evidence, not certification
Article 20(9) of the Machinery Regulation gives a presumption of conformity with sections 1.1.9 and 1.2.1, but only for machinery certified, or covered by a statement of conformity, under a cybersecurity certification scheme adopted under the Cybersecurity Act (Regulation (EU) 2019/881) and referenced in the Official Journal. As of writing, no such scheme has been referenced for these sections, and harmonised standards for 1.1.9/1.2.1 are still under development, so their identity and dates are to be confirmed against the Official Journal when published. IEC 62443 is a voluntary IEC/ISA industrial-automation standard, developed independently of the EU's standardisation process — using it does not, by itself, satisfy Article 20(9).
What it does give a machine builder is structured, testable evidence for the risk assessment Annex III already requires: a documented set of requirements to test a control system or component against, test methods already defined by the standard, and a vocabulary (foundational requirements, security levels) that EU notified bodies and market surveillance authorities are likely to recognise even without a formal cross-reference in the Regulation. The same caution applies on the Cyber Resilience Act side of a machine's compliance picture — see IEC 62443-4-2 vs the CRA and EN 18031 for why that standard doesn't grant CRA presumption of conformity either.
What a machine builder should do with this mapping
Run the Annex III risk assessment first, and use IEC 62443-3-3's seven FRs as a checklist for what to test, not as a document to attach instead of the risk assessment itself. File evidence against the specific clause it supports(1.1.9 vs 1.2.1), not as a generic "IEC 62443 compliant" statement — a notified body or auditor will expect to trace evidence back to the Regulation's own text. Design the software-identification and five-year log duties separately, since neither is a direct IEC 62443 requirement; treat them as machine-level SBOM and logging-retention design decisions. Watch for the harmonised standardOnce the European Commission references a cybersecurity certification scheme or harmonised standard for sections 1.1.9/1.2.1, re-check whether it changes what IEC 62443 evidence can be used for. Keep component-level evidence (IEC 62443-4-2) and system-level evidence (62443-3-3) in separate files, since a machine typically integrates components from several suppliers, each with its own test evidence.
SoftWSP maps a machine's component inventory and known vulnerabilities against Annex III 1.1.9/1.2.1 and the underlying IEC 62443 foundational requirements, without requiring source code from every component supplier: see services for machine builders.
This guide is general information, not legal advice.
Sources
- Regulation (EU) 2023/1230 on machinery, EUR-Lex
- Regulation (EU) 2024/2847 (Cyber Resilience Act), recital 53, EUR-Lex
- IEC Webstore: IEC 62443-3-3:2013 — Industrial communication networks – Network and system security – Part 3-3
- IEC Webstore: IEC 62443-4-2:2019 — Security for industrial automation and control systems – Part 4-2
- ISA: The ISA/IEC 62443 Series of Standards
Frequently asked questions
Does meeting IEC 62443 automatically satisfy the Machinery Regulation's cybersecurity requirements?
No, not automatically. Presumption of conformity with Annex III sections 1.1.9 and 1.2.1 comes from Article 20(9) of Regulation (EU) 2023/1230, which applies only to machinery certified under a cybersecurity certification scheme adopted under the Cybersecurity Act, Regulation (EU) 2019/881, and referenced in the Official Journal. IEC 62443 is not, as of writing, such a scheme, and no harmonised standard has yet been published against these two sections. IEC 62443-3-3 and 62443-4-2 are still useful as working technical evidence for a risk assessment, but they do not by themselves grant a presumption of conformity.
Which parts of IEC 62443 map most directly onto Annex III 1.1.9 and 1.2.1?
IEC 62443-3-3's seven foundational requirements (identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability) cover much of what 1.1.9's "protection against corruption" and 1.2.1's "withstand reasonably foreseeable malicious attempts" describe in plain language, at the control-system level. IEC 62443-4-2 breaks the same seven requirements down to individual components — a single PLC, HMI or gateway — which is the level Annex III 1.1.9's "identify the software" and "protect hardware interfaces" clauses actually bite at.
Does IEC 62443 cover the five-year tracing log the Machinery Regulation requires?
Not directly. Section 1.2.1(f) requires a tracing log of interventions and safety-software version uploads kept for five years after upload, solely to demonstrate conformity on a reasoned authority request. IEC 62443-3-3's System Requirement SR 6.1 (audit log accessibility) and the broader "timely response to events" foundational requirement cover logging as a security capability, but neither one is written around the Machinery Regulation's specific five-year retention period or its narrow purpose (demonstrating conformity to an authority), so a machine builder still needs to design that retention period in separately.
Does using IEC 62443-4-2 also help with the Cyber Resilience Act?
Partially, and in the same limited way. See our dedicated [IEC 62443-4-2 vs CRA guide](/guides/iec-62443-4-2-vs-cra/) for the full comparison; in short, 62443-4-2's technical component requirements overlap with CRA Annex I Part I's design requirements, but neither 62443-4-2 nor the Machinery Regulation mapping in this guide covers the CRA's own process duties — SBOM, coordinated vulnerability disclosure, and 24-hour reporting — which come from a different part of the CRA entirely.
What should a machine builder actually do with this mapping today?
Use IEC 62443-3-3 and 4-2's structured requirement lists as a checklist when building the Machinery Regulation's required cybersecurity risk assessment, and keep the resulting evidence (test results, component security-level claims, design decisions) filed against the specific Annex III clause it supports, rather than filing it as generic "IEC 62443 compliance." That keeps the evidence usable even if, or when, a different scheme is eventually recognised under Article 20(9).
In this cluster
