Cybersecurity risk assessment under the CRA and the Machinery Regulation: what belongs in it – with an example
In brief · As of July 2026
Two regulations require a documented cybersecurity risk assessment: the CRA for the product as a whole (Art. 13, part of the technical documentation under Annex VII), the Machinery Regulation for the safety-relevant side (Annex III, 1.1.9 and 1.2.1). In practice both deliverables come out of one threat analysis per system type – the usual tool is STRIDE along the system's interfaces. The assessment is a one-off task per type, with only the delta documented per order; the ongoing part is vulnerability management.
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 goes into the cybersecurity risk assessment, how it is scoped, and what it looks like on a concrete machine?
The Machinery Regulation asks about hazard, the CRA about 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 – and 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? – including 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 as 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.
| Machinery Regulation | CRA | |
|---|---|---|
| Protected asset | Health and safety of persons | Cybersecurity of the product as a whole |
| Basis | Annex III, esp. 1.1.9 and 1.2.1 | Art. 13(2)–(3), Annex I, Annex VII |
| Typical question | Does the attack cause a hazard? | Is the risk treated appropriately? |
| Mandatory from | 20 Jan 2027 | 11 Dec 2027 (fully applicable) |
The safety-relevant part is thus a subset of the CRA perspective. 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.
Scoping: 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 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 it is the shape an auditor expects: base assessment plus project-specific addendum.
The tool: STRIDE along the interfaces
STRIDE sorts threats into six categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The value is not in the terms but in the method: the six questions are asked not per component but 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 beats depth at the individual component: what is inside the firmware of a purchased PLC is assessed by its manufacturer, and you may rely on their advisories.
Example: 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:
| Threat | Scenario and consequence | Measure | Applies to |
|---|---|---|---|
| Spoofing | A device on the machine network poses as an engineering station and connects to the unprotected PLC – third-party program changes become possible. | Enable controller access protection (protection levels, passwords), segment the machine network. | CRA + MR |
| Tampering | Manipulation of the PLC program or drive parameters; a changed speed limit becomes a mechanical hazard. | Write protection and integrity checks, safety functions on a separate F-CPU or hard-wired. | CRA + MR |
| Repudiation | After an incident it cannot be established who accessed the machine via remote access and when – the Machinery Regulation explicitly requires this evidence (1.1.9). | Logging on the remote access router, individual accounts instead of a shared login. | CRA + MR |
| Information disclosure | The OPC UA interface transmits recipe and production data unencrypted into the customer network – no hazard, but a confidentiality risk. | Enable an OPC UA security policy (sign and encrypt), manage certificates. | CRA only |
| Denial of service | A broadcast storm from the customer network disrupts PROFINET communication; the machine faults and the line stops. | Network transition only via router/firewall with defined connections, no flat coupling. | CRA only |
| Elevation of privilege | The remote access uses a shared password and is permanently open – anyone who knows it has full access down to the controller. | Individual accounts with two-factor login, access switchable by the operator (key switch). | CRA + MR |
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.
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: six parts
System description with network diagram, operating environment and assumptions, threat analysis per interface, risk rating with measures and mapping to the requirements, residual risks with justification, maintenance rule. Each chapter provides the basis for the one after it.
The offer: base assessment per system type
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 your design team. The STRIDE analysis is produced in between. After two weeks you have a signature-ready assessment – with both deliverables (the Machinery Regulation part for the machine's risk assessment, the CRA part for the technical documentation) and the maintenance rule your team uses to keep the per-order deltas itself.
The template with the structure described is available on request – with a brief note of your name, company and system type. We send it over and check back after two weeks to see how far you have got: request the template.
Updating: a one-off task, maintained when triggered
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 explicitly requires updates throughout the support period (Art. 13(3)). Separate from that is the ongoing work: continuously 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.
Questions from practice
Is the existing risk assessment under EN ISO 12100 sufficient?
No. The existing document stays valid and is supplemented by the threat analysis; it is not replaced.
Does every machine need its own cybersecurity risk assessment?
No. The scoping follows the control platform and the interfaces, not the individual order.
Which method does the legislator require?
None. The CRA and the Machinery Regulation are method-neutral; what is required is traceability. Common practice is STRIDE for the threats, a simple rating grid of likelihood and impact, and IEC 62443 as the reference framework for measures.
Is the risk assessment a one-off or ongoing?
The document is the one-off part. What is ongoing is vulnerability management across the delivered field base – the part where manual processes fail the 24-hour deadline.
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.