EU Machinery Regulation Cybersecurity Guide: Meeting the Protection Against Corruption Requirements

From January 2027, machinery sold in the EU must be designed so that a remote connection, a tampered update or a corrupted configuration cannot make it dangerous. Regulation (EU) 2023/1230 on machinery replaces the Machinery Directive 2006/42/EC and, for the first time, writes cyber-related safety requirements into the essential health and safety requirements that every machine must meet. This guide explains who is covered, what Annex III sections 1.1.9 and 1.2.1 actually require, where the Regulation stops and the Cyber Resilience Act starts, and how manufacturers, integrators and plant operators can build evidence of compliance. It is written for OT security leads, product security teams, safety engineers and compliance owners. Status line: checked against EUR-Lex, the European Commission machinery page and BAuA on 11 November 2026.

Source note: obligations and dates come from Regulation (EU) 2023/1230 on EUR-Lex and European Commission guidance unless another source is named. Status is as of November 2026. Confirm against the official text before relying on it.

Key takeaways

• The application date is 20 January 2027. The Official Journal text says 14 January 2027, but a corrigendum corrected the dates and both the Commission and the German federal safety institute BAuA now give 20 January 2027; machinery placed on the market before then follows the Machinery Directive.
• Section 1.1.9 is a safety requirement, not a general security mandate. It requires protection against accidental or intentional corruption only where corruption could lead to a hazardous situation or undermine compliance, which keeps the scope narrower than the Cyber Resilience Act.
• Evidence is mandatory, not optional. Machinery must collect evidence of legitimate or illegitimate intervention in critical hardware, safety software and configuration, and keep a tracing log of safety software versions uploaded after placing on the market for five years.
• Self-evolving AI gets stricter treatment. Safety components and machinery with fully or partially self-evolving behaviour using machine learning appear in Annex I Part A, which removes the option of self-certification (module A) for those categories.
• Remote access identities are part of the safety case. Maintenance accounts, update signing keys and the service identities that push configuration are exactly the routes Annex III asks manufacturers to control and log, so identity design belongs in the risk assessment.

Scope: who and what is covered

Article 2 states that the Regulation applies to machinery and a list of related products, such as safety components and removable mechanical transmission devices, and it also applies to partly completed machinery. Article 2(2) lists exclusions, for example safety components intended as spare parts to replace identical components supplied by the original manufacturer. The definitions in Article 3 matter for cyber work because they were extended to digital elements:

• Safety component: Article 3(3) defines a safety component as a physical or digital component, including software, of a product. A software module that implements a safety function, placed on the market separately, can therefore be a safety component in its own right.
• Substantial modification: Article 3(16) covers a modification of machinery or a related product, by physical or digital means, that the manufacturer did not foresee or plan and that affects safety. Recital 26 explains it is substantial when new significant protective measures are required.
• Who becomes a manufacturer: Under Article 18, a person who carries out a substantial modification is considered a manufacturer for the purposes of the Regulation, with the full set of obligations for the modified part. This catches integrators and operators who add remote connectivity, new control software or AI functions to machines already in service.

Instructions may be supplied in digital form. Article 10(7) requires that digital instructions stay accessible online during the expected lifetime of the product and for at least 10 years, and recital 40 confirms that users can still ask for a paper copy free of charge. Security information such as hardening settings, the list of safety-relevant software and update procedures belongs in those instructions.

Key obligations

The cyber-relevant requirements sit in Annex III, the essential health and safety requirements. Two sections do most of the work.

Section 1.1.9: protection against corruption

• Connections must not create hazards: machinery must be designed so that connecting another device to it, directly or through a remote device, does not lead to a hazardous situation.
• Critical hardware is protected and monitored: hardware components that transmit signals or data relevant to safety or compliance must be protected against corruption, and the machinery must collect evidence of a legitimate or illegitimate intervention in that hardware.
• Critical software and data are identified and protected: software and data critical for compliance must be identified and adequately protected against accidental or intentional corruption.
• Software identity is available on demand: the machinery must identify the software installed on it that is necessary for safe operation and be able to provide that information at all times in an easily accessible form.
• Interventions leave a trail: the machinery must collect evidence of a legitimate or illegitimate intervention in software or of a modification of the software installed on it or its configuration.

Section 1.2.1: safety and reliability of control systems

• Malicious attempts: control systems must be designed so that they can withstand, where appropriate to the circumstances and the risks, reasonably foreseeable malicious attempts from third parties leading to a hazardous situation.
• Tracing log: the tracing log of data generated by an intervention and of the versions of safety software uploaded after the machinery has been placed on the market must be enabled for five years after such upload, solely to demonstrate conformity on a reasoned request from a competent national authority.
• Self-evolving logic: control systems with fully or partially self-evolving behaviour or logic must not cause actions beyond their defined task and movement space, and it must always be possible to correct the machinery to maintain its inherent safety. Data on safety-related decision making must be recorded and kept for one year after collection, again only for conformity demonstration.

Recital 25 sets the boundary: manufacturers are required to adopt proportionate measures limited to the protection of the safety of the machinery. The Regulation does not ask for confidentiality controls on production data or protection of business systems. Those belong to the Cyber Resilience Act and NIS2.

Conformity assessment and presumption of conformity

Article 6 and Annex I split higher-risk categories into Part A (third-party assessment mandatory) and Part B (the specific procedures in Article 25(3)). Categories not in Annex I use internal production control (module A, Annex VI) under Article 25(4). Annex I Part A lists six categories, including safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions, and machinery with embedded systems with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions that have not been placed independently on the market. Article 20(9) adds a cyber-specific route: machinery and related products certified, or covered by a statement of conformity, under a cybersecurity certification scheme adopted under Regulation (EU) 2019/881 (the Cybersecurity Act) are presumed to conform with sections 1.1.9 and 1.2.1 in so far as the certificate covers those requirements.

Timeline and current status

As of 11 November 2026 there is no harmonised standard for section 1.1.9 cited in the Official Journal. prEN 50742 is a draft: its scope says it provides requirements and recommendations to prevent accidental and intentional corruption of machines, covering hardware that transmits signals or data and software and data that could affect safety, and it notes that cybersecurity topics overlap with but are not identical to its subject. The DGUV KANBrief article states the draft is intended to be as compatible as possible with ISO/IEC 15408, EN 17640 and IEC 62443. Drafts change, so do not design to clause numbers from it yet. The Commission page lists horizontal and vertical recommendation for use (RfU) sheets for the Regulation, status May 2026, which notified bodies use for consistent interpretation. Check for the Commission guide and any standards citation before your conformity file is frozen.

Relationship with the Cyber Resilience Act: Regulation (EU) 2024/2847 (the CRA) covers products with digital elements more broadly, including vulnerability handling, security updates and reporting of actively exploited vulnerabilities. A connected machine can fall under both. The Machinery Regulation answers "can corruption make this machine unsafe?", while the CRA answers "is this product secure across its support period?". See the EU Cyber Resilience Act Guide. AI-based safety functions may also bring the machine into the EU AI Act high-risk regime, see the EU AI Act High-Risk AI Systems Guide.

Enforcement and penalties

Enforcement is national. Article 50 requires Member States to lay down rules on penalties applicable to infringements by economic operators, which must be effective, proportionate and dissuasive and may include criminal penalties for serious infringements, and to notify those rules to the Commission. The Regulation sets no EU-wide fine level, so exposure depends on the country of placing on the market. Practical enforcement levers are those of EU market surveillance: authorities can request documentation, require corrective action, restrict or withdraw products from the market and order recalls. The five-year tracing log and the one-year decision log in section 1.2.1 exist precisely so that a competent national authority can ask for them on a reasoned request. Liability for damage is a separate track: the revised Product Liability Directive treats software as a product, see the EU Product Liability Directive 2024 Guide.

What it means for AI agents and non-human identities

Annex III never uses the word identity, but every requirement in section 1.1.9 depends on knowing which machine, person or service made a change. In practice the corruption routes are:

• Agents must stay inside the defined task space: section 1.2.1 requires that self-evolving control logic cannot act beyond its defined task and movement space. Where an AI agent can call tools that change machine settings, enforce limits in the safety-rated layer, not in the agent's prompt. See the AI in OT and Industrial Systems Guide.
• Signing keys are safety assets: a stolen update signing key defeats the integrity control the safety case relies on. Store it in an HSM, separate build and release identities, and see the Code Signing Security Guide.
• Device certificates need a lifecycle: machines live for decades, so plan certificate renewal and revocation for the whole service life. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Logs must attribute to an identity: evidence of a legitimate or illegitimate intervention is only useful if the log records which account or certificate performed it. Shared vendor logins make that impossible.

Compliance steps

1. Classify the portfolio (first quarter): list every machine and related product you will place on the market from 20 January 2027, mark which have communication interfaces, updatable software or machine learning, and check each against Annex I Parts A and B to choose the conformity route.
2. Extend the risk assessment: add corruption scenarios (remote connection, malicious update, configuration tampering, rogue device on the fieldbus) to the ISO 12100 style risk assessment. Use IEC 62443-3-2 zones and conduits to structure it; see the IEC 62443 Guide.
3. Identify safety-relevant software: build a list of software and data critical for compliance, with versions and hashes, and make it retrievable from the machine (HMI page, service interface or diagnostic command) as section 1.1.9 requires.
4. Design the evidence trail: implement an intervention log for hardware, software and configuration changes and a tracing log of post-market safety software versions retained for five years, protected against deletion by the same accounts that make changes.
5. Harden the interfaces: authenticate updates and connected devices, remove default and shared credentials, and apply product security practice such as IEC 62443-4-1 and 4-2. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
6. Test before release: include corruption scenarios in validation: unsigned update attempts, configuration rollback, connection of an unknown device and loss of network. The expected result is a safe state and a log entry, never a hazardous movement.
7. Write the instructions: document the safety-relevant software list, update procedure, required network segmentation and how operators retrieve logs. Keep digital instructions online for at least 10 years.
8. Plan for change after sale: define which updates are foreseen by the manufacturer and which would be substantial modifications under Article 18, and tell integrators. Roll back by keeping the previous signed image and a documented procedure to restore it without losing the tracing log.

Decision guidance

• Harmonised standard versus own technical solution: until a standard is cited, document your own solution against each 1.1.9 bullet. When prEN 50742 is published and cited, applying it gives presumption of conformity and can shorten notified body review.
• Cybersecurity certification versus Annex III argument: Article 20(9) presumption only helps if a scheme under the Cybersecurity Act covers the relevant requirements. Check the scheme scope before relying on it.
• Small manufacturers: focus on the narrow scope of recital 25: protect safety functions and record changes. Avoid building enterprise-grade logging the Regulation does not require. Larger manufacturers with fleets should reuse CRA vulnerability handling and update infrastructure so one process serves both regimes.
• Operators retrofitting connectivity: before adding remote access to existing machines, decide whether the change is substantial. If new significant protective measures are needed, you take on manufacturer obligations. See the OT Remote Access Guide.

Detection and measurement

• Coverage: percentage of products in scope with a documented corruption risk assessment.
• Software identity: percentage of products that can report safety-relevant software versions on demand.
• Log integrity: percentage of products whose intervention log cannot be cleared by the maintenance role.
• Update integrity: share of field updates verified by signature on the device, target 100 percent.
• Attributable access: number of shared or default remote maintenance accounts remaining, target zero.

Framework mapping

Common failure patterns

• Treating 1.1.9 as an IT security checklist: teams import an enterprise control catalogue and miss the actual test, which is whether corruption can produce a hazard.
• Logs the attacker can erase: intervention logs stored where the maintenance account has write access do not count as evidence of an illegitimate intervention.
• Shared vendor credentials: one support password across a fleet makes every intervention look legitimate and unattributable.
• Safety limits inside the AI model: relying on a model's training to respect movement limits instead of an independent safety-rated limit fails the self-evolving logic requirement.
• Ignoring substantial modification: integrators add cloud connectivity to installed machines without reassessing, and unknowingly become the manufacturer.

Practitioner checklist

• Confirm which products are placed on the market from 20 January 2027 and which conformity route each needs.
• Add corruption and malicious-access scenarios to every machine risk assessment.
• Publish a retrievable list of safety-relevant software with versions on each machine.
• Implement tamper-resistant intervention logging and a five-year tracing log of safety software versions.
• Require signed updates and authenticated device connections that fail to a safe state.
• Replace shared and default maintenance credentials with named, time-bound identities.
• Enforce AI and optimiser limits in an independent safety layer and keep decision data for one year where required.
• Track prEN 50742, the Commission guide and RfU sheets, and update the technical file when they change.
• Map overlap with the CRA so vulnerability handling and update processes serve both laws.

Standards and references

• EUR-Lex: Regulation (EU) 2023/1230 on machinery
• European Commission: Machinery
• BAuA: The new European Machinery Regulation
• Estonian Centre for Standardisation: prEN 50742 Safety of machinery, Protection against corruption
• DGUV KANBrief: Combating vulnerabilities with standards, new EU cybersecurity rules
• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)

Related NHI Mgmt Group resources: IEC 62443 Guide · EU Cyber Resilience Act Guide · AI in OT and Industrial Systems Guide · Non-Human Identity (NHI) Guide. This guide summarises Regulation (EU) 2023/1230 as of 11 November 2026 and is not legal advice.