SME Device Makers Face a 24-Hour Flaw Reporting Duty From September 2026

For small and mid-sized manufacturers of connected products, the first live obligation under the EU Cyber Resilience Act is not a product redesign. It is an incident-response capability. From 11 September 2026, manufacturers placing products with digital elements on the European market must be able to warn the EU Agency for Cybersecurity (ENISA) and the relevant national cyber security body about actively exploited vulnerabilities within 24 hours of becoming aware of them.

That date sits well ahead of the deadline most firms have pencilled into their plans. The bulk of the regulation's product obligations apply from 11 December 2027, and many smaller manufacturers have treated that later date as the one that matters. The reporting duty arrives more than a year earlier, and it depends on groundwork that cannot be assembled in a fortnight: a monitored security contact, a way of identifying which shipped versions contain an affected component, and a named person accountable for a clock that starts the moment a researcher sends an email.

A timetable that puts reporting first

The Cyber Resilience Act follows a staged calendar rather than a single switchover. Notified-body provisions apply from 11 June 2026, establishing the conformity assessment infrastructure that some product categories will need. Vulnerability and incident reporting follows on 11 September 2026. The main body of obligations — security-by-design requirements, technical documentation, conformity assessment and CE marking — applies from 11 December 2027.

The sequence is deliberate but easily misread. A manufacturer that plans only for December 2027 will spend the autumn of 2026 without the reporting channel the regulation already requires, and without the internal records needed to answer a report accurately. The reporting duty is also narrower than the later obligations, which makes it a useful place to start: it concerns events rather than product architecture, and the process built to handle it feeds directly into the risk assessment and technical documentation that conformity work will demand later.

Scope matters here. The regulation reaches manufacturers wherever they are established, provided their products are placed on the EU market, and firms outside the EU generally need an authorised representative inside it. Small exporters that sell through European distributors should confirm where the obligation lands before assuming a customer will carry it.

What starts the clock

Two categories of event trigger reporting. The first is an actively exploited vulnerability in the product. The second is a severe security incident affecting the security of the product. In both cases the manufacturer must notify ENISA and the national computer security incident response team designated as coordinator, through the single reporting platform the regulation establishes.

The sequence is staged rather than a single filing:

• An early warning within 24 hours of becoming aware, flagging the suspected malicious exploitation and, where applicable, the member states where the product has been made available.
• A fuller notification within 72 hours, setting out the general information available about the incident, the affected product, the nature of the exploitation and any corrective or mitigating measures taken or planned.
• A final report at a later point, covering the root cause, the measures applied and, where relevant, the steps taken to protect customers.

The practical difficulty is not the form. It is the word "aware". Awareness usually arrives informally — a customer email, a conference disclosure, a researcher's message to a general enquiries address — and the 24-hour period runs from that point, not from the moment a company decides the matter is serious. A security contact that nobody monitors is not a reporting channel; it is a liability with a mailbox.

The unglamorous prerequisites

Meeting the duty depends on five things that are administrative before they are technical.

First, a published and monitored security contact, distinct from sales and support addresses, with someone assigned to triage what arrives. Second, a coordinated disclosure policy that tells researchers what to expect and gives staff a route to follow. Third, a software bill of materials, so that a report naming an open-source component can be traced to products. Fourth, version and shipment records, so the firm can say which units in the field carry the affected build. Fifth, a named process owner with the authority to convene engineers, draft a notification and decide what customers are told.

Where small firms typically break is at the joins. There is no intake channel for external researchers, so reports arrive through a support queue and stall. There is no component inventory, so the firm cannot tell whether the affected library shipped in the 2023 model or only the 2025 one. And there is no practical mechanism for pushing an update to devices already installed in customers' premises, which turns a fixable defect into a prolonged exposure.

Classification should be settled early

The regulation does not treat all products alike. Some categories carry heavier requirements and require third-party conformity assessment, while others may be assessed by the manufacturer itself against harmonised standards. Which class a product falls into shapes the depth of documentation, the testing evidence and the assessment route — and it is far cheaper to establish at the start of development than to discover during a launch review. The reporting duty applies regardless, but the records generated by handling a vulnerability properly are the same records a notified body or an auditor will later ask to see.

The commercial case for building it now

The regulation includes provisions intended to lighten the documentation and procedural burden on smaller firms, recognising that a twenty-person manufacturer cannot run the compliance apparatus of a multinational. That relief is real, but it does not extend to being unreachable when something goes wrong.

The commercial argument is separate and, for many SMEs, more immediate. Large buyers and public procurers already ask suppliers how they handle vulnerabilities: whether they have a security contact, whether they publish advisories, how quickly they patch, and whether they can identify affected versions. A documented process answers those questions with evidence rather than assurance. Firms that build the reporting machinery during 2026 will find the December 2027 obligations easier to meet, because the inventory, the update path and the incident log will already exist. Firms that wait will be assembling all of it under deadline pressure, with the first live obligation already in force.

The 24-hour duty is best understood not as a filing requirement but as a test of whether a manufacturer can find out what it shipped, decide what to do about it, and tell the right people quickly. That capability is worth having whether or not a regulator is watching.