Machinery Regulation and Cyber Resilience Act

Not the same compliance framework, but distinct obligations

A connected machine is not compliant merely because it is mechanically safe. Nor is it cyber-secure merely because it implements functional safety functions.

Regulation (EU) 2023/1230 and the Cyber Resilience Act — Regulation (EU) 2024/2847 — address two different risks and must be managed as two parallel compliance workstreams.

Scope and objective

The Machinery Regulation 2023/1230 governs machinery, related products and partly completed machinery. Its objective is to ensure safety and the protection of health in design and construction by addressing risks arising from intended use and reasonably foreseeable misuse.


It repeals the Machinery Directive 2006/42/EC.

The CRA 2024/2847, by contrast, is a horizontal regulation covering products with digital elements placed on the EU market in the course of a commercial activity. It therefore covers products that are connected physically or logically, for example through hardware interfaces, network sockets, APIs, files, pipes and other software interfaces, including where the connection is only indirect.

The CRA is horizontal, but it does not displace lex specialis. Products covered by sector-specific regulations with equivalent cybersecurity requirements, such as medical devices, vehicles and aeronautical products, may therefore be excluded from the CRA’s essential requirements and conformity assessment procedures.

Topic	Machinery Regulation 2023/1230	CRA 2024/2847
Primary risk	Physical injury and harm to health; functional harm	Cyber compromise, exploitation of vulnerabilities, and impact on availability, integrity and confidentiality
Regulatory approach	Essential health and safety requirements, supported by the risk assessment	Essential cybersecurity requirements throughout the product’s entire lifecycle
Design focus Safety integrated into the machinery, predictable behaviour, fault management, and protection against risks arising also from malicious third-party actions Secure by design and by default, vulnerability management, security updates, protection of communications and traceability Software Software that performs a safety function and is independently placed on the market is a safety component Software may itself be a product with digital elements; monetised open-source components integrated into commercial products may also fall within scope Conformity assessment Technical file, EU declaration of conformity and CE marking; more stringent procedures for high-risk categories, including systems with fully or partially self-evolving behaviour that ensure safety functions EU declaration of conformity and CE marking; more stringent procedures for important and critical products	Safety integrated into the machinery, predictable behaviour, fault management, and protection against risks arising also from malicious third-party actions	Secure by design and by default, vulnerability management, security updates, protection of communications and traceability Software Software that performs a safety function and is independently placed on the market is a safety component Software may itself be a product with digital elements; monetised open-source components integrated into commercial products may also fall within scope Conformity assessment Technical file, EU declaration of conformity and CE marking; more stringent procedures for high-risk categories, including systems with fully or partially self-evolving behaviour that ensure safety functions EU declaration of conformity and CE marking; more stringent procedures for important and critical products
Software	Software that performs a safety function and is independently placed on the market is a safety component Software may itself be a product with digital elements; monetised open-source components integrated into commercial products may also fall within scope Conformity assessment Technical file, EU declaration of conformity and CE marking; more stringent procedures for high-risk categories, including systems with fully or partially self-evolving behaviour that ensure safety functions EU declaration of conformity and CE marking; more stringent procedures for important and critical products	Software may itself be a product with digital elements; monetised open-source components integrated into commercial products may also fall within scope Conformity assessment Technical file, EU declaration of conformity and CE marking; more stringent procedures for high-risk categories, including systems with fully or partially self-evolving behaviour that ensure safety functions EU declaration of conformity and CE marking; more stringent procedures for important and critical products
Conformity assessment	Technical file, EU declaration of conformity and CE marking; more stringent procedures for high-risk categories, including systems with fully or partially self-evolving behaviour that ensure safety functions	EU declaration of conformity and CE marking; more stringent procedures for important and critical products

Accordingly, while the Machinery Regulation expressly introduces the need to consider risks arising from malicious third parties, it does so from the perspective of machinery safety: the objective is to prevent a cyber compromise from creating a physical or functional hazard. The CRA, by contrast, starts from the product’s cyber resilience and requires the manufacturer to manage security throughout the entire lifecycle, reduce vulnerabilities and ensure appropriate security updates.

Functional safety is not cybersecurity

A PLC, robot or industrial video analytics system may have a robust functional safety architecture, safe-stop logic, redundancy and fault diagnostics, and comply with the requirements of the Machinery Regulation, while still presenting vulnerabilities in network services, firmware updates, integration APIs or the software supply chain.

The essential cybersecurity requirements are set out in Annex I to the CRA and cover the entire lifecycle:
secure configuration;
protection against unauthorised access;
data confidentiality and integrity;
vulnerability management;
security updates;
the ability to detect and manage incidents.

