Cybersecurity risk assessment for machinery: what the Machinery Regulation and the CRA need from it, with a STRIDE example

The risk assessment is the most familiar document in machine building. Every machine has one under EN ISO 12100, and every design office knows the method: identify the hazard, rate the risk, define the measure, justify the residual risk. The procedure stays the same. What comes on top is a second category of causes, deliberate interference, and two regulations demand the assessment for it. How the CRA and the Machinery Regulation interact and what has to be in place by which deadline are covered in separate articles. This one is about the document itself: what does the Machinery Regulation need from it, what does the CRA need, and what does the assessment look like on a concrete machine?

The Machinery Regulation asks about the hazard, the CRA about the protection

The Machinery Regulation (EU) 2023/1230 asks: can an attack endanger people? Annex III requires protection against corruption (1.1.9): connecting the machine to other devices must not lead to a hazardous situation, safety-relevant software and data must be protected against manipulation, and interventions must be evidenced. Added to that are control systems that withstand malicious attempts as well (1.2.1). That is the familiar 12100 logic, extended to the attack as a cause of a hazard.

The CRA asks more broadly: is the product secured appropriately for its risks? That applies even where no safety consequence looms: recipe data crossing into the customer network in plain text, a remote access route as a stepping stone, production downtime from disrupted communication. Art. 13(2) and (3) require assessing the risks, feeding the outcome into planning, design, development and maintenance, and keeping the assessment current throughout the support period; under Art. 13(4) it becomes part of the technical documentation (Annex VII). The essential requirements of Annex I explicitly apply "on the basis of the risks". Which requirement is implemented how, or excluded with justification, is decided by exactly this assessment.

The safety-relevant part is a subset of the CRA perspective. The Commission explicitly allows a manufacturer to keep a single risk assessment for several pieces of legislation, as long as conformity with each can be demonstrated individually (Commission FAQ v1.4, no. 4.1.1). In practice that means one threat analysis per system type, from which both deliverables are derived. The Machinery Regulation side goes into the machine's existing risk assessment, the CRA side into the technical documentation. Writing two separate documents from scratch doubles the work and produces contradictions.

The Machinery Regulation needs the safety slice of the analysis

From the threat analysis, the Machinery Regulation takes exactly the rows that can reach a safety function or trigger a hazard. For the risk assessment under EN ISO 12100, four things are needed from them:

• the list of interfaces through which an intervention reaches the controller,
• the scenarios in which an intervention defeats a safety function or releases a movement,
• the measures that protect safety-relevant software and data against manipulation,
• the evidence that interventions are logged (1.1.9).

Assumptions about the operating environment, such as a remote access that the operator has to enable, belong in the instructions for use, otherwise they are not evidenced in an audit. For machines placed on the market from 20 January 2027, the assessment has to exist by that date; anyone delivering then introduces it into the current order book.

The technical detail comes from the draft standard prEN 50742 "Protection against corruption", intended as the harmonised standard for 1.1.9 and 1.2.1. The draft requires a cyber risk assessment in three steps (identify critical assets, analyse threats, determine the required protection level) and introduces four safety-related security levels for it, SRSL 0 for fully isolated networks up to SRSL 3. For manufacturers with established industrial security processes, the draft provides the route via IEC 62443 as an alternative. The final vote was scheduled for September 2026 and publication is expected towards the end of 2026; until it is listed in the Official Journal the draft remains guidance without a presumption of conformity.

The CRA needs every row mapped to Annex I and the residual risks justified

The CRA takes every row of the threat analysis, including those without a safety consequence. Under Art. 13(3) and (4) it needs from the document:

• the statement of which requirements in Annex I Part I point 2 apply to the machine and how they are implemented,
• a justification for every requirement that does not apply (Commission FAQ v1.4, no. 4.1.3),
• the residual risks with justification,
• filing in the technical documentation under Annex VII.

For the row "OPC UA unencrypted" that means: mapping to the confidentiality requirement in Annex I Part I point 2, measure, residual risk.

On residual risks the Commission sets the yardstick. Under the guidelines pursuant to Art. 26 (C(2026) 5252, paras 157 to 159), a residual risk is not measured against the manufacturer's own risk appetite but against whether the product is appropriately secured for its intended purpose; cost considerations do not justify an untreated risk (paras 158 and 163). The instructions for use may carry assumptions, such as operation only in a trusted environment or behind a network boundary (para 162); they do not replace a gap in the design, and the responsibility stays with the manufacturer (para 161). Added to that are the support period, which the analysis takes into account under Art. 13(8), and the information for the operator under Annex II. The guidelines are not legally binding, but they are the reading a market surveillance authority will rely on.

The assessment is written per system type, not per order

The most common objection is: "every one of our machines is one of a kind." For the cyber threat landscape that is rarely true. Whether the machine folds boxes or fills bottles, the attack surface is set by the control platform, the operator level, the remote access route and the connection to the customer network, and those repeat across the portfolio. The Commission sees it the same way: for product variants that share architecture, security-relevant design and risks, one risk assessment and one set of technical documentation suffice; only differences that affect cybersecurity, such as other interfaces or a different remote access, have to be reflected in the assessment (C(2026) 5252, paras 174 to 176). The assessment is therefore produced once per system type or control platform. In the individual order only the delta is checked and recorded: additional interfaces, the specific MES connection, deviating components. That keeps the effort per project at hours rather than days and is the shape an auditor expects: base assessment plus project-specific addendum.

