Cyber Resilience Act Reporting Obligations: What Machine Builders and OEMs Must Do Now

Since 11 September 2026, the EU Cyber Resilience Act (CRA) requires every manufacturer of a connected product sold in the EU to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix (for vulnerabilities) or one month (for incidents). The rest of the CRA applies from 11 December 2027.

Checked 1 October 2026. This is a summary for engineers, not legal advice. The legal text is Regulation (EU) 2024/2847; the articles quoted are listed under Sources.

What changed on 11 September 2026?

The CRA entered into force on 10 December 2024 with staggered dates. Article 71 sets them out:

• 11 June 2026: the rules on notified bodies (Chapter IV) applied, so conformity assessment bodies could be designated.
• 11 September 2026: Article 14, the reporting obligations of manufacturers, applied. ENISA launched the Single Reporting Platform (SRP) the same day.
• 11 December 2027: everything else applies, including the essential cybersecurity requirements in Annex I, conformity assessment and CE marking. Reporting duties for open-source software stewards also start then.

The part many teams miss is Article 69(3). The reporting obligations apply to all in-scope products placed on the EU market before 11 December 2027, not only new ones. A PLC, HMI or connected machine shipped in 2019 that is still in the field is covered today.

What exactly must be reported, and when?

Two events trigger a report: an actively exploited vulnerability in your product, meaning there is evidence a malicious actor is using it, and a severe incident having an impact on the security of your product, broadly one that affects its ability to protect the availability, authenticity, integrity or confidentiality of important data or functions, or that leads to malicious code being introduced or run. The clock starts when the manufacturer becomes aware.

1. Early warning, within 24 hours. A short alert, not an analysis. It indicates, where applicable, the Member States where you know the product has been made available. For an incident it also says whether it is suspected to be caused by unlawful or malicious acts.
2. Notification, within 72 hours. General information about the product, the nature of the exploit or incident, corrective or mitigating measures taken, measures users can take, and how sensitive you consider the information.
3. Final report. For a vulnerability, no later than 14 days after a corrective or mitigating measure is available, with its severity and impact, any information on the attacker, and details of the update. For a severe incident, within one month of the 72-hour notification.

Each report goes once, through the SRP, to the CSIRT designated as coordinator in the Member State of your main establishment and to ENISA; the platform shares it with the CSIRTs of other countries where the product is sold. Manufacturers without an EU establishment follow a hierarchy in Article 14 to find their CSIRT. You must also inform affected users about the vulnerability or incident and what they can do about it, and if you do not do so in time, the CSIRT may inform them itself.

Who counts as a manufacturer?

The CRA defines a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately. A manufacturer is anyone who develops or manufactures such a product, or has it made, and markets it under its own name or trademark, whether for payment or free of charge. The CRA covers products whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. A few sectors with their own cybersecurity rules, such as medical devices, motor vehicles and civil aviation, are excluded.

In automation, that plainly includes makers of PLCs, HMIs, drives, remote I/O, safety controllers, industrial switches, IIoT gateways, edge computers and engineering or SCADA software sold as products. It very likely includes machine builders who sell networked machines under their own name with their own control software on board. Location does not matter: a manufacturer in the US, China, Japan, the UK or India selling into the EU has the same duties.

Are PLCs and HMIs "important products"?

Not by name. The Commission's 2022 proposal listed industrial automation and control systems such as PLCs, DCS, CNC and SCADA, but the final Annex III does not. Class I includes routers, modems and switches, physical and virtual network interfaces, operating systems, VPN products, network management and SIEM systems, and microprocessors and microcontrollers with security-related functions. Class II covers hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers.

So many control products will fall in the default category, which allows self-assessment from December 2027, unless their core functionality matches an Annex III category (an industrial firewall or managed switch, for example). The class only changes how conformity is assessed. Reporting applies to every in-scope product, whatever its class.

What does it mean for machine builders and OEMs?

A machine is a stack of other people's products: a PLC, an HMI, drives, a switch, a gateway, an operating system. The CRA expects manufacturers to exercise due diligence on third-party components and, from 2027, to keep a software bill of materials (SBOM). For reporting, three practical questions decide whether you can meet a 24-hour deadline:

• Do you know what is in each machine? Which PLC firmware, which HMI runtime, which Windows build, at which customer, in which EU country. Without that, you cannot say which Member States are affected in an early warning.
• Will you hear about exploitation in time? When a PLC or HMI vendor publishes an advisory saying a flaw is being exploited, the component maker has its own reporting duty. Whether your machine is then also affected, and whether you must report too, is a judgement your product security owner needs to make quickly, with legal advice where it is unclear.
• Can you ship a fix? The final report depends on a corrective or mitigating measure being available. For machines in the field, that means a tested way to deliver firmware and project updates, or at least a documented workaround such as blocking a port.

What are the fines?

Article 64 sets three tiers. Non-compliance with the essential requirements in Annex I or the manufacturer obligations in Articles 13 and 14 can be fined up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other listed breaches carry up to EUR 10 million or 2%, and supplying incorrect or misleading information to authorities up to EUR 5 million or 1%. Microenterprises and small enterprises cannot be fined for missing the 24-hour early-warning deadline, and open-source stewards are exempt from fines. Member States set and enforce the penalty rules.

What should engineers who support these products do now?

Reporting is a process problem more than a technical one. The engineers who know the products (the firmware, the network services, the installed base) are the people a product security team will call at 2 a.m.

• Register before you need to. ENISA provides an FAQ, user manuals, tutorial videos, a glossary and a help desk for the SRP. Do the set-up while nothing is on fire.
• Agree definitions in advance. Decide who has authority to say "this is actively exploited" or "this is severe", and how you will record the time you became aware.
• Practise. Take a real past advisory for a component you ship and run the drill: could you have filed the early warning in 24 hours?
• Plan for December 2027. The Annex I requirements (secure by default, no known exploitable vulnerabilities at release, security updates for the support period, an SBOM) apply then, and they take longer to build into products than a reporting process does.

Where does IEC 62443 fit?

The CRA does not name IEC 62443, and European harmonised standards for the CRA are still being prepared. But automation vendors widely use IEC 62443-4-1 (a secure product development lifecycle, including vulnerability handling) and IEC 62443-4-2 (technical security requirements for components) as their working basis, because they cover much of the same ground as Annex I. If your company already follows 62443-4-1, you have the bones of CRA vulnerability handling: a contact for reports, triage, fixes, advisories and updates.

The free courses on EDWartens cover this ground:

• OT and ICS Cybersecurity with ISA/IEC 62443 for the standard's structure, zones and conduits, and security levels.
• Cybersecurity for PLC Programmers for hardening Siemens and Rockwell controllers.
• ICS Security Foundations for defence in depth and the 62443 requirements.
• OT Security Assessment for testing a plant without stopping it.

All four are on the OT and ICS security page, and the IIoT and OT security path puts them in order with the networking you need first. For background, read OT cybersecurity explained. The courses are free in full; the optional EDWartens Certificate of Completion is from US$2.99 and is not an IEC, ISA or ENISA credential.

Take the free course

Cybersecurity · Intermediate · Free

OT and ICS Cybersecurity with ISA/IEC 62443

Cybersecurity · Intermediate · Free

Cybersecurity for PLC Programmers: Hardening Siemens and Rockwell Controllers

Cybersecurity · Beginner · Free

ICS Security Foundations: Control Systems, Defence in Depth and the 62443 Requirements

Cybersecurity · Intermediate · Free

OT Security Assessment: Testing a Plant Without Stopping It