What changed from the Directive to the Regulation
The shift from a Directive to a Regulation is more than a technicality. Directives require national transposition, which meant 27 slightly different implementations across EU member states. Regulations apply directly and uniformly. From 20 January 2027, every machine builder selling into the EU faces the same rules, interpreted the same way, with no national wiggle room.
Beyond the legal form, the Regulation introduces several substantive changes that reflect how machinery has evolved since 2006.
Software is now explicitly a safety component. The old Directive focused on physical hardware. The Regulation recognises that software performing a safety function, even when placed on the market independently, constitutes a safety component subject to all conformity assessment obligations. This single change pulls countless software-driven safety systems into regulatory scope.
Cybersecurity enters the essential health and safety requirements. Two new EHSRs (1.1.9 and 1.2.1) mandate protection against corruption of safety-relevant systems. These have no equivalent in the old Directive.
Substantial modification triggers manufacturer obligations. If someone significantly modifies a machine, they become the manufacturer for regulatory purposes, inheriting the full set of obligations including the new cybersecurity requirements. This matters for system integrators who retrofit or upgrade existing installations.
The high-risk machinery list has expanded. Annex I now covers more machine categories requiring mandatory third-party conformity assessment. Machines with AI-based safety functions appear explicitly, requiring Notified Body involvement regardless of whether harmonised standards have been applied.
Digital documentation is permitted. Instructions for use and EU Declarations of Conformity can be supplied digitally, with paper copies available on request. A small but practical modernisation.
The transition is a hard cut-off. Until 19 January 2027, only the old Directive applies. From 20 January 2027, only the Regulation applies. There is no overlap period where manufacturers can choose. If you place a machine on the market on that date, it must comply with the new rules.
The two cybersecurity requirements explained
The Machinery Regulation’s cybersecurity obligations are concentrated in two essential health and safety requirements within Annex III.
EHSR 1.1.9 on protection against corruption
This requirement states that machinery’s safety-relevant software, data, and hardware components that transmit signals or data must be identified as such and protected against corruption. The term “corruption” is deliberately broad, encompassing accidental corruption (a garbled signal, a bit flip, a failed update) and intentional corruption, including malicious attacks.
The practical implication is straightforward but far-reaching. Every machine builder must first identify which software, data, and hardware elements are safety-relevant. Then they must demonstrate that adequate protective measures are in place. “Adequate” is where the engineering judgement comes in, and where the emerging standards provide guidance.
EHSR 1.2.1 on safety and reliability of control systems
This requirement extends the existing obligation for reliable control systems by adding that they must withstand “reasonably foreseeable malicious attempts by third parties” that could lead to a hazardous situation.
The phrase “reasonably foreseeable” does important work here. It does not require protection against every conceivable nation-state attack. But it does require manufacturers to think about what kinds of malicious interference are realistic given the machine’s connectivity, deployment environment, and exposure. A machine connected to the public internet faces different reasonably foreseeable threats than one operating on an isolated backplane bus inside a locked cabinet.
What this means in practice
Together, these two EHSRs create a new obligation that sits between traditional functional safety and full IT security. The Regulation does not ask machine builders to become cybersecurity companies. It asks them to ensure that the safety functions they have already designed and validated cannot be undermined through digital means.
This is fundamentally a safety-first perspective on cybersecurity. The question is not “can someone steal data from this machine?” but “can someone manipulate this machine into hurting someone?” Confidentiality of business data, while important, is not what these EHSRs address. They focus squarely on integrity and availability of safety functions.
The standards landscape for machinery cybersecurity
Machinery safety standards follow a three-tier hierarchy that has served the industry well for decades. Understanding where cybersecurity fits into this hierarchy is essential for navigating what comes next.
Type A standards establish fundamental safety concepts and design principles applicable to all machinery. EN ISO 12100 is the sole Type A standard. It defines the risk assessment methodology that underpins everything else. Currently being revised to incorporate cybersecurity considerations, the updated draft explicitly acknowledges that threats to IT security can result in hazardous situations.
Type B standards address specific safety aspects or safeguard types across many machine categories. EN ISO 13849-1 (Performance Levels for safety-related control systems) and IEC 62061 (Safety Integrity Levels for programmable systems) are the most widely used. Neither currently addresses cybersecurity in any meaningful depth, though the 2023 edition of EN ISO 13849-1 at least acknowledges the topic. The critical new addition here is prEN 50742, which is being developed specifically to address protection against corruption.
Type C standards provide detailed requirements for specific machine types. Hundreds of these exist, and they typically reference the Type A and B standards while adding machine-specific provisions. None currently cover cybersecurity, and few are expected to develop bespoke cybersecurity clauses. Instead, they will reference prEN 50742 for cybersecurity, just as they reference EN ISO 13849-1 or IEC 62061 for functional safety.
The roughly 800 harmonised standards currently listed under the old Machinery Directive are being transitioned to the Regulation. Each will receive a new Annex ZB mapping its requirements to the Regulation’s EHSRs, alongside the existing Annex ZA mapping to the Directive. The European Commission issued a standardisation mandate to CEN/CENELEC on 20 January 2025, with a draft work programme due by July 2025.
Critically, these existing standards do not address the new cybersecurity EHSRs. That is precisely why prEN 50742 is being developed as a complementary standard. The intended model is that manufacturers apply their existing (transitioned) harmonised Type C standard plus prEN 50742 to cover all Regulation requirements, including cybersecurity.
prEN 50742 in depth
prEN 50742, titled “Safety of machinery – Protection against corruption,” is the single most important new standard for machinery cybersecurity. Developed by CLC/TC 44X (Safety of machinery, electrotechnical aspects), it went to public enquiry in late 2025 with a CENELEC deadline of February 2026. Once finalised and harmonised under the Regulation, applying it will give manufacturers a presumption of conformity with EHSRs 1.1.9 and 1.2.1.
Scope and approach
The standard covers hardware components (including interfaces to remote devices and control systems), software, and data, wherever they could influence the safety of machinery. It applies across the full lifecycle, from development through manufacturing, commissioning, operation, maintenance, and decommissioning.
One of its most pragmatic features is the dual-approach structure. Manufacturers can choose between two paths.
Approach A (Clauses 5 and 7) is a self-contained set of process and product requirements developed for manufacturers who have not adopted the IEC 62443 framework. It defines Safety-Related Security Levels (SRSLs) from SRSL0 to SRSL3, with escalating requirements for authentication, authorisation, integrity verification, input validation, and physical tampering detection. This approach lets smaller manufacturers or those new to cybersecurity meet the requirements without first implementing the full IEC 62443 infrastructure.
Approach B (Clauses 6 and 8) is designed for manufacturers already working with IEC 62443. It maps machinery requirements directly to IEC 62443-3-3 (system security), IEC 62443-4-1 (secure development lifecycle), and IEC 62443-4-2 (component security). The standard specifies exactly which security requirements from IEC 62443 must be met, at which security levels, for which foundational requirements. For example, machinery systems under Approach B must comply with IEC 62443-3-3 at SL-C2 for identification and authentication control, use control, system integrity, and resource availability.
Both approaches share common clauses covering risk assessment (per EN ISO 12100), general protection against corruption principles, and information for use requirements.
The SRSL concept
For Approach A, the standard introduces Safety-Related Security Levels (SRSLs) as the mechanism for determining how much protection a given safety function needs. The SRSL is determined through a threat assessment that considers three factors.
The Exposure Level (EL0 through EL4) reflects the attack surface of the interface under consideration. EL0 applies to completely isolated internal components. EL1 covers physical access points like USB ports or RJ45 connectors on the machine boundary. EL2 covers local OT network connections. EL3 extends to factory-level networks bridging OT and IT. EL4 applies to connections to untrusted networks, including the internet.
The Attacker Capability considers what level of skill and knowledge an attacker would need. The scale runs from minimal knowledge with basic skills (script kiddies) through moderate knowledge with specialist skills (trained technicians) to extensive knowledge with advanced capabilities (malicious insiders or highly trained hackers).
The Window of Opportunity accounts for how much time and access an attacker would realistically have, ranging from very restricted (rarely accessible, under constant surveillance) to unlimited (open, frequent access).
These factors combine to produce an attack potential score, which, together with the safety impact of the function being protected (expressed as a Performance Level per EN ISO 13849-1), determines the required SRSL.
Logging and traceability
The standard mandates that machines record evidence of interventions that affect safety-related control systems. An “intervention” is any legitimate or illegitimate action that changes safety-relevant software, data, or configuration. Log records must include the type of intervention, means for correlating events (timestamps or counters), and evidence of any log deletion. Logs must be retained for at least five years and protected against tampering.
This logging requirement is notable because it creates a forensic trail for safety-relevant modifications. If a machine is involved in an accident and foul play is suspected, the tracing log provides evidence of what was changed and when.
Information for use
Manufacturers must document the security context for the machine (what environment it is designed to operate in), provide identification of safety-relevant software versions and configurations, explain how to access this information, and specify what modifications are permitted or prohibited. This information becomes part of the machine’s instructions for use.
IEC 62443 for machine builders
IEC 62443 is the international standard series for industrial automation and control system (IACS) cybersecurity. It was not designed for machine builders specifically, but it remains the most comprehensive and mature cybersecurity framework available for industrial applications. prEN 50742 references it extensively, and practical experience with IEC 62443 will be essential for meeting the Regulation’s requirements.
The role-mapping challenge
IEC 62443 defines three primary roles: product suppliers (who make components), system integrators (who assemble systems from components), and asset owners (who operate systems). Machine builders fit awkwardly into this scheme.
A series machine manufacturer designs and builds complete systems, then places them on the market as products. They act like product suppliers in terms of development processes (IEC 62443-4-1 applies) and their machines contain components that should meet IEC 62443-4-2. But they also integrate those components into a system, which makes IEC 62443-3-3 relevant.
Custom machine and plant builders sit closer to the system integrator role, selecting and assembling components from various suppliers into a bespoke installation. For them, IEC 62443-3-2 (security risk assessment for system design) and IEC 62443-3-3 (system security requirements) are particularly relevant.
Which parts matter most
IEC 62443-4-1 defines the secure product development lifecycle. It covers security management, specification of security requirements, secure design, secure implementation, security verification and validation, defect management, patch management, and end-of-life considerations. For any machine builder placing products on the EU market, adopting a development process aligned with IEC 62443-4-1 is arguably the highest-impact single step. It satisfies requirements under both the Machinery Regulation and the Cyber Resilience Act, and prEN 50742 Approach B requires it directly.
IEC 62443-4-2 specifies technical security requirements for IACS components, organised around seven foundational requirements: identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Machine builders should be asking their component suppliers (PLC vendors, drive manufacturers, HMI providers) whether their products are certified to IEC 62443-4-2, and at which security level.
IEC 62443-3-3 covers system-level security requirements using the same foundational requirement structure. This is where the overall machine architecture gets assessed, not just individual components.
IEC 62443-3-2 provides the methodology for conducting a security risk assessment at system level. It defines zones and conduits, identifies threats, and determines target security levels. This maps well to the threat assessment process required by prEN 50742.
Practical advice
Do not try to implement all of IEC 62443 at once. Start with IEC 62443-4-1 for your development process and IEC 62443-3-2 for threat assessment methodology. Use these to determine where your machines actually need protection, then apply the relevant component (4-2) and system (3-3) requirements where the risk assessment says they matter. The SRSL concept in prEN 50742 Approach A was created precisely because full IEC 62443 implementation can be overwhelming for machine builders who are just starting their cybersecurity journey.
The dual compliance problem with the Cyber Resilience Act
Here is where things get complicated. Machinery with digital elements must comply with both the Machinery Regulation and the Cyber Resilience Act (EU) 2024/2847. Recital 53 of the CRA makes this explicit. Neither regulation supersedes the other. Neither provides an exemption from the other.
Different scope, overlapping territory
The Machinery Regulation focuses on safety. Its cybersecurity requirements (EHSRs 1.1.9 and 1.2.1) are specifically about protecting safety functions against corruption that could lead to hazardous situations.
The CRA takes a broader view. It applies to all products with digital elements placed on the EU market and covers the full lifecycle of cybersecurity: secure design, vulnerability management, security updates, software bills of materials (SBOMs), and incident reporting. The CRA does not care whether a cyber vulnerability creates a safety hazard. If it is a vulnerability in a product with digital elements, it is in scope.
For machine builders, this means the Regulation’s cybersecurity requirements are a subset of what the CRA demands. Meeting the CRA does not automatically satisfy the Regulation (because the Regulation’s safety-focused analysis is different), and meeting the Regulation’s cybersecurity requirements does not satisfy the CRA (because the CRA requires far more than safety-function protection).
The gap period
The timelines do not align neatly. CRA vulnerability reporting obligations begin on 11 September 2026. The Machinery Regulation applies from 20 January 2027. Full CRA obligations apply from 11 December 2027. This creates a period from January to December 2027 where machines must comply with MR cybersecurity requirements but not yet the full CRA. In practice, preparing for both simultaneously is the only sensible approach.
What the CRA adds
Beyond the Machinery Regulation’s safety-focused cybersecurity, the CRA introduces several obligations that machine builders will find unfamiliar.
Software Bills of Materials. Manufacturers must create and maintain an SBOM for each product with digital elements. For a complex machine containing dozens of PLCs, drives, HMIs, sensors with embedded software, and custom application code, this is a substantial documentation effort.
Vulnerability management. Manufacturers must actively identify and remediate vulnerabilities throughout the product’s expected lifetime. This includes monitoring external vulnerability databases, coordinating disclosure, and providing timely patches.
Incident reporting. Actively exploited vulnerabilities must be reported to ENISA within 24 hours of discovery, with a full report within 72 hours. This obligation begins in September 2026, well before the full CRA applies.
Secure updates. Manufacturers must ensure security updates can be delivered to their products throughout the support period, and that these updates are separated from functionality updates so users can apply security fixes without risking operational changes.
The multiplication problem
Industry associations, notably CEMA (the European agricultural machinery association), have raised concerns about the compliance burden for complex machines. A modern combine harvester or CNC machining centre may contain over 100 individual products with digital elements, each of which technically requires its own SBOM, vulnerability management process, and update mechanism under the CRA. When you consider that a machine builder typically purchases these components from third-party suppliers, the coordination effort is immense.
The practical solution is an integrated compliance approach. Use IEC 62443-4-1 as the backbone of your development process (it satisfies requirements under both regulations), apply prEN 50742 for MR conformity, prepare for prEN 40000 series compliance for the CRA, and build a single vulnerability management process that covers all obligations. The EU Declaration of Conformity for a machine will eventually need to reference both the Machinery Regulation and the CRA, alongside any other applicable legislation.
Sector-specific developments
While prEN 50742 provides horizontal cybersecurity requirements for all machinery, some sectors are developing their own cybersecurity standards tailored to their specific operating environments and threat landscapes.
ISO/DIS 24882 for agricultural and earth-moving machinery
ISO/DIS 24882, “Agricultural machinery, tractors, and earth-moving machinery – Product cybersecurity,” was circulated as a Draft International Standard in late 2025. Developed by ISO/TC 23/SC 19 in collaboration with ISO/TC 127/SC 3, it represents the first Type C-level cybersecurity standard for a specific machinery sector.
The standard takes a risk-based approach, guiding manufacturers through system identification, asset identification, threat modelling, impact rating, likelihood assessment, and risk treatment. It then specifies technical cybersecurity requirements covering secure software updates, integrity and authenticity verification, hardening and secure configuration, logging and anomaly detection, access control, and secure communication.
What makes ISO/DIS 24882 particularly relevant is its sector context. Agricultural machinery operates in environments where connectivity is rapidly increasing (precision farming, fleet management, autonomous operation) while physical security is often minimal (machines left in open fields, accessible service ports, remote locations with limited monitoring). The standard addresses these realities directly.
For manufacturers in the agricultural and earth-moving sectors, ISO/DIS 24882 will likely become a key reference alongside prEN 50742. It provides sector-specific interpretation of the general cybersecurity principles, just as sector-specific Type C safety standards interpret the general principles of EN ISO 12100.
Other sectors will likely follow. Packaging machinery, woodworking machinery, and metalworking machinery all have active standardisation committees, and cybersecurity is on their agendas. Machine builders in these sectors should monitor their relevant TC activities.
Timeline and practical action plan
Key dates
11 September 2026 marks when CRA vulnerability reporting obligations begin. If you discover an actively exploited vulnerability in any of your products with digital elements after this date, you must report it to ENISA within 24 hours.
20 January 2027 is the hard application date for the Machinery Regulation. Every machine placed on the market from this date must comply with all requirements, including EHSRs 1.1.9 and 1.2.1 on cybersecurity.
15 May 2027 is when the old EN ISO 13849-1:2015 is withdrawn and the 2023 edition takes over exclusively. While not directly a cybersecurity deadline, it affects safety control system design and interacts with the cybersecurity requirements.
11 December 2027 is the full CRA application date. All products with digital elements must meet the complete set of CRA requirements, including SBOM, vulnerability management, secure updates, and full lifecycle cybersecurity.
Six concrete steps to take now
1. Map your machinery portfolio for digital elements. Walk through every product you place on the market. Which ones contain software? Which have network interfaces, USB ports, wireless connectivity, or remote access capabilities? Which use safety-related embedded software or safety-related application software? This inventory is the foundation for everything that follows.
2. Identify your safety-relevant digital assets. For each machine, determine which software, data, and hardware components are safety-relevant. This maps directly to EHSR 1.1.9’s requirement to “identify as such” safety-relevant elements. Document which safety functions depend on which digital components, and what interfaces those components expose.
3. Adopt a secure development lifecycle. Implement a development process aligned with IEC 62443-4-1. This does not require certification on day one, but it does require documented processes for threat modelling, secure coding, security testing, vulnerability management, and patch delivery. This single step addresses requirements under both the Machinery Regulation and the CRA.
4. Establish vulnerability management. Build a process for monitoring vulnerability databases, receiving vulnerability reports from external researchers, assessing impact, developing patches, and communicating with customers. The CRA reporting obligations begin in September 2026. You need this process running before then.
5. Start building SBOMs. Begin documenting the software components in your machines, including third-party libraries, open-source components, and supplier-provided firmware. Engage your component suppliers about their own SBOMs. This is a CRA requirement that takes time to implement properly, especially for machines with complex software supply chains.
6. Monitor standards development. Track the progress of prEN 50742 (your primary route to Machinery Regulation cybersecurity conformity), the prEN 40000 series (your route to CRA conformity), and any sector-specific standards relevant to your machines. Participate in standards committees if you can. Being part of the discussion is far better than being surprised by the outcome.
What this means for different roles
Machine manufacturers (series production)
You carry the primary burden. As the entity placing the machine on the market, you are responsible for compliance with both the Machinery Regulation and the CRA. You need to integrate cybersecurity into your existing safety engineering process, adopt a secure development lifecycle, and prepare for new documentation obligations (SBOMs, vulnerability handling, security context documentation). In the IEC 62443 framework, you function primarily as a product supplier, despite delivering complete systems.
Custom machine and plant builders
Your situation is similar but complicated by the bespoke nature of your work. Each machine may have a unique combination of components and interfaces, making standardised cybersecurity measures harder to apply. You sit closer to the system integrator role in IEC 62443 terms. Pay particular attention to IEC 62443-3-2 for security risk assessment and IEC 62443-3-3 for system-level security. The security context documentation for each machine will need to reflect its specific deployment environment.
Component suppliers
If you make PLCs, drives, HMIs, safety controllers, sensors with embedded software, or any other component with digital elements, you are directly subject to the CRA. Your customers (machine builders) will increasingly demand IEC 62443-4-2 certification, SBOMs for your products, and commitment to vulnerability management and security updates. Getting ahead of these demands is a competitive advantage. Those who can already supply IEC 62443-4-2 certified components with comprehensive SBOMs will be preferred suppliers as the deadlines approach.
System integrators
If you modify or substantially upgrade existing machines, the Regulation’s substantial modification provisions may make you the manufacturer. That means full compliance obligations, including cybersecurity. Even if your modifications do not trigger manufacturer status, you should understand the cybersecurity requirements so you do not inadvertently compromise the safety integrity of the machines you work on. Adding a remote access interface to a machine, for instance, changes its exposure level and may require additional protective measures.
Safety engineers and consultants
Your role is expanding. Risk assessment per EN ISO 12100 now needs to consider cybersecurity threats alongside traditional mechanical, electrical, and functional safety hazards. The threat assessment process in prEN 50742 becomes part of your toolkit. You do not need to become a penetration tester, but you do need to understand exposure levels, attack potential, and how cybersecurity measures interact with functional safety. Learning the basics of IEC 62443 is no longer optional if you advise machine builders on regulatory compliance.
Where safety and security converge
The EU Machinery Regulation represents a genuine turning point. For the first time, a major piece of European product safety legislation explicitly recognises that you cannot guarantee machinery safety without considering cybersecurity. The logic is simple and hard to argue with. If a safety function runs on software, and that software can be corrupted through a network interface, then protecting that interface is a safety measure, not just an IT measure.
The standards landscape is still forming. prEN 50742 is in draft. The prEN 40000 series is under development. Sector-specific standards like ISO/DIS 24882 are working through their approval processes. Manufacturers who wait for everything to be finalised before they act will find themselves scrambling in late 2026.
The manufacturers who start now, mapping their digital assets, adopting secure development practices, building vulnerability management processes, and engaging with the standards development, will arrive at 20 January 2027 with confidence rather than panic. They will also find that customers, insurers, and market surveillance authorities increasingly reward proactive cybersecurity maturity.
Cybersecurity and functional safety are no longer separate disciplines for machinery. The regulation has made that official. The question is no longer whether to act, but how fast you can move.