STRIDE is the usual method for the threat list

Neither regulation prescribes a method. The Commission FAQ on the CRA (v1.4, no. 4.1.2) only requires that the threat modelling fits the product's intended purpose and that the authority can trace how risks were identified, evaluated and treated. The Machinery Regulation names no method, and prEN 50742 also only calls for a threat analysis. The closest thing to a recommendation is IEC 62443-4-1: it lists STRIDE among its abbreviations and uses it in clause 9.3.2 as the example of how the effectiveness of countermeasures is tested.

STRIDE sorts threats into six categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The value is in the method: the six questions are asked per interface, wherever data enters or leaves the system. On a typical machine that is a handful of points:

• the engineering access to the controller,
• the operator level (HMI, local panels),
• the remote access route,
• the machine network itself (fieldbus, PROFINET/EtherCAT),
• the interface to the customer network (MES/ERP, usually OPC UA),
• USB ports and removable media.

Six interfaces times six questions yield a table of manageable size. Completeness along the interfaces counts for more than depth at the individual component: what is inside the firmware of a purchased PLC is assessed by its manufacturer, and the machine builder may rely on their advisories.

Worked example: a packaging machine with remote access

Concretely, on a typical machine: PLC and safety controller, HMI panel, servo drives on PROFINET, a remote access router with VPN and an OPC UA connection to the operator's MES. The table shows one scenario per STRIDE category. In the real assessment there are several rows per interface, but the structure stays the same:

The "applies to" column is the switch between the two regulations: if the scenario endangers people or defeats a safety function, the row additionally belongs in the Machinery Regulation risk assessment. Every row is CRA-relevant.

IEC 62443 supports the assessment as checklist and catalogue of measures

The series does not replace the risk assessment; it supports it in three places. Part 4-1 (requirement SR-2) lists what a threat model has to contain: data flows, trust boundaries, interfaces to external systems, implemented protocols, externally accessible physical ports, possible attack vectors, mitigations and external dependencies such as third-party software. That list serves as a completeness check for the STRIDE table; the standard also requires the model to be reviewed at least annually. Part 3-2 is the integrator's system view: the system is partitioned into zones and conduits, and a target security level is set per zone. That is the structure in which the network segmentation from the table above is justified. Parts 3-3 and 4-2, finally, provide the catalogue of measures from which the "measure" column draws its references.

For the CRA, IEC 62443 is not a harmonised standard and therefore gives no presumption of conformity; as recognised state of the art it remains the usual evidence until the CRA standards are listed in the Official Journal. For the Machinery Regulation, prEN 50742 provides the route via IEC 62443 as an equivalent alternative. Aligning the assessment with 62443 therefore serves both regulations with the same structure.

In an audit the justification fails, not the method

The typical weak points are the justifications: an accepted residual risk without a documented reason, CRA Annex I requirements ticked off across the board instead of on a risk basis, assumptions about the operating environment that never made it into the instructions for use. Gaps like these only show up in the reading: in an audit, in a damage case, when an end customer asks.

At the bottom of the document there is a signature. The safety risk assessment is signed by someone who has applied the procedure hundreds of times; the cybersecurity risk assessment is signed by the same head of design or project lead for the first time. That is why the first assessment per system type should not be produced alone: it has to hold up to scrutiny when it matters.

The finished assessment consists of six parts

System description with network diagram, operating environment and assumptions; threat analysis per interface; risk rating with measures; mapping of every row to Annex I of the CRA and, where a safety function is affected, to Annex III of the Machinery Regulation; residual risks with justification; maintenance rule. Each chapter provides the basis for the one after it, and the two mappings are the deliverables that go into the technical documentation and into the 12100 assessment.

The offer: one base assessment per system type, ready for signature in two weeks

Werkspilot produces the base assessment for one system type in two sessions: system capture with network diagram and interfaces, then a walkthrough of the results with the design team. The STRIDE analysis is produced in between. After two weeks a signature-ready assessment is on the table, with both deliverables (the Machinery Regulation part for the machine's risk assessment, the CRA part for the technical documentation) and the maintenance rule for the per-order deltas. The design team signs it; the second session is there so that they know what they are signing.

Request an intro call →

We send the template with the structure described on request, with name, company and system type, together with a proposed date for a walkthrough on the reader's own system type: request the template.

The assessment is written once and updated when there is a trigger

The assessment is produced once per system type and revisited when triggered: on a substantial modification, a new interface, a changed threat landscape. The CRA requires updates throughout the support period (Art. 13(3)), IEC 62443-4-1 a review at least once a year. Separate from that is the ongoing work: matching new supplier advisories against the systems in the field and, in the worst case, reporting within the deadlines. The risk assessment is the one-off part of the CRA work, the monitoring is the daily one, and that is exactly what Werkspilot automates.

Werkspilot produces STRIDE threat analyses as part of the risk assessment and automates ongoing vulnerability management across the field base of plant builders and integrators. This article reflects Werkspilot's assessment and does not replace legal advice; the regulation texts themselves are authoritative. The Commission FAQ and guidelines are not legally binding; prEN 50742 is cited as a draft.