• secure configuration;
  
• protection against unauthorised access;
• data confidentiality and integrity;
  
  
• vulnerability management;
• security updates;
• the ability to detect and manage incidents.

Article 13 of the CRA expressly requires the manufacturer to identify and document cybersecurity risks, maintain the technical documentation, manage vulnerabilities, provide security updates for the declared support period and generate an SBOM in a machine-readable format, including CycloneDX.An SBOM (Software Bill of Materials) is a structured inventory of the software components contained in a product: libraries, dependencies, open-source components, proprietary modules and, where relevant, the relationships between them. It is the software equivalent of the bill of materials for a mechanical machine.
CycloneDX is a standard for describing a product’s components and their dependencies in a structured, machine-readable form.

Overlapping, not duplicate, regulations

Where there is a connected machine, the issue is not which regulation to apply, but which risks each regulation covers.

• The Machinery Regulation requires machinery to be safe in use and risks arising from malicious interference to be addressed to the extent necessary for safety.
  
  
• The CRA requires the digital product to be resilient to cyber threats, irrespective of its sector. Remote data processing solutions developed by the manufacturer — for example, the cloud service required for the remote control of a device — fall within the scope of the CRA where they are necessary for the product to function.

Deadlines and obligations

• Machinery Regulation 2023/1230: applicable from 14 January 2027.
  CRA 2024/2847: the principal placing-on-the-market obligations apply from 11 December 2027; the reporting obligations start earlier, on 11 September 2026.
  
  From 11 September 2026, in the event of an actively exploited vulnerability or a severe incident, the manufacturer must submit an initial early-warning notification to ENISA/the designated CSIRT within 24 hours, a notification within 72 hours and a final report within 14 days, subject to any extensions provided for by the Regulation. This means that the window for integrating an SBOM, threat modeling, a secure development lifecycle, vulnerability management and a security update process forms part of the compliance plan.
  
  
• CRA 2024/2847: the principal placing-on-the-market obligations apply from 11 December 2027; the reporting obligations start earlier, on 11 September 2026.
  
  
• From 11 September 2026, in the event of an actively exploited vulnerability or a severe incident, the manufacturer must submit an initial early-warning notification to ENISA/the designated CSIRT within 24 hours, a notification within 72 hours and a final report within 14 days, subject to any extensions provided for by the Regulation. This means that the window for integrating an SBOM, threat modeling, a secure development lifecycle, vulnerability management and a security update process forms part of the compliance plan.
  

What to bring under control

For a manufacturer of connected machinery:

1. Map the product against both scopes: machinery, related product, partly completed machinery and product with digital elements, checking for any sector-specific exclusions.
   
2. Keep the physical and functional safety risk assessment separate from cybersecurity threat modeling.
   
3. Treat firmware, software safety components, APIs, OTA updates and open-source dependencies as objects of compliance, rather than as implementation details.
   
4. Define a vulnerability management process with SLAs, a reporting channel and patch-release capability.
   Build a technical file capable of supporting both Machinery Regulation and CRA compliance, without confusing functional safety evidence with cybersecurity evidence.
5. Build a technical file capable of supporting both Machinery Regulation and CRA compliance, without confusing functional safety evidence with cybersecurity evidence.

The operational bridge from regulatory requirement to resilience

The Machinery Regulation requires machinery to be safe in use and risks arising from malicious interference to be addressed to the extent necessary for safety. The CRA, by contrast, requires the digital product to be resilient to cyber threats throughout its entire lifecycle.

In an industrial environment, these two objectives converge on a practical question: when a suspicious event or attack occurs, how can the organisation respond without turning cyber defence into a new risk to production?

This is where Agger, Gyala’s IT/OT/IoT cybersecurity platform, provides an operational approach. The platform integrates detection and reaction capabilities that can be customised down to the individual endpoint, together with an OT Defence module capable of actively querying connected industrial devices, including through standard protocols such as S7, MMS and SNMP.

This makes it possible to contextualise the security response according to the actual state of the OT infrastructure — production, maintenance, cleaning or other operating phases — and to calibrate detection and reaction actions in order to preserve safety and operational continuity. The platform is also designed to ensure the 24/7 resilience of IT/OT/IoT infrastructures through automated, customisable response rules.

In other words, regulatory compliance defines what must be protected; Agger helps determine how to protect it without stopping what must remain operational.

Primary sources

• Regulation (EU) 2023/1230, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2023/1230/oj/ita
  
• Regulation (EU) 2024/2847 — Cyber Resilience Act, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj