Protection Against Corruption under the Machinery Regulation: Annex III Section 1.1.9 in the Risk Assessment
From 20 January 2027, Annex III, Part B, section 1.1.9 of the Machinery Regulation (EU) 2023/1230 requires that connected devices and remote access do not lead to a hazardous situation, that safety-relevant hardware, software and data are protected against accidental and intentional corruption, and that the machine identifies its safety-relevant software and collects evidence of interventions. Section 1.2.1 adds that control systems, where appropriate, withstand reasonably foreseeable malicious attempts by third parties and that interventions and uploaded safety software remain traceable for five years after upload; you assess both in the risk assessment. CE-Copilot covers protection against corruption as part of the risk assessment: interface inventory, 15 threat scenarios as hazards with measures at three levels, based on the draft standard prEN 50742, and an evidence checklist, on the Starter plan from €119 per month (licence for three months at a time, final price; checklist in the test reports from Professional).
What section 1.1.9 requires
Section 1.1.9 “Protection against corruption” is new in machinery legislation. It has five paragraphs, summarised here from the consolidated version:
Connected devices and remote access
1.1.9, 1st paragraph
Connecting another device, via any feature of that device or via a remote device communicating with the machinery, must not lead to a hazardous situation.
Safety-relevant hardware
1.1.9, 2nd paragraph
Hardware components transmitting signals or data relevant for access to software that is critical for compliance must be adequately protected against accidental or intentional corruption. The machinery collects evidence of legitimate or illegitimate interventions in these components.
Software and data
1.1.9, 3rd paragraph
Software and data that are critical for compliance with the essential health and safety requirements must be identified as such and adequately protected against accidental or intentional corruption.
Identification of installed software
1.1.9, 4th paragraph
The machinery identifies the installed software necessary for safe operation and is able to provide that information at all times in an easily accessible form.
Evidence of interventions in software and configuration
1.1.9, 5th paragraph
The machinery collects evidence of legitimate or illegitimate interventions in the software and of modifications of the installed software or its configuration.
Link with section 1.2.1 “Safety and reliability of control systems”
Section 1.2.1 applies the same idea to the control system. Control systems must, where appropriate to the circumstances and the risks, withstand external influences, explicitly including reasonably foreseeable malicious attempts from third parties leading to a hazardous situation (point (a)). A fault in the hardware or the logic of the control system must not lead to hazardous situations (point (b)). The limits of the safety functions are established in the risk assessment, and hazardous modifications of settings or rules are not allowed, including during a learning phase (point (d)). Point (f) is new: the tracing log of the data generated in relation to an intervention and of the versions of safety software uploaded after placing on the market must be available for five years after upload, upon a reasoned request of a competent national authority.
Two further points concern every connected machine: with wireless control, a failure of communication or connection, or a faulty connection, must not lead to a hazardous situation (section 1.2.1, last paragraph), and the interruption, re-establishment or fluctuation of the communication network connection must not lead to hazardous situations (section 1.2.6). The protection goal of all these requirements is the safety of persons, not the protection of data or know-how.
What the manufacturer has to show
The Machinery Regulation does not prescribe a particular technology, but every requirement has to be met in a traceable way. In practice this evidence is produced:
| Requirement | Section | Typical evidence |
|---|---|---|
| Interfaces do not lead to a hazardous situation | 1.1.9, 1st para. | Interface inventory, threat scenarios with measures per interface in the risk assessment, interface description for integrators |
| Safety-relevant hardware protected, interventions traceable | 1.1.9, 2nd para. | List of protected assemblies, seals, locked ports, event list of the control system with a sample log |
| Software and data identified and protected | 1.1.9, 3rd para. | Register of safety-relevant software and data with versions and checksums, description of integrity checks and access protection |
| Installed software identifiable at all times | 1.1.9, 4th para. | Screenshot of the version display, comparison with the acceptance report |
| Interventions in software and configuration logged | 1.1.9, 5th para. | Change and event log with user, time, content and version, export route |
| Control system withstands foreseeable malicious attempts by third parties | 1.2.1, point (a) | Security concept with zones, roles and password rules, hardening evidence, test report |
| No hazardous modifications of settings or rules | 1.2.1, point (d) | Limits of the safety functions from the risk assessment, write protection of safety-relevant parameters |
| Tracing log for five years after upload | 1.2.1, point (f) | Storage and retention concept for intervention data and safety software versions, export procedure for authority requests |
| Loss of the communication network or radio link is not hazardous | 1.2.6; 1.2.1, last para. | Test report on communication loss and restart in all modes, stopping time on link loss |
The technical documentation contains the risk assessment with the list of applicable requirements and the protective measures (Annex IV, Part A, point (b)) and the test reports (point (g)). Point (m) is new: the source code or programming logic of safety-related software is made available upon a reasoned request of a competent national authority where it is needed to check the essential requirements (see also Article 10(3)).
prEN 50742, IEC 62443 and the presumption of conformity
prEN 50742 “Safety of machinery, protection against corruption” is the draft standard for section 1.1.9, prepared at CENELEC. In Germany it has been issued as draft DIN EN 50742 (VDE 0113-742):2026-03. According to a technical article by IBF Solutions GmbH (last updated 5 October 2026) the project is in the approval stage; when the EN will be published is not fixed. The draft has no reference in the Official Journal under the Machinery Regulation. A presumption of conformity under Article 20(1) only arises with such a reference.
According to that article the draft describes two approaches. Approach A builds on a manufacturer-specific threat analysis to EN ISO 12100, that is within the usual risk assessment. Approach B uses the IEC 62443 series with the secure development process (IEC 62443-4-1), the system requirements (-3-3) and the component requirements (-4-2).
IEC 62443 is the established series for the IT security of industrial automation systems and a good orientation for security measures. Under the Machinery Regulation it is not a harmonised standard and gives no presumption of conformity. If you apply it, describe it in the technical documentation as a technical specification applied (Annex IV, Part A, point (f)) and show in the risk assessment how the measures reduce the hazards to persons.
Article 20(9) provides a further route to presumption: machinery certified, or covered by a statement of conformity, under a cybersecurity certification scheme adopted under Regulation (EU) 2019/881 whose references are published in the Official Journal is presumed to meet sections 1.1.9 and 1.2.1 insofar as the certificate or statement covers those requirements. Check whether such a scheme is an option for your product at all.
Relation to the Cyber Resilience Act and the Radio Equipment Directive
- Cyber Resilience Act (EU) 2024/2847. Applies to products with digital elements, including connected machinery, and protects the cybersecurity of the product over its lifetime. The reporting obligations under Article 14 apply since 11 September 2026, also to products already delivered; the other obligations apply to products placed on the market from 11 December 2027. According to recital 53, meeting the CRA requirements can facilitate showing compliance with sections 1.1.9 and 1.2.1; the manufacturer demonstrates the synergy and follows the conformity assessment under both regulations. CRA conformity does not create a presumption for section 1.1.9. Details in the guide Cyber Resilience Act for machinery.
- Radio Equipment Directive 2014/53/EU. For radio equipment placed on the market from 1 August 2025 to 10 December 2027, the cyber requirements of Article 3(3)(d), (e) and (f) apply through Delegated Regulation (EU) 2022/30, with the EN 18031 series. Delegated Regulation (EU) 2026/339 repeals it with effect from 11 December 2027; the CRA takes over from then. Whether a machine with a permanently installed radio module counts as radio equipment as a whole is not conclusively settled.
The same interface can therefore appear in up to three assessments with different protection goals: persons (Machinery Regulation), network and data (Radio Equipment Directive) and the product over its lifetime (CRA). Timeline and methods in the guide Cybersecurity of machinery.
Approach in seven steps
1. Record interfaces and assets
Every route by which data or commands reach the machine: network and fieldbus, remote maintenance, cloud connection, radio, USB and memory cards, operator panel with parameter management, programming access to the control system, update path, accessible safety hardware in the control cabinet and connected third-party devices. Add the software and data that are critical for safety, such as the safety program, limit values and muting parameters.
2. Identify threats as hazards
For each interface ask: can accidental or intentional corruption trigger a hazardous situation? Typical scenarios are safety parameters changed over the network, remote access while someone works in the danger zone, an unreleased software version after an update, bridged safety contacts or a communication loss followed by an unexpected restart.
3. Estimate and evaluate the risk
As for any other hazard: severity of possible harm and probability. For security scenarios the probability mainly depends on how reachable the interface is (internet, local network, on site only), the effort required and whether an intervention would be detected.
4. Define measures in order of priority
Following section 1.1.2(b), design first, for example safety-relevant parameters held only in the safety controller and not writable over the process network; then technical protective measures such as authentication, signed updates, segmentation and logging; information for use last.
5. Evaluate residual risk and verify effectiveness
Re-assess the residual risk per scenario and test the measures: version display, log entries after an update, behaviour on communication loss, on-site release of remote access. The results belong to the test reports under Annex IV, Part A, point (g).
6. Evidence in the technical documentation
The risk assessment with the list of applicable requirements including section 1.1.9 and the protective measures (Annex IV, Part A, point (b)), the technical specifications applied for draft standards or IEC 62443 (point (f)) and the test reports (point (g)). Source code or programming logic of safety-related software is made available upon a reasoned request of a competent national authority (point (m), Article 10(3)).
7. Information in the instructions
Section 1.7.4.2 has no separate security item. The information belongs to putting into service and use (point (k)), residual risks (point (l)) and protective measures to be taken by the user (point (m)): where the software version is displayed, the update procedure followed by a functional test of the safety functions (section 1.1.2(e)), requirements for the operator's network, release of remote access and retention of the logs.
Examples: interface, threat, measures
| Interface | Threat | Typical measures |
|---|---|---|
| Network, OPC UA, MES | Unauthorised write access changes muting times or speed limits | Safety parameters only in the safety controller, not writable over the process network; authentication, checksum of the safety configuration, log of every change |
| Remote maintenance, VPN | Program change or reset from remote while persons are in the danger zone | Remote access without a path to the safety controller, release on site only and time-limited, “remote access active” indication, session log |
| Software update | Manipulated or unreleased version of the safety software is installed | Signed firmware checked before activation, checksum on the operator panel, version entry kept for five years, functional test after every update |
| Control cabinet | Safety contacts bridged or DIP switches of the safety module changed | Locked cabinet, seals, coded connectors, opening recorded with a time stamp |
| Fieldbus, radio | Communication loss, then unexpected start with outdated setpoints | Time monitoring of safety telegrams, transition to the safe state, restart only after acknowledgement |
How CE-Copilot covers protection against corruption
CE-Copilot follows approach A of the draft prEN 50742: the threat analysis is part of the risk assessment to EN ISO 12100, rated with the same risk score from severity and probability as every other hazard.
“Protection against corruption” module in the risk assessment
Appears in the risk assessment editor as soon as the machine description mentions digital interfaces such as network, remote maintenance, USB, radio or an operator panel with parameter management; otherwise you show it via “Assessments under further legislation”. The interface inventory covers ten interface types and is pre-filled from the description; explicitly negated mentions such as “no Wi-Fi” are not taken over. You confirm or correct the selection, which is saved in the machine profile of the project.
from Starter
15 threat scenarios as hazards
For the selected interfaces the module proposes matching scenarios, from parameter manipulation over the network to missing logging. Only what you tick in the selection dialog is taken over: as a hazard of the type “Corruption/Security” with scenario, life cycle phases, legal reference, pre-filled severity and probability and measures at three levels. The reference follows the legal framework of the project: in a Machinery Regulation project Annex III, sections 1.1.9, 1.2.1 and 1.2.6; in a Machinery Directive project Annex I, sections 1.2.1 and 1.2.6 as the state of the art, with a note on section 1.1.9 from 20 January 2027. Each scenario lists the matching system requirements of IEC 62443-3-3 as a reference.
from Starter
AI hazard search that looks at the interfaces
If the inventory contains interfaces, the AI hazard search additionally asks for machine-specific scenarios in which corruption at exactly these interfaces can trigger a hazardous situation, assessed like the other hazards. The suggestions are drafts for your technical review.
from Starter, within the plan's AI allowance
Evidence in the export
The PDF and Word export of the risk assessment and the overall project dossier contain a “Protection against corruption” box with the number of assessed scenarios, the interface inventory and the legal basis, including the explicit note that there is no presumption of conformity without a reference in the Official Journal.
from Starter
Test report section with twelve requirements
Requirements A1 to A12 relate to sections 1.1.9, 1.2.1 and 1.2.6, plus instructions and the update process, each with legal reference, the evidence expected and a reference to IEC 62443. In a Machinery Regulation project all twelve are mandatory; in a Machinery Directive project the requirements that exist only in the Regulation are shown as recommendations for placing on the market from 20 January 2027.
from Professional
Cybersecurity chapter in the instructions
Checked interfaces appear in the instructions with designation, protocol, connection and update route. Information on access protection is deliberately kept out of the document so that the instructions do not become a description of vulnerabilities.
operating instructions module from Professional, one-off purchase per project
One inventory for the Machinery Regulation, radio equipment and the CRA
You maintain details per interface and the assets to be protected once; the radio equipment module and the “Cybersecurity (CRA)” page use the same inventory. The module also points out that the cyber risk assessment under the CRA is a separate assessment alongside section 1.1.9.
inventory from Starter, Cybersecurity (CRA) page from Professional
What CE-Copilot does not do: no certification, no penetration testing, no review of your control software and no classification into security levels under IEC 62443 or the draft standard (approach B is named per scenario as a reference, not carried out). The app does not contain the text of prEN 50742. Plans and prices are listed on the pricing page; where else your machine needs work before 20 January 2027 is shown by the free Machinery Regulation readiness check.
FAQ
Frequently asked questions
Does section 1.1.9 apply to every machine?
From when do I have to show protection against corruption?
Is prEN 50742 a harmonised standard?
Is applying IEC 62443 enough?
How does protection against corruption relate to the Cyber Resilience Act?
Does protection against corruption have to be part of the risk assessment?
What belongs in the instructions regarding protection against corruption?
Is there software that integrates protection against corruption into the risk assessment?
Sources
Run EU machinery compliance in-house, in English
This guide is written by the team behind CE-Copilot, a software platform covering the whole EU CE process for machinery: directive classification, a standards finder across 3,600+ standards with harmonisation status, risk assessment per EN ISO 12100, functional safety documentation, test reports, the technical file, operating instructions and the EU Declaration of Conformity. Documents are exported in seven languages, including Chinese, and the EU Declaration of Conformity in German, English, French, Italian, Spanish and Polish. The platform is available in English; the AI drafts, you review and sign off.
More English guides
This guide is general information for machinery manufacturers, verified against the official EU legal texts as of 3 November 2026. It is not legal advice. For decisions about your specific product, consult the legal texts (EUR-Lex) or a qualified advisor.