On this page · 11 sections
- What changes on 20 January 2027
- Software is now a safety component
- Protection against corruption: what sections 1.1.9 and 1.2.1 require
- Self-evolving behaviour: when machine learning makes a safety decision
- Digital instructions and declarations of conformity
- How the Machinery Regulation, the CRA and the AI Act fit together
- Worked example: an ML person-detection module for mobile robots
- Checklist for OEMs before 20 January 2027
- Checklist for software suppliers, including Indian exporters
- How eCorpIT can help
- References
Summary. Regulation (EU) 2023/1230 replaces the Machinery Directive on 20 January 2027, a date set by a 2023 corrigendum to the original 14 January. Machinery placed on the EU market before then stays under the Directive. Three changes reach engineering teams. Standalone software performing a safety function is now a safety component, and a modification can be digital. Annex III sections 1.1.9 and 1.2.1 make cybersecurity a safety requirement: safe connections, protected software and data, evidence of interventions and a five-year tracing log. Machine learning with self-evolving behaviour that ensures a safety function sits in Annex I Part A, so a notified body is mandatory. The Digital Omnibus on AI did not move the date. It shifted machinery to the AI Act's sectoral Section B, with AI requirements reaching Annex III through delegated acts that must apply by 2 August 2028. The harmonised standard EN 50742 has an estimated ratification date of 13 November 2026 and is not yet cited. Our verdict: plan for 20 January, not for a delay.
About this article. For machinery OEMs, industrial software suppliers and compliance leads. We checked this on 1 November 2026 against the Regulation as published on 29 June 2023, read with the corrigendum of 4 July 2023 and the amendments in Regulation (EU) 2026/1744, plus the Cyber Resilience Act, the AI Act, Commission and Council documents and CENELEC's project record. The Commission's guide and EN 50742 are still being finalised, so re-check before you sign a declaration of conformity. This is general information, not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What changes on 20 January 2027
The Commission's machinery page gives 20 January 2027 as the mandatory application date. Machinery placed on the EU market before it must comply with Directive 2006/42/EC, and manufacturers may also state conformity with the Regulation on its EU declaration of conformity. An older copy that says 14 January 2027 predates the corrigendum of 4 July 2023.
No postponement is in the law. Industry groups asked for the cyber provisions to wait for the Cyber Resilience Act date, and the Commission told its expert group in April 2026 that no delay was foreseen. The Digital Omnibus on AI amends Articles 8, 20 and 47 of the Regulation and leaves the date alone.
The Regulation applies directly across Member States and aligns machinery law with the New Legislative Framework, so importers and distributors now carry their own obligations under Articles 13 to 16.
The dates below come from these primary records.
| Date | What happens |
|---|---|
| June and July 2023 | Adopted 14 June, published 29 June, corrected 4 July, in force 19 July |
| 27 July 2026 | Digital Omnibus on AI, Regulation (EU) 2026/1744, in force |
| 11 September 2026 | Cyber Resilience Act reporting obligations apply |
| 13 November 2026 | Estimated ratification of EN 50742; availability estimated for 20 November |
| 23 November 2026 | Indicative Parliament vote on Omnibus IV |
| 19 January 2027 | Last day to place machinery on the market under the Directive |
| 20 January 2027 | Machinery Regulation applies |
| 11 December 2027 | Cyber Resilience Act main obligations apply |
| 2 August 2028 | Delegated acts adding AI requirements to Annex III must apply; AI Act high-risk rules for other regulated products apply |
Software is now a safety component
Article 3(3) makes software a safety component when it is independently placed on the market to fulfil a safety function, its failure endangers people, and the product does not need it to function or normal components could replace it. Annex II's indicative list now names software ensuring safety functions.
Your software can carry its own CE marking. A package sold on its own, such as safety-rated vision or speed monitoring, can meet that test. Its maker is then a manufacturer, with a declaration of conformity, technical documentation and instructions to supply.
Updates can create a new machine. A substantial modification is a change by physical or digital means, not foreseen or planned by the manufacturer, that creates a new hazard or increases an existing risk. It must also require added guards or protective devices that change the safety control system, or extra stability or strength measures. Whoever makes it becomes the manufacturer under Article 18 and must run the conformity assessment, unless they are a non-professional modifying a machine for their own use.
The practical fix is to foresee updates. If the risk assessment describes the update channel, the safety envelope and the pre-release checks, a routine update is planned rather than substantial. That is our reading, not a ruling: the guide chapter on substantial modification was still under discussion on 22 October 2026.
Protection against corruption: what sections 1.1.9 and 1.2.1 require
Section 1.1.9 has five paragraphs, summarised below with points (a) and (f) of section 1.2.1. Point (a) applies where appropriate to the circumstances and risks. The point (f) log exists solely to show conformity on a reasoned request from a national authority. The right-hand column is our engineering reading, not legal text. Keep the design documents and test results for each row in the technical file.
| Requirement in plain terms | What to build |
|---|---|
| 1.1.9 para 1: connecting another device, directly or through a remote device, does not create a hazardous situation | Inventory and threat-model remote access, cloud links, USB, debug ports and wireless |
| 1.1.9 para 2: hardware carrying signals or data relevant to safety-critical software is protected against accidental or intentional corruption, and the machine collects evidence of interventions in it | Secure gateways, data diodes, sealed housings, intrusion detection |
| 1.1.9 para 3: software and data critical for compliance are identified and protected against accidental or intentional corruption | Signed firmware, message authentication codes, parameter integrity checks, access control |
| 1.1.9 para 4: the machine identifies the software it needs to operate safely and can report it at all times in an easily accessible form | Version and hash readout on the HMI or as an exportable file |
| 1.1.9 para 5: the machine collects evidence of interventions in its software and of changes to software or configuration | Tamper-evident change log with timestamps and change type |
| 1.2.1(a): control systems withstand reasonably foreseeable malicious attempts by third parties that lead to a hazardous situation | Defence in depth around safety controllers, safe-state fallback, attack testing |
| 1.2.1(f): tracing log of intervention data and uploaded safety software versions, enabled for five years after each upload | Durable, write-protected log storage with a retention test |
What the draft guidance says
IBF Solutions hosts draft chapters of the Commission's guide, dated 18 October 2026. The chapter on these sections is headed final version but watermarked draft. An Editorial Group report for the 22 October expert group meeting shows it still needing endorsement, and the Commission has said the guide is non-binding. Points useful now:
- The machine need not keep running when corruption is detected; a safe state, such as stopped, is acceptable.
- Section 1.1.9 covers safety, not data confidentiality or intellectual property.
- Needed remote access should ship in a secure state, for example deactivated.
- Checksums protect only against accidental corruption. Listed examples beyond that include signature verification on updates and cryptographic message authentication, with penetration testing to validate measures where public networks are reachable.
- Where a safety protocol already safeguards the data (black channel communication), logging interventions in intermediate hardware is not required.
- If evidence is recorded on an external device, the machine may operate only while that recording works, which matters for cloud logging designs.
Article 20(9) also presumes conformity where a referenced Cybersecurity Act certificate or statement covers these sections.
The standard to watch
CENELEC lists EN 50742:2026 at the approval stage, with the estimated dates in the table above and citation expected under the Regulation. CEN-CENELEC said in April that efforts were under way to speed citation before January 2027, but the Commission's standards page says the first implementing decision under the Regulation is still being prepared. A presumption of conformity starts only once the reference is in the Official Journal.
IBF's description of the draft sets a Safety-Related Security Level from SRSL0 to SRSL3 for each safety function, based on exposure, attacker capability and available time, with the IEC 62443 series as an alternative route. Check the published text.
Citation matters. Draft minutes of the April meeting record that cyber-safety requirements may need notified body assessment where harmonised standards are not fully applied, including for Annex I Part B machinery. Existing EC type-examination certificates stay valid until expiry, but the product must still meet the new requirements, possibly through a supplementary certificate. Machinery outside Annex I stays on Module A and can use other specifications, explained in the technical file.
Self-evolving behaviour: when machine learning makes a safety decision
Annex I Part A lists safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions, and machinery with such embedded systems not placed independently on the market, in respect only of those systems.
Article 25 sets the routes.
| Product category | Conformity routes |
|---|---|
| Annex I Part A | Module B (EU type-examination) plus Module C, or Module H (full quality assurance), or Module G (unit verification); notified body mandatory |
| Annex I Part B | Module A only if harmonised standards or common specifications fully cover the requirements; otherwise B plus C, H or G |
| Not in Annex I | Module A, internal production control |
Annex III sets requirements for machinery with self-evolving behaviour:
- The human-machine interface must suit the operators, and where relevant the machine must communicate its planned actions understandably.
- The control system must not cause actions beyond the defined task and movement space.
- Data on safety-related decision-making must be recorded and kept for one year after collection, solely for a reasoned request from a national authority.
- It must be possible at all times to correct the machine to keep it safe.
- The risk assessment must cover foreseeable hazards from the intended evolution, and hazardous settings changes during a learning phase must be prevented.
Settle two questions early with your notified body, and get the answers in writing.
Is the model self-evolving? The Regulation has no definition. Recital 55 excludes software incapable of learning or evolving that only executes certain automated functions. A model trained once and frozen is the grey area. Guidance will not settle it soon: one Editorial Group member rejected the draft chapter, with a solution still needed on 22 October.
Does Part B catch it anyway? Leaving Part A does not mean Module A. Part B lists protective devices designed to detect the presence of persons, and logic units ensuring safety functions. There, Module A depends on a fully applied harmonised standard or common specification.
What the Digital Omnibus on AI changed
Regulation (EU) 2026/1744 moves machinery from Section A to Section B of Annex I of the AI Act. For Section B products only a few AI Act articles apply, listed in Article 2(2), so manufacturers should not face a separate AI Act conformity assessment.
Article 8 of the Machinery Regulation now requires delegated acts adding to Annex III requirements for AI systems classed as high-risk under Article 6(1) of the AI Act. They must apply by 2 August 2028. Until machinery-specific standards exist, new Article 20(10) lets AI Act harmonised standards or common specifications give a presumption of conformity. The Commission announced the first on 19 October 2026: EN 18286:2026, on quality management systems.
The Part A listing and self-evolving requirements still apply from 20 January 2027. Our Digital Omnibus dates explainer covers the wider AI Act changes.
Digital instructions and declarations of conformity
Article 10(7) allows digital instructions on these conditions:
- The machine, or failing that the packaging or accompanying documents, says how to access them.
- Users can print, download and save them, including instructions embedded in software.
- They stay online for the expected lifetime and at least 10 years after placing on the market.
- A user who asks for paper at the time of purchase gets it free within one month.
- Where non-professional users are intended or foreseeable, essential safety information stays on paper.
Under Article 10(8), the declaration of conformity can be an internet address or machine-readable code in the instructions, online for at least 10 years. For a software team, that means a versioned documentation portal, a 10-year hosting commitment and a paper fulfilment process. If the portal sits in the cloud, note a nearby date: Data Act switching charges end on 12 January 2027.
One change is pending. The Omnibus IV compromise would require the declaration in digital format, reached directly through the address or code without login or personal data, with machinery changes applying 30 months after entry into force. Parliament's first-reading vote is indicatively set for 23 November 2026, so this is not yet law.
How the Machinery Regulation, the CRA and the AI Act fit together
Connected machinery often falls under more than one law. Recital 53 of the Cyber Resilience Act says manufacturers of machinery that is also a product with digital elements should comply with both sets of requirements. Meeting the CRA could help with sections 1.1.9 and 1.2.1, but the manufacturer has to demonstrate that and follow each law's conformity procedure. CRA reporting already applies, as our reporting guide explains. Table dates come from the Commission's CRA page and the Omnibus.
| Question | Machinery Regulation (EU) 2023/1230 | Cyber Resilience Act (EU) 2024/2847 | AI Act (EU) 2024/1689, as amended |
|---|---|---|---|
| Key dates | 20 January 2027 | Reporting from 11 September 2026; main obligations from 11 December 2027 | AI in regulated products from 2 August 2028; Annex III uses from 2 December 2027 |
| AI angle | Self-evolving safety functions in Annex I Part A | Not AI-specific | For machinery, requirements move into the Machinery Regulation by delegated act |
| Conformity | Module A, or notified body for Annex I | Self-assessment for most products; notified body for some | Through the Machinery Regulation route for machinery |
One security programme can feed all three technical files: one threat model, one signed-update pipeline, one logging design and one vulnerability process.
Worked example: an ML person-detection module for mobile robots
Take a hypothetical industrial software firm in Pune whose camera-based module stops an autonomous mobile robot when someone enters its path, sold to a German robot maker.
Route 1: sold as a standalone safety component. The supplier is the manufacturer. A self-evolving model falls in Part A and needs a notified body, plus the supplier's own declaration of conformity, CE marking and technical documentation. Whoever imports it into the EU, possibly the robot maker itself, takes on the Article 13 importer checks. Recital 54 helps the buyer: embedding an already third-party assessed component should not by itself force re-certification.
Route 2: delivered for integration. The robot maker is the manufacturer of the whole machine, and Part A applies to the machine in respect of that embedded system. The supplier's obligations become contractual, but the robot maker cannot finish its file without the supplier's evidence.
A frozen model needs the Part B check on either route, since protective devices that detect people are named there. Either way, expect requests for evidence against each row of the corruption table above, plus defined task and movement limits, one year of decision data, a statement on whether the model learns in the field, and a CRA vulnerability contact.
Checklist for OEMs before 20 January 2027
- List products shipping after 19 January 2027 and switch their declarations of conformity to the Regulation.
- Classify each against Annex I; flag every machine learning safety function and person-detection device.
- Book notified body capacity now for Part A products and for Part B products that may not reach a fully applied standard. The Commission points to NANDO for listed bodies.
- Check existing EC type-examination certificates against the new requirements.
- Extend risk assessments to interfaces, remote access, foreseen updates and any learning phase.
- Add integrity protection, signed updates and a software identification readout.
- Keep tamper-evident logs, with the tracing log enabled for 5 years after each safety software upload.
- Set up 10-year digital instruction hosting and a one-month paper process.
- Run CRA vulnerability reporting now and plan for 11 December 2027.
- Flow the evidence list into supplier contracts.
- Track the Commission's guide, the citation of EN 50742, the Omnibus IV vote and the AI delegated acts.
Checklist for software suppliers, including Indian exporters
India's industrial software exporters, from PLC and HMI developers to machine vision, robotics and remote-monitoring platforms, sit in this supply chain, including the robot-learning startups in our physical AI piece.
- Treat remote access as a safety interface. Section 1.1.9 paragraph 1 covers remote devices, so IIoT and remote-service platforms sit inside your customer's threat model.
- Plan for source code requests. National authorities can request source code or programming logic of safety software on a reasoned request, where needed to check compliance.
- Prepare for the CRA. A product with digital elements placed on the EU market under your name carries CRA manufacturer obligations; reporting has applied since 11 September 2026.
- Mind the logs. Logs that record operator identities hold personal data under GDPR. The retention design in our DPDP engineering playbook carries over.
- Check the UK separately. SI 2026 No. 867, in force from 20 January 2027, lets machinery meeting the Regulation and carrying the CE marking be placed on the Great Britain market, with documents in English.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team helps machinery OEMs and industrial software suppliers build interface inventories, threat models, signed-update pipelines and tamper-evident logging for sections 1.1.9 and 1.2.1. Talk to us at /contact-us/.
Last updated: 1 November 2026.
