EU Machinery Regulation 2027: What Robot Builders Need to Know

Machinery placed on the EU market from 20 January 2027 falls under Regulation (EU) 2023/1230, not Directive 2006/42/EC. The old Directive is repealed on that date. There is no transition period for new placements. Any robot arm, AMR, AGV, or cobot cell you first place on the EU market after 19 January 2027 must carry a CE mark issued under the Regulation. This guide maps the legal text onto engineering work: safety functions, firmware, ROS 2 stacks, learned controllers, documentation, and conformity routes.

Quick Takeaways

• Hard date: Directive 2006/42/EC applies through 19 Jan 2027. The Regulation applies from 20 Jan 2027, directly in all member states.
• Software is regulated hardware: Software that performs a safety function is a safety component. Learned controllers that perform safety functions can trigger third-party assessment.
• Cybersecurity is a safety requirement: The Regulation requires protection against corruption of safety-relevant hardware and software.
• Paperwork goes digital: Instructions and the declaration of conformity can be supplied digitally. Technical documentation requirements are stricter.

What Changed: Directive vs. Regulation

Two practical points follow. First, because the instrument is a Regulation, there is no national transposition to track. Second, non-EU manufacturers carry the same obligations, and importers and distributors have defined duties.

Who Is the “Manufacturer” of a Robot Cell?

The Regulation keeps the Directive’s split between machinery, partly completed machinery, and safety components. A bare 6-axis arm sold without a gripper or guarding is typically partly completed machinery. It ships with a Declaration of Incorporation and assembly instructions. The integrator who builds the full cell becomes the manufacturer of the finished machinery and signs the Declaration of Conformity.

The Regulation also defines substantial modification. If you change a machine’s physical or digital structure in a way not foreseen by the original manufacturer, and the change creates a new hazard or raises the risk, you are treated as the new manufacturer. For robot builders, that includes:

• Replacing a safety PLC program or safety-rated controller firmware.
• Adding a mobile base to a stationary arm.
• Retraining or swapping a perception model that feeds a speed-and-separation function.

Software as a Safety Component

Any software that performs a safety function is a safety component. Typical examples in robotics:

A general-purpose ROS 2 node is not a safety function. Keep it that way architecturally. The nav2 stack, a MoveIt 2 planner, or an ros2_control hardware interface should sit outside the safety path. The safety layer must be able to stop the machine regardless of what those nodes do.

Cybersecurity and Protection Against Corruption

The Regulation requires that connected machinery resist corruption, whether accidental or malicious, that could lead to a hazardous situation. This applies to safety-relevant hardware and software. Evidence is expected in your technical file: a threat model, access control, and integrity measures.

Harmonised standards for this requirement are still in development. Practitioners commonly reference the IEC 62443 series for industrial automation and control systems security, and a dedicated machinery standard (prEN 50742) is in progress. Treat the standards landscape as moving and verify the current Official Journal listings before freezing your design.

A minimal engineering baseline:

Enabling SROS 2 on a ROS 2 Robot

# Create a keystore (run once per robot fleet or per machine)
ros2 security create_keystore ~/sros2_keystore

# Create enclave credentials for the navigation node
ros2 security create_enclave ~/sros2_keystore /robot/nav2_controller

# Enable security at runtime
export ROS_SECURITY_KEYSTORE=~/sros2_keystore
export ROS_SECURITY_ENABLE=true
# "Enforce" rejects unauthenticated participants instead of just logging them
export ROS_SECURITY_STRATEGY=Enforce

# Launch the node inside its enclave
ros2 run nav2_controller controller_server \
  --ros-args --enclave /robot/nav2_controller

SROS 2 secures the DDS layer. It does not make a node safety-rated, and it does not replace a threat analysis. Use it as one control among several.

AI, Machine Learning, and Self-Evolving Behavior

This is the section that matters most to teams shipping learned perception or policy networks.

The Regulation addresses machinery and safety components with fully or partially self-evolving behavior using machine learning to perform safety functions. Machinery embedding such systems, and the safety components themselves, appear on the Annex I Part A list. The practical consequence is a mandatory third-party conformity assessment by a notified body rather than internal production control alone. The Regulation also requires that safety-relevant learned behavior stays within defined boundaries, and that data be recorded to demonstrate this.

An engineering pattern that fits both the text and sound safety practice:

[ Learned planner / policy ]  --->  [ Deterministic safety envelope ]  --->  [ Actuators ]
   (non-safety-rated)                (certified, bounded, verified)

Constrain the learned component with a deterministic monitor. A simple example is a velocity and force envelope:

v_cmd_safe = clip(v_cmd, -v_max(d), +v_max(d))

v_max(d) = sqrt(2 * a_brake * max(d - d_margin, 0))

where:
  d        = measured protective separation distance (m)
  a_brake  = guaranteed braking deceleration (m/s^2)
  d_margin = sensor error + latency stopping allowance (m)

The envelope is what you certify. The learned policy stays outside the safety function. Whether your design still falls under the Annex I self-evolving category depends on exactly where safety functions live, so confirm the classification with a notified body early.

AI Act Interplay

The EU AI Act applies separately where an AI system is a safety component of a product covered by Union harmonisation legislation. Machinery Regulation conformity assessment can cover the AI-specific safety aspects, but you must still confirm which AI Act obligations apply and when. The AI Act timeline for product-embedded high-risk systems has been under active discussion, so check current status rather than relying on older dates.

Human-Robot Collaboration: Ergonomics and Psychological Stress

The updated essential requirements add attention to human-machine interaction. Robots that work closely with people must be designed so that the interaction does not cause unacceptable psychological stress. Practical design inputs include:

• Predictable, legible motion with consistent speeds near operators.
• Clear status signaling (light bars, audible cues) before a motion begins.
• Defined behavior in degraded states, such as safe stop versus protective stop.

Risk assessment must cover these interaction effects alongside the classic crushing and impact hazards.

Conformity Assessment Routes

Annex I Part A includes, among others, certain safety components with self-evolving behavior and machinery embedding such systems. Part B covers categories where a different route is available. Check the Annex text against your exact product.

Digital Documentation

The Regulation permits digital instructions and a digital Declaration of Conformity accessed via a link or machine-readable code. Constraints to respect:

• Instructions must still be available on paper on request for non-professional users, free of charge.
• The digital copy must remain accessible for the period required by the Regulation after the last unit is placed on the market.
• The Declaration of Conformity or a link to it must travel with the product.

A reasonable implementation is a QR code on the nameplate resolving to a versioned, access-controlled page per serial number.

Technical File Checklist for Robot Builders

Real-World Workflow: Preparing an AMR Platform for 20 January 2027

A realistic path for a team shipping a ROS 2 based AMR into the EU:

1. Classify. Decide whether the AMR is machinery, partly completed machinery, or a safety component. Identify whether any learned model performs a safety function.
2. Partition the architecture. Move all safety functions to a certified safety controller and safety scanner. Keep nav2 and perception outside the safety path.
3. Define the envelope. Specify field sets, speeds, and stopping distances per ISO 3691-4. Validate with measured braking data.
4. Secure the stack. Signed updates, SROS 2, a segmented safety network, and logged parameter changes.
5. Build the technical file against the checklist above, and set up a version-controlled change process so that updates do not silently become substantial modifications.
6. Engage a notified body early if Annex I Part A may apply. Lead times are the main schedule risk.
7. Check standards status. Harmonised standards under the Regulation are being published in stages, and the Commission has indicated that many existing standards will carry over. Confirm which references you can cite when you issue your declaration.

Which Standards to Anchor On

Harmonised standards are voluntary. They give a presumption of conformity, but you may use other technical solutions if you can demonstrate equivalent safety.

FAQ

When does the EU Machinery Regulation come into force?

The Regulation entered into force on 19 July 2023 and applies from 20 January 2027. Machinery placed on the market before that date is assessed under Directive 2006/42/EC. There is no general transition period for new placements.

Does the Machinery Regulation apply to robots?

Yes. Industrial robots, cobots, robot cells, and AMRs are machinery or partly completed machinery. Robots that perform safety functions through software or machine learning face additional requirements, and some fall under mandatory third-party assessment.

Do I need a notified body for my robot?

Only if your product falls under Annex I Part A, for example certain safety components or machinery with self-evolving ML behavior performing safety functions. Other machinery can usually use internal production control, but confirm your classification against the Annex text.

Does the Regulation require cybersecurity for robots?

Yes, for safety-relevant hardware and software. You must protect against corruption that could create a hazard and document the measures. IEC 62443 is a common reference, and dedicated harmonised standards are still being developed.