From 20 January 2027, Regulation (EU) 2023/1230 requires machinery and related products to address software, data, connections, and malicious influence where they can create hazardous situations or affect Annex III compliance.
Map each relevant asset and connection to a machinery-safety consequence, then retain the version, intervention, control-system, and validation evidence required for that safety case.
Structured answer sets in this page tree.
Cited legal and guidance references.
Regulation (EU) 2023/1230 applies from 20 January 2027. Its cyber-safety rules focus on machinery hazards: connections must not create hazardous situations, compliance-critical software and data must resist accidental or intentional corruption, and must withstand reasonably foreseeable malicious attempts where the circumstances and risks make that appropriate. Products placed on the EU market before 20 January 2027 must comply with Machinery Directive 2006/42/EC, while other applicable cybersecurity legislation must be assessed separately.
Classify software and connectivity by their machinery-safety role. Review a maintenance portal, firmware update path, sensor-data pipeline, machine-learning safety component, or remote-control channel when corruption, loss of integrity, or malicious influence could create a hazardous situation or undermine compliance with an applicable Annex III requirement.
The Regulation defines source code as the currently installed software version written in a programming language that is unambiguous and understandable to humans. Annex IV requires source code or programming logic for safety-related software when needed to demonstrate conformity. Article 10 requires a manufacturer to provide relevant source code or programming logic to a competent national authority only after a reasoned request and only when the authority needs it to check Annex III compliance. The rule does not make source code public.
Annex III section 1.1.9 first requires the machinery or related product to be designed and constructed so that connecting another device, directly or remotely, does not create a hazardous situation. It then requires adequate protection against accidental or intentional corruption for hardware that transmits signals or data relevant to access to compliance-critical software, and for software and data that are critical to applicable EHSRs.
The product must identify the software installed on it that is necessary for safe operation and make that information easily accessible at all times. It must also collect evidence of legitimate or illegitimate intervention in relevant hardware and of intervention in, or modification of, installed software or its configuration. Tie the evidence record to the protected asset, access route, safety consequence, protection measure, and recorded intervention.
Annex III section 1.2.1 requires to be designed and constructed so that they prevent hazardous situations and withstand relevant operating stresses and external influences, including reasonably foreseeable malicious attempts from third parties where appropriate to the risks.
Section 1.2.1 sets two distinct retention rules. A tracing log of intervention data and safety-software versions uploaded after market placement or putting into service must be enabled for five years after each upload, exclusively to demonstrate Annex III conformity after a reasoned authority request. For fully or partially self-evolving operating with varying autonomy, recording of data on the safety-related decision-making process must be enabled and the data retained for one year after collection for the same limited purpose.
Annex IV requires technical documentation to specify the means used to ensure conformity with applicable essential health and safety requirements. For software-heavy machinery, connect the released configuration, hazards, controls, and verification evidence; a repository, ticket queue, or security policy alone does not show conformity.
Keep the evidence version-specific. A reviewer should be able to connect a released machinery configuration to the safety-related software version, programming logic, protected data, control-system design, tests, residual risks, and update history.
Map safety-related software, control-system assumptions, corruption-protection measures, update triggers, and Annex IV evidence before release or technical-file review.
Answer safety-related software, control-system, and corruption-protection questions with cited outputs.
Check whether software, data, updates, and control-system records support the Annex III safety case.
Reopen the software and cybersecurity assessment whenever a change could affect a safety function or the evidence behind it. Typical triggers include firmware releases, supplier component changes, remote-access changes, new sensor inputs, model retraining, changed operating envelopes, vulnerability remediation, incident reports, or a revised harmonised standard used in the conformity argument.
ISO/TR 22100-4:2018 gives machinery manufacturers guidance for identifying and addressing IT-security threats that can influence machinery safety, but it does not provide detailed implementation specifications. It does not replace the Regulation or establish a presumption of conformity on its own. Map each chosen measure to the relevant Annex III requirement and retain the supporting Annex IV evidence.
Regulation (EU) 2026/1744 was published on 24 July 2026 and entered into force on 27 July 2026. It moves the Machinery Regulation into Section B of AI Act Annex I and requires the Commission to add corresponding health and safety requirements to Machinery Regulation Annex III through delegated acts that apply by 2 August 2028 for AI systems classified as high-risk under Article 6(1) because they are safety components of machinery or are themselves machinery.
"applies on a mandatory basis as of 20 January 2027"
"documentation and verification of the risk assessment"
"does not provide detailed specifications"
"foreseeable at the time of placing"