New Machinery EHSRs for Autonomous Robots

New Machinery EHSRs change the evidence a hotel buyer should expect for an autonomous or connected service robot placed on the EU market from 20 January 2027. A technical file built around Directive 2006/42/EC may still discuss control-system faults, emergency stops and foreseeable misuse. That does not prove that the file covers protection against corruption, malicious interference, software traceability or the operating limits of autonomous mobile machinery under the current consolidated Regulation (EU) 2023/1230.

The decision is practical. Before accepting a 2027 machine, compare the old file against Annex III points 1.1.9, 1.2.1 and the mobility requirements that apply to the actual robot. Then trace each applicable requirement to design evidence, verification results and instructions. Do not accept a cybersecurity policy, a penetration-test summary or a CE logo as a substitute for that chain. This review concerns machinery safety. Other cybersecurity laws may apply at the same time.

Map the Machinery EHSRs against the old file

The European Commission says the Machinery Regulation applies on a mandatory basis from 20 January 2027. The date matters because a file created for a machine placed on the market under the Machinery Directive 2006/42/EC was prepared against a different legal text. The Directive already required control systems to prevent hazardous situations and stated that hardware faults, software faults and errors in control logic must not create hazards. The new Regulation retains that safety logic and adds requirements written for connected, software-dependent and autonomous machinery.

A reviewer should not label every old file defective. First record the exact model, configuration, software release, manufacturer and intended placing-on-the-market date. A machine lawfully placed on the market before the Regulation applies is not converted into a 2027 product merely because a hotel uses it later. A new unit, a new manufacturer release or a substantial modification can produce a different analysis. The legal route depends on the facts, so procurement should obtain advice where the timing or modification status is disputed.

The Machinery EHSRs comparison should use the current consolidated act rather than an early proposal or a slide deck. It should also stay narrow. Annex III cybersecurity provisions address corruption or malicious action where these can affect machinery safety. They are not a declaration that every confidentiality, billing or privacy issue becomes a machinery EHSR.

Map protection against corruption under point 1.1.9

Annex III point 1.1.9 requires a connected device communicating with the machinery not to lead to a hazardous situation. It also requires hardware components that affect compliance, and software and data that are critical for compliance, to be identified and adequately protected against accidental or intentional corruption. The machine must collect evidence of legitimate or illegitimate intervention in those components, software or data.

For a hotel delivery robot, the file should identify which digital assets can affect safe speed, braking, obstacle detection, lift-interface behaviour, docking and restart. That list is more useful than a generic network diagram. It should distinguish a safety-related parameter from an ordinary operational setting. A menu change may have no safety effect. A remote change to maximum speed, stopping distance, sensor masking or allowed route can be different.

Ask how the manufacturer prevents an unauthorised command from changing a safety function, how it authenticates service access, and what happens when communications are lost or corrupted. Then ask for the corresponding verification evidence. The Regulation does not prescribe one universal technical control. The evidence should fit the architecture and risk assessment. A certificate or statement under a relevant scheme adopted through the EU Cybersecurity Act can create a presumption of conformity for points 1.1.9 and 1.2.1 only to the extent that the scheme and certificate cover those requirements. The existence of a certificate is not enough without checking its scope.

Test control-system software against point 1.2.1

Point 1.2.1 requires control systems to prevent hazardous situations and to withstand intended operating stresses and external influences. The new wording expressly includes reasonably foreseeable malicious attempts by third parties that could lead to a hazardous situation. The familiar checks for hardware faults and logic errors remain. The review must now connect threat conditions to safety outcomes instead of treating cyber testing as a separate IT exercise.

The same point requires the limits of safety functions to be established as part of the manufacturer’s risk assessment. For machinery with fully or partially self-evolving behaviour, it requires the product not to perform actions beyond its defined task and movement space. It also requires tracing logs for interventions and versions of safety-related software after the machine is placed on the market or put into service. For self-evolving machinery, the technical record must support review of safety-related decisions and the data used for them under the periods stated in the Regulation.

Procurement should therefore freeze a software baseline at acceptance. Record firmware, control application, safety controller, model or perception package, maps and configuration values that can affect the assessed behaviour. The supplier should explain which updates were foreseen in the risk assessment, how versions are signed or otherwise controlled, how rollback works, and when an update requires renewed assessment. A promise of “automatic updates” answers none of those questions.

This is also where Annex I classification can re-enter the file. Fully or partially self-evolving systems that use machine-learning approaches to ensure safety functions can fall within the higher-risk categories in Annex I. The separate Ergasa analysis of notified-body routes explains that classification. The present review does not assume that every navigation algorithm or AI label triggers that route.

Define the autonomous travel and supervision envelope

The Regulation defines autonomous mobile machinery by reference to an autonomous mode in which essential safety functions are ensured in the travel and working area without permanent operator interaction. Annex III then addresses supervision, travel, steering, obstacle risks, charging movement and instructions. For a hotel, the assessed environment is part of the safety case. A robot proven on a flat test floor is not automatically proven for a lobby with children, luggage, reflective surfaces, lift thresholds and changing furniture.

Where relevant, the supervisory function must let the supervisor receive information and give limited orders. The Regulation confines remote actions to stopping, starting, or moving the machine to a safe position and safe state, with conditions on the supervisor’s view of the working area and on protective devices. The travel requirements call for an enclosed protected zone, obstacle-detection devices, or both where the risk assessment requires them. Steering failure must not compromise safety. Automatic travel to a charging station must also address collision and electrical hazards.

Point 3.6.3.3 requires instructions for autonomous mobile machinery to specify the characteristics of intended travel areas, working areas and danger zones. Put those characteristics into the purchase specification before testing. Include slopes, thresholds, floor transitions, minimum clearances, lift interfaces, wireless coverage assumptions, lighting or reflective conditions relevant to sensors, maximum traffic density, prohibited zones and the location of recovery controls. The manufacturer must decide which factors are safety-relevant; the hotel should not invent limits after delivery.

Rebuild the technical-file evidence chain

Annex IV calls for the risk assessment, drawings, calculations, test results, standards or other technical specifications, instructions and conformity documents needed to demonstrate compliance. For safety-related software, it also provides for source code or programming logic to be supplied after a reasoned request from a competent national authority when needed to check Annex III compliance. This is an authority-access requirement, not a promise that a hotel receives the source code with the robot.

The file should still show enough controlled evidence for the buyer to understand the assessed baseline. Annex IV also addresses the data, characteristics and process used to develop, test and validate software where these are needed for the safety assessment. For an adaptive perception or control function, a marketing accuracy score is weak evidence. The useful record connects hazards to requirements, data boundaries, tests, abnormal conditions, residual risk and instructions.

The EU’s technical-documentation guidance places responsibility on the manufacturer to identify applicable requirements and explain how the product satisfies them. The conformity-assessment guidance makes the manufacturer responsible for the assessment route. The CE-marking guidance is equally clear that there is no central EU body issuing permission to affix CE marking. A hotel or importer should check consistency, but it should not rewrite the manufacturer’s risk assessment and pretend that this cures missing design evidence.

New evidence question	Record to inspect	Weak answer
Which digital assets affect safety?	Asset and safety-function map tied to the risk assessment	Generic IT asset inventory
How is corruption detected and resisted?	Architecture, access controls, integrity checks and verification results	Cybersecurity policy without product tests
Can a malicious input create a hazard?	Threat-informed safety tests and fault-response evidence	Penetration score with no safety consequence analysis
Which software version was assessed?	Controlled baseline, release record and trace log	Unversioned application screenshots
Where may the robot travel?	Validated operating envelope and instructions	Brochure statement saying “all indoor areas”
What changed after an update?	Impact assessment, regression results and approval record	Supplier email saying the update is routine

Assign duties before accepting the machine

The manufacturer owns the product risk assessment, applicable EHSR mapping, conformity assessment, technical documentation, declaration and CE marking. An authorised representative performs only the tasks covered by its mandate. An importer must check specified conformity and documentation elements before placing a non-EU machine on the market. A distributor must act with due care and check required markings and documents. Those roles should not be collapsed into “the vendor”.

The hotel as buyer and operator needs the validated conditions of use, staff controls, route management, incident response and maintenance records. If the hotel or integrator makes a substantial modification, or places the machine on the market under its own name, manufacturer obligations may arise. The existing manufacturer-classification analysis covers that threshold in more detail.

Market-surveillance authorities can require information and take action against non-compliant products under the Machinery Regulation and the wider EU market-surveillance framework. Contract rights matter because the hotel may need the supplier to provide logs, evidence or corrective action quickly. They do not transfer the public-law duty away from the responsible economic operator.

Use a decision checklist and cost the gaps

1. Record the exact product, software baseline, intended use and expected placing-on-the-market date.
2. Map the old Directive file against every applicable Annex III requirement, including points 1.1.9 and 1.2.1.
3. Identify safety-related hardware, software, data, communications and configuration parameters.
4. Trace corruption and malicious-attempt scenarios to safety controls and test results.
5. Define the robot’s task, movement space, travel area, danger zones and supervision design.
6. Check software-version records, intervention logs, update control and regression evidence.
7. Reconcile the risk assessment, Annex IV file, instructions, declaration, model identifiers and CE marking.
8. Assign manufacturer, importer, distributor, integrator and hotel actions in the contract and acceptance plan.

Do not invent a single “2027 compliance cost”. Price the verified gaps as work packages. Typical lines are architecture remediation, software configuration control, safety testing, cybersecurity testing tied to hazards, instruction updates, technical-file reconstruction, conformity-route work and hotel integration testing. Some files will already contain useful evidence. Others will require design changes rather than more paperwork.

The Cyber Resilience Act may impose separate cybersecurity duties for products with digital elements. Its presence does not erase the Machinery Regulation’s safety requirements. Scope, timing and responsible parties need a product-specific review. Keep separate cost lines where the evidence and legal tests differ, then identify records that can support both regimes without counting the same task twice.

Uncertainty and legal boundary: The applicable EHSRs depend on the robot’s design, safety functions, software behaviour, intended environment and market date. Whether an update or integration is a substantial modification also depends on the facts. This article is procurement analysis, not legal advice, a conformity assessment or a product certification.

Frequently asked questions

Does every connected robot fail an old 2006/42 technical file review?

No. The old file may contain useful control-system, software and test evidence. Review it against the requirements that apply to the 2027 product and record each gap. Do not infer compliance or failure from the file’s date alone.

Is a penetration test enough for point 1.1.9?

No. The evidence must identify safety-critical assets and connect corruption or interference scenarios to hazardous outcomes, controls and verification. A penetration test can support that chain, but a generic score does not replace it.

Must the manufacturer give source code to the hotel?

Annex IV provides for source code or programming logic of safety-related software to be available after a reasoned request from a competent national authority when necessary for its check. That is different from an automatic buyer entitlement. Contractual access and escrow are separate questions.

Does a Cybersecurity Act certificate prove full machinery compliance?

No. A relevant certificate can create a presumption only for the covered parts of points 1.1.9 and 1.2.1. Check the scheme, product, version, scope and validity. The remaining EHSRs and conformity duties still require evidence.

What should a hotel freeze at acceptance?

Freeze the model and options, safety-related software versions, maps and configuration values, intended travel areas, interfaces, update policy and the matching technical documents. Retain the supplier’s evidence and the hotel’s acceptance results.