# Cybersecurity requirements of the Machinery Regulation: what a manufacturer must actually do

> From 20 January 2027 the CE marking of machinery includes cyber requirements (Annex III, 1.1.9 and 1.2.1). The typical reaction (securing the whole machine) is wrong and expensive. What a manufacturer must concretely do, in what order, with which choices: scoping the safety-relevant perimeter, extending the risk assessment, choosing the EN 50742 path, the technical measures, reusing the CRA work. With an operational checklist.

- URL: https://albertoscarpa.com/blog/en/machinery-regulation-cybersecurity-manufacturer/
- Lingua / Language: English
- Published: 2026-09-20
- Tags: Machinery, CRA, IEC 62443, AI Act

---

*Updated September 2026. prEN 50742 is still a draft and its harmonisation status is evolving: check the latest version and status before any formal use.*

From 20 January 2027 the CE marking of a machine includes, for the first time, cybersecurity requirements. Regulation (EU) 2023/1230 brings two sections into Annex III, protection against corruption (1.1.9) and safety of control systems (1.2.1), which ask for things until now foreign to mechanical safety. The most common reaction, when a manufacturer reads them, is to think "I need to secure the whole machine". That reaction is wrong, and expensive.

The task is more circumscribed than that, and (this is the good news) it grafts onto things the manufacturer *already does*: the risk assessment, the technical file, the declaration of conformity. This article does not repeat what the law says (for the full picture, the annexes and the relationship with the CRA, NIS2 and IEC 62443 there is the guide [Machinery Regulation (EU) 2023/1230](/guide/en/machinery-regulation/)), but tries to answer the next question: and now, in practice, where do I start and what do I put in place?

## First move: scope the "safety-relevant" perimeter

The single mistake that makes the work balloon is treating 1.1.9 as "do full-blown cybersecurity on the machine". That is not what it asks. The requirement is targeted: a corruption (accidental or malicious) of hardware, software or data **relevant to safety** must not translate into a hazardous situation. It is cybersecurity in the service of safety, not information security in the broad sense.

The difference is concrete. Confidentiality of production data, service continuity, theft of know-how are real problems, but they are not the object of 1.1.9: they belong, if anywhere, to the CRA or to the security of the organisation. Here only the portion in which a manipulation produces a *physical* hazard to people matters.

Hence the first concrete step, before any technical measure: **taking an inventory of what is relevant to safety**. Which machine functions, if altered, generate a hazard? Which hardware components implement them? Which software and (an often-forgotten point) which *data* (parameters, thresholds, set-points, safety logic) govern them? What ends up in this list is the perimeter of the Regulation's cyber requirements. Everything else, for the purposes of 1.1.9, is out.

An example of filled-in rows, to fix the columns:

| Safety-relevant function | Hardware component | Software | Critical data | Hazard if altered |
|---|---|---|---|---|
| Safe stop of the axis | Safety module/PLC | Safety firmware, safety logic | Reaction times, speed thresholds, travel limits | Failure to stop: crushing or impact on the operator |
| Monitoring of an interlocked guard | Safety sensor + relay | Input-monitoring logic | Safety input configuration | Open guard not detected: access to moving parts |

Every row of this table is a candidate for the risk scenarios of the next step: if it is not in the list, it is not a requirement of the Regulation.

> Operational note (my reading, not the text of the law). This inventory is the most valuable document of the whole exercise, because it is also what defends you against over-engineering: when someone proposes to encrypt everything or to harden a subsystem that does not touch safety, the question is only one: is that component in the list of the "safety-relevant" ones? If not, it is not a requirement of the Machinery Regulation.

## Extend the risk assessment you already do

Risk assessment and reduction remain the pillar of conformity, as in Directive 2006/42/EC. The novelty is not adding a separate document: it is **extending the analysis you already conduct** with scenarios you did not consider before, those of tampering.

Concretely, alongside the failures and misuse you already assess, scenarios of corruption, accidental and intentional, of what you put in the inventory come in. Some examples to tabulate:

- alteration of the control system firmware (local flashing, unauthenticated update, downgrade to a vulnerable version);
- tampering with safety parameters (thresholds, reaction times, operating limits) via a service interface;
- a command injected through a remote connection, a fieldbus or a diagnostic port left open;
- corruption of data in transit between a safety sensor and the control logic.

For each scenario, the Regulation's question is always the same: can this corruption lead to a hazardous situation? Where the answer is yes, a measure is needed. Where it is no, you document why and stop. It is the same mindset as mechanical risk assessment, applied to a new class of causes.

Tabulated, a filled-in scenario has this form:

| Corruption scenario | Can it generate a hazard? | Measure | Ref. |
|---|---|---|---|
| Unauthenticated firmware update of the safety PLC | Yes, altered firmware can disable the stop | Digital signature and secure boot, block downgrade to vulnerable versions | 1.2.1 |
| Change of reaction times via service interface without authentication | Yes, altered thresholds delay the stop | Authentication on functions that touch safety parameters, log of the change | 1.1.9 |
| Reading production data from a diagnostic port | No, no effect on safety | None for the purposes of 1.1.9 (a CRA topic, if anything) | - |

The last row counts as much as the first two: documenting *why* a scenario requires no measure is what keeps the file defensible and the work proportionate.

## Choose the conformity path: prEN 50742, approach A or B

The essential requirements say *what* to achieve, not *how*. The "how" will be provided by the supporting technical standard: prEN 50742 ("Safety of machinery - Protection against corruption"), a candidate to become the harmonised reference standard for 1.1.9. Note: as of this article it is still a draft (prEN 50742), not published as harmonised. You can (and should) set up the work on it already now, but the harmonisation status must be checked before invoking its presumption of conformity.

The standard provides **two alternative paths**, and it is a choice worth making early because it steers everything else:

- **Approach A, based on risk assessment.** Designed for machines not originally engineered to IEC 62443. You start from the corruption scenarios of your risk assessment and adopt proportionate measures, without first having to embrace the entire apparatus of industrial security.
- **Approach B, based on IEC 62443.** You adopt the requirements of the IEC 62443 series (vulnerability management, access control, integrity of software and data, protection of interfaces), adapted to the machinery sector.

The selection criterion is almost always one: **where you start from**. If you already work along IEC 62443 lines, because you serve OT (operational technology) customers or because you are preparing for the CRA, Approach B is the direct route: that work is not just reusable evidence, it is the main road to the presumption of conformity. If instead you start from a "traditional" machine, Approach A gets you to the result without the cost of adopting the whole 62443 framework just for the occasion. A point about roles not to lose: the standard that grants the presumption of conformity is prEN 50742, not 62443 as such; 62443 is the technical apparatus on which one of the two paths rests.

## The technical measures, mapped to the requirements

With the perimeter clarified and the path chosen, the concrete measures group into four families, all anchored to what 1.1.9 and 1.2.1 ask.

| Family of measures | What the Regulation asks | Typical measures | Ref. |
|---|---|---|---|
| **Integrity of critical software and data** | Safety-relevant software and data "identified as such and adequately protected against accidental or intentional corruption" | Integrity and authenticity verification of firmware (digital signature, secure boot where the control system allows it), authenticated-only updates, block downgrade to vulnerable versions | 1.2.1 |
| **Access control and protection of interfaces** | Connection to another device "of any kind" must not be able to generate a hazard | Authentication to access functions that touch safety parameters, closing by default of unnecessary ports, segmentation between the safety control network and the rest | 1.1.9 |
| **Evidence of tampering** | There must be evidence of an intervention (legitimate or illegitimate) on safety-critical components | Logs of access and of changes to safety parameters, hardware tamper-evidence where it makes sense, traces that after an event tell whether something was touched | 1.1.9 |
| **Control systems that resist corruption** | Control systems must "withstand the intended effects of a corruption" | Segregation of the safety function from the rest of the logic, safe fallback state if an alteration is detected, no direct path from the "connected and convenient" part to what stops or starts in safety | 1.2.1 |

Two reading keys the table alone does not give. The first: the objective is precise, to prevent the code and the parameters that govern safety from being altered without the machine noticing. The second concerns evidence of tampering, the most often neglected requirement because it is not "prevent" but "make ascertainable": you do not need an industrial security event management system (SIEM), you need a manipulation not to pass invisibly.

For each family, the calibration is given by the risk assessment: the measure is adequate when it reduces the hazardous scenario to an acceptable level, not when it exhausts the state of the art of cybersecurity. This is, again, what keeps the cost under control.

## Do not duplicate: reuse the work done for the CRA

A modern machine with digital elements and connections is almost always, at the same time, a "product with digital elements" under the CRA (Regulation (EU) 2024/2847) and a machine under 2023/1230. You do not choose: you satisfy both. But the two acts do not ask you to do the same work twice.

Conformity with the CRA cybersecurity requirements **can cover** requirements 1.1.9 and 1.2.1 of the Machinery Regulation, provided you demonstrate it. Where the CRA has already led you to build software integrity, access management, vulnerability management, much of the evidence for Annex III is already produced. The efficient thing is **a single body of evidence and a single declaration of conformity** citing both regulations, not two parallel streams.

A distinction of scope remains to keep explicit: the CRA looks at the cyber resilience of the product as a whole, for its entire useful life; the Machinery Regulation looks only at the tampering that generates a physical hazard. The CRA work eases the Machinery one, but does not exhaust it, and vice versa. For the CRA framework there is the guide [The CRA in one hour](/guide/en/cra-in-one-hour/); on how much CRA work counts elsewhere too, [You are a manufacturer subject to the CRA. Does NIS2 concern you as a company too?](/blog/en/manufacturer-cra-nis2/).

## The special case: a safety function entrusted to AI

A caveat for those who put machine learning inside a safety function. If a safety function is realised by a system with evolving or self-adapting behaviour based on ML, the machine enters the **high-risk** ones of Annex I. For these categories the conformity assessment (Art. 25) stiffens: internal control with self-certification is no longer the ordinary route and, for safety functions based on self-evolving ML, the involvement of a **notified body** is typically required. A nuance not to take for granted: the exact applicable path depends on the Annex I category and on the existence and full application of harmonised standards, so it must be checked against Art. 25. In any case the procedure changes, not just the technical requirements, and it must be factored into the timeline.

On the technical side the maturing reference is ISO/IEC TS 22440 (functional safety of AI systems), born precisely for the problem classical standards were not designed to handle: behaviour that changes over time. And there is a second hat: the same function typically also falls under the AI Act, which qualifies as high-risk the AI systems that are safety components of harmonised products. They are not alternatives: they are two lenses on the same component, to be mapped in parallel from the design stage. If you are not entrusting safety functions to AI, this section does not concern you and the perimeter remains that of the previous paragraphs.

## Documentation and instructions for the user

The measures must be recounted where conformity is demonstrated. Into the **technical file** go the inventory of safety-relevant components, the risk assessment extended to corruption scenarios, the measures adopted and their justification, the prEN 50742 path followed. The **EU declaration of conformity** cites the standards applied and, where relevant, both the Machinery Regulation and the CRA.

Then there is a piece that touches the user. Many measures work only if the machine is installed and managed correctly: the **instructions for use** must say how to configure it securely (credentials to change, ports not to expose, updates to apply) and where the manufacturer's responsibility ends and that of the integrator or user begins. A machine delivered secure but with the diagnostic port open and the default password is a risk that can, and must, be closed with the instructions, not with the hardware alone.

## What to do now

20 January 2027 seems far off, but it is not for those who design machines with a multi-year development cycle: the machines in design today are the ones that will be placed on the market under the new regime. Machine cybersecurity is **designed from the start**, not added at the end: a secure-by-design costs a fraction of a retrofit on a machine already closed.

In summary, the concrete steps:

1. **Inventory** the safety-relevant components, software and data. It is the perimeter, and it is what defends you against over-engineering.
2. **Extend the risk assessment** with the accidental and intentional corruption scenarios of that perimeter.
3. **Choose the prEN 50742 path**: Approach A (risk-based) or B (IEC 62443), depending on where you start from.
4. **Apply the measures** on four fronts: integrity of software and data, access control and interfaces, evidence of tampering, control systems that resist corruption.
5. **Reuse the CRA work**: one body of evidence, one declaration of conformity citing both.
6. If a safety function uses **evolving AI**, factor in the notified body and the double lens with the AI Act.
7. **Document** in the technical file and translate into instructions for use what depends on whoever installs and manages.

The thread that holds it all together is the initial scoping: these requirements do not ask you to become a cybersecurity company, they ask you to ensure that no tampering with the right components turns into a hazard to people. Done well, it is a proportionate job, and largely already started, if you are working on the CRA.

---

If you are designing now a machine that will be placed on the market under the new regime, the hard part is not reading Annex III: it is scoping the "safety-relevant" perimeter in your specific product, without widening it (expensive) or narrowing it too much (non-compliant).

The **Regulatory Spark** is a 45-minute call to do exactly this: where tampering with the right components can generate a hazard in your machine, which prEN 50742 path is preferable and how much of the CRA work you can reuse. You leave with a written summary, a direction and, if you need it, the template for the inventory of safety-relevant components, the table above ready to fill in. No fluff.

**[Book the Regulatory Spark](/en/regulatory-spark/)**


---

*References: Regulation (EU) 2023/1230 (Machinery Regulation), Annex I on the high-risk categories and Annex III, sections 1.1.9 (protection against corruption) and 1.2.1 (safety and reliability of control systems); application from 20 January 2027. Regulation (EU) 2024/2847 (CRA). prEN 50742 "Safety of machinery - Protection against corruption" (draft, not yet harmonised). ISO/IEC TS 22440 (functional safety and AI systems). IEC 62443 series. The notes flagged as operational are my interpretations, not regulatory text; section numbers and the publication status of the technical standards must be verified against the act and the Commission's official list before any formal use. The full picture is in the guide [Machinery Regulation (EU) 2023/1230](/guide/en/machinery-regulation/).*