From 11 September 2026, the EU Cyber Resilience Act (CRA) starts applying its mandatory reporting obligations for actively exploited vulnerabilities and severe security incidents affecting products with digital elements. For Malaysian and Singapore manufacturers that design or supply connected industrial controllers, gateways, embedded devices, monitoring equipment, industrial software or other networked products into Europe, this is no longer a distant 2027 compliance issue.
The CRA’s main product cybersecurity requirements become applicable on 11 December 2027, but Article 14 reporting obligations start earlier. The European Commission states that manufacturers must submit an early warning within 24 hours of becoming aware of a reportable event and a fuller notification within 72 hours, through the CRA Single Reporting Platform managed by ENISA.
For anyone building connected equipment for Europe, this is no longer just a cybersecurity best-practice discussion. It affects market access and the whole product lifecycle. Firmware updates, version traceability, vulnerability handling and support periods now need to be designed into the product rather than added later.
What products can fall within the CRA?
The regulation applies broadly to a product with digital elements made available on the EU market where its intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
Depending on the specific product and exclusions, that can potentially include:
- industrial IoT gateways and remote monitoring devices;
- embedded controllers and intelligent sensors;
- industrial Ethernet or wireless communication devices;
- condition-monitoring and predictive-maintenance hardware;
- connected HMI or engineering software;
- remote I/O, data loggers and protocol gateways;
- industrial software supplied as part of a connected product;
- machine or equipment subsystems containing network-connected digital functions.
The CRA has exclusions and interactions with other EU sector legislation, so product classification must be performed product by product. Medical devices, certain automotive products, aviation products and marine equipment, for example, may fall under other regulatory regimes rather than the CRA.
The part that starts now: reporting
From 11 September 2026, manufacturers in scope must be capable of handling mandatory cybersecurity reporting. The European Commission’s CRA reporting guidance sets out the core timing:
| Event | Required action |
|---|---|
| Actively exploited vulnerability or severe security incident | Early warning within 24 hours of awareness |
| Reportable event | Full notification within 72 hours |
| Final reporting | Final report after corrective action, using the applicable CRA timetable |
ENISA’s Single Reporting Platform is scheduled to operate from 11 September 2026 for these mandatory notifications.
For an industrial product company, this creates an operational question that is easy to underestimate: who inside the organisation can recognise a reportable cybersecurity event, establish the affected product versions, determine customer exposure and prepare an evidence-based notification inside 24 hours?
This is not only an IT-security problem
For industrial and embedded products, CRA preparation crosses engineering, firmware, product management, service and quality functions. A vulnerability may originate in an operating system, bootloader, third-party library, web interface, communications stack, cloud API, diagnostic service or update mechanism.
A practical product-security workflow therefore needs more than a firewall. It should connect:
product identity → hardware revision → firmware/software version → third-party components → vulnerability assessment → affected installed base → corrective firmware/software → controlled update → customer notification → regulatory reporting.
This is especially relevant to long-lived industrial equipment. The CRA text recognises that industrial control systems are often used for significantly longer periods than consumer products, which affects the support period that manufacturers may need to define.
Five engineering controls worth implementing before 2027
1. Create a real software and firmware inventory
Manufacturers should know exactly which software components are inside each released product. That includes operating systems, communication libraries, web frameworks, cryptographic libraries, protocol stacks and open-source components. Without a reliable component inventory, vulnerability assessment becomes slow and uncertain.
2. Make firmware versioning and field identification unambiguous
Every deployed unit should be traceable to a hardware revision and firmware/software release. Serial numbers, production records and update history should allow engineering teams to determine quickly whether a discovered vulnerability affects 20 units, 2,000 units or none.
3. Design secure update and rollback mechanisms
A field-update process should support authenticity checking, integrity verification, controlled deployment and recovery from failed updates. For embedded controllers this may involve signed firmware, protected bootloaders, dual-image or rollback mechanisms, service authentication and release logging.
4. Treat industrial protocols and gateways as trust boundaries
Classical CAN, CAN FD, Modbus, serial links and legacy field protocols were generally not designed as end-to-end cybersecurity systems. Security has to be engineered around them using gateway segmentation, access control, authenticated service interfaces, firmware protection, monitoring and controlled diagnostics.
CANS has discussed this specifically for CAN-based products in CAN Security in 2026: What CANsec Changes—and What Machine Builders Must Secure Today.
5. Establish a vulnerability-response owner and clock
A 24-hour reporting clock is short. A manufacturer should define in advance who receives vulnerability reports, who performs technical triage, who approves customer communication, and who owns regulatory notification. Waiting until the first incident occurs is likely to create delay and inconsistent decisions.
Why this is particularly relevant to Malaysian manufacturers
Malaysia’s export-oriented electronics and machinery base makes product cybersecurity increasingly important. MIDA reported that in the first half of 2026, 31% of approved manufacturing projects planned to export at least 80% of their output, with E&E and machinery & equipment among the leading export-oriented sectors. MATRADE also reported RM126.42 million in potential exports generated at SEMICON Southeast Asia 2026, involving international buyers including European markets.
For manufacturers supplying OEMs, machine builders or technology companies in Europe, CRA readiness can therefore become a customer-qualification issue before the full 2027 enforcement date. European buyers may start asking suppliers for evidence of secure-development processes, vulnerability handling, support periods and update capability well ahead of statutory deadlines.
Singapore suppliers face the same market-access question
Singapore continues to expand advanced electronics, semiconductor and precision-engineering capabilities. EDB’s 2026 semiconductor investment programme is increasing activity in power electronics, advanced fabrication and high-value manufacturing. Companies building connected production equipment, embedded subsystems or industrial technology for multinational supply chains should assess CRA exposure whenever those products are placed on the EU market.
A practical CRA preparation checklist for industrial product teams
- List every connected product currently sold or expected to be sold into the EU.
- Determine whether each product falls inside CRA scope or another sector-specific regime.
- Map hardware, firmware, operating system, third-party software and remote services.
- Define product support periods appropriate to actual industrial service life.
- Implement a single vulnerability-reporting contact point.
- Set internal 24-hour and 72-hour incident-response procedures.
- Establish signed and auditable firmware/software release processes.
- Maintain serial-number and version traceability for deployed products.
- Document cybersecurity risk assessment and corrective-action decisions.
- Plan the 2027 conformity-assessment and technical-documentation work now rather than at product launch.
How CANS can help
CANS works across industrial automation and embedded-system development, including controller architecture, industrial communications, firmware, gateways, remote monitoring and integration. For manufacturers preparing connected products for international markets, the useful engineering work is often at the boundary between cybersecurity requirements and the actual embedded product design.
Relevant CANS services include embedded firmware architecture, secure update design, industrial gateway integration, product traceability, communications engineering and engineering and digitalisation consultancy. For connected field equipment, industrial IoT and remote monitoring architecture can also be reviewed from a product-security and lifecycle-support perspective.
If you sell connected products into Europe, start with one product. Map the firmware, software components and update path, then compare the way you support it today with the CRA reporting and lifecycle requirements. That exercise will expose most of the real gaps quickly.
Send CANS an enquiry or discuss CRA readiness for your industrial or embedded product on WhatsApp.
This article provides engineering and product-lifecycle guidance and is not legal advice. Product classification and regulatory obligations should be confirmed for the specific product and market route.
References
- European Commission — Cyber Resilience Act: Reporting obligations
- European Commission — Cyber Resilience Act: Summary of the legislative text
- EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)
- ENISA — CRA Single Reporting Platform
- MIDA — Malaysia approved investments, 1H 2026
- MATRADE — SEMICON Southeast Asia 2026 international sourcing programme
Recent Comments