From 11 September 2026, the EU Cyber Resilience Act (CRA) requires manufacturers to report certain security events affecting products with digital elements made available on the European Union market. That date has passed. The broader product-security requirements arrive on 11 December 2027, but reporting is already in force.
For an industrial-controller or gateway manufacturer in Malaysia or Singapore, the hard part is often knowing which firmware version was shipped to which customer, who assesses an incident and how to maintain equipment operating behind a factory firewall.
Two different CRA deadlines
| Date | What applies |
|---|---|
| 11 September 2026 | Reporting of qualifying actively exploited vulnerabilities and severe incidents affecting product security. |
| 11 December 2027 | Most product-security, vulnerability-handling, documentation and conformity obligations. |
The European Commission confirms that the 2026 reporting duty can reach products with digital elements already made available in the EU before the 2027 date. Scope and exclusions still need checking; not every PLC program or locally installed control system is automatically a product covered by the CRA.
A published CVE is not automatically a reportable exploit
The law distinguishes an actively exploited vulnerability from a vulnerability that has only been identified or theoretically demonstrated. Qualifying severe incidents affecting the security of the product must also be reported. Manufacturers need evidence about the affected product versions, exploit status and consequences before deciding that notification criteria are met.
The early warning is due within 24 hours of awareness and the fuller notification within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, a final report follows within one month of the 72-hour notification. These are reporting milestones, not a promise to deliver replacement firmware within 24 hours.
Notifications use ENISA’s Single Reporting Platform. It launched on 11 September 2026 and ENISA reported an upgrade to version 1.1 on 12 October 2026. The authorised contact and reporting procedure should be settled before an actual incident occurs.
Identify the affected hardware first
Consider an embedded-Linux gateway with Ethernet, Modbus RTU and a maintenance web interface. A serious vulnerability appears in a third-party library. Does it affect every shipped unit, one firmware branch, or only products where a particular service is enabled? A supplier cannot assess the incident quickly without release records.
Keep a traceable link between serial-number range, PCB revision, bootloader, firmware hash, operating-system packages, software components, exposed interfaces and update method. A software bill of materials (SBOM) helps when it matches the image actually released. A list generated from the current development branch does not prove what was shipped last year.
Evidence of exploitation, reachability, configuration and compensating controls all matter. The same vulnerable library in a disconnected test fixture and in an Internet-facing gateway presents a different engineering problem.
Updating an industrial controller is not a smartphone update
Firmware maintenance must survive loss of power, corrupt downloads, configuration differences and restricted access to the plant. Depending on hardware and threat model, that may mean authenticated packages, protected keys, boot integrity checks, dual images or a defined recovery route. Recovery rollback and resistance to malicious downgrade are separate design considerations.
Where controllers have no Internet access, signed offline packages and technician-authorised installation may be essential. Test the installed firmware version, retained process configuration and normal machine behaviour after the service visit. Safety PLCs, emergency stops and hazardous-motion interlocks must remain within their validated safety design; an application firmware patch is not permission to bypass them.
IEC 62443 and the product lifecycle
IEC 62443-4-1 describes secure development lifecycle processes for industrial automation products: requirements, secure coding, verification, defect management, patch management and end-of-life. Those are useful disciplines for embedded OEMs. Applying the standard is not, by itself, proof of CRA conformity. Product scope, supplier responsibilities and the applicable conformity route need separate assessment.
I would test the process using one controller family already sold into the EU. Reconstruct the released component inventory, identify the customers using affected firmware, and run a tabletop exercise involving credible active exploitation. Who makes the reportability decision, who prepares the 24-hour early warning, and who can deliver a verified mitigation without leaving a machine unusable? If the answers sit only in one engineer’s memory, the work is not yet under control.
CANS works on embedded systems, industrial communications and automation integration. For controller firmware, industrial gateway design or maintenance architecture, send CANS an engineering enquiry or WhatsApp +60 12-295 9602.
Featured photo: Raymond Sime / Unsplash (Unsplash Licence). Regulatory scope requires assessment for the actual product and market.
References
- European Commission, Safer and more secure digital products, 11 September 2026.
- European Commission, CRA reporting obligations.
- ENISA, CRA Single Reporting Platform launch, 11 September 2026.
- ENISA, SRP documentation, updated 12 October 2026.
- IEC 62443-4-1:2018.
Recent Comments