Nine days is enough time to test a reporting account. It is not enough time to invent an incident process after a customer reports that an attacker is already exploiting a flaw.

That is the practical pressure facing manufacturers whose software or connected products are available in the European Union. On 11 September 2026, the reporting provisions of the EU Cyber Resilience Act begin to apply—more than a year before most of the regulation's product-security requirements take full effect.

The early deadline matters to small businesses because the clock runs from awareness, not from the end of an internal investigation. A covered manufacturer must submit an early warning of an actively exploited vulnerability or a severe security incident within 24 hours of becoming aware of it. The European Commission says a fuller notification follows within 72 hours.

The first deadline is reporting, not full product conformity

The Cyber Resilience Act entered into force on 10 December 2024. Its main obligations—including essential cybersecurity requirements, conformity assessment and CE-marking duties—generally apply from 11 December 2027. Article 14 reporting obligations start earlier, on 11 September 2026. Treating 2027 as the only implementation date therefore leaves a material gap.

The reporting rule also reaches products already made available on the EU market before the main 2027 application date. A manufacturer cannot assume that an older supported product sits outside Article 14 simply because it was launched before the regulation was adopted.

Which businesses should examine their products

The regulation covers hardware and software products with digital elements, including components marketed separately, when they are made available on the EU market. The Commission's summary identifies operating systems, mobile applications, computer games, smart appliances, network equipment and software libraries among the broad examples. Remote data processing can also be part of the product when the product depends on it to perform a function.

The principal obligations fall on the manufacturer—the person or company placing the product on the market under its own name or trademark. That makes geography a poor screening test. A developer in the United States, United Kingdom, Canada, Australia, Singapore, Sri Lanka or elsewhere may still need to assess the CRA if it commercially supplies a covered product in the EU.

Not every digital service falls inside. The Commission explains that standalone services, including purely web-based software, are generally outside the product definition, while remote processing integral to a product may be included. Certain sectors governed by other Union legislation are excluded. A business with an uncertain product boundary should map the actual software, hardware, cloud dependencies and route to market rather than relying on a label such as SaaS or IoT.

Two events trigger the mandatory route

The first is an actively exploited vulnerability: a product weakness for which there is reliable evidence that a malicious actor has exploited it. The second is a severe incident affecting the security of the product. The regulation defines severity through effects such as disrupting the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, where the effect is serious enough to meet the statutory test.

A vulnerability does not become reportable merely because it exists. Equally, a company should not wait for perfect forensic certainty when evidence indicates active exploitation. The internal decision needs documented technical facts, a named decision-maker and access to legal or regulatory expertise where the classification is unclear.

The sequence continues after the first 24 hours

For an actively exploited vulnerability, the Commission describes an early warning within 24 hours and a vulnerability notification within 72 hours. A final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the same 24-hour early warning and 72-hour incident notification apply, followed by a final report within one month of the incident notification.

These are staged reports, not three copies of the same message. Early information can be incomplete. Later submissions add the available assessment, affected product information, mitigation or corrective measures and, for incidents, analysis such as severity, impact and likely root cause. The regulation also contains duties to inform affected users about the incident or actively exploited vulnerability and about measures they can take, where applicable.

ENISA's platform is the operational front door

Notifications are to be filed through the Single Reporting Platform established and managed by the European Union Agency for Cybersecurity, ENISA. The platform is intended to let a manufacturer report once rather than separately to every national authority. The reporting party selects the relevant national computer security incident response team, generally according to its main place of establishment under the regulation's routing rules.

A non-EU manufacturer or a group with several establishments should determine its routing position before an event. ENISA has published platform guidance and frequently asked questions, and says the platform is scheduled to be operational when mandatory reporting begins. Registration, authorised-representative arrangements and internal access should be tested against the official instructions rather than delegated to an employee who may be unavailable during an incident.

Small-company relief does not erase the obligation

The Commission's CRA summary notes a narrow penalty protection: manufacturers qualifying as microenterprises or small enterprises may not be fined for failing to meet the 24-hour reporting deadline for vulnerabilities and severe incidents. That protection is not an exemption from reporting, and it does not remove the rest of the CRA or other applicable cybersecurity, privacy and sector rules.

For a small manufacturer, the safer interpretation is operational rather than defensive. The firm should still build a process capable of meeting the deadline. Late awareness inside the company, uncertainty over who is authorised to file, or a support inbox left unread can delay customer protection even where a particular fine is unavailable.

What should exist before 11 September

Start with a product register showing every covered product and supported version available in the EU, the responsible legal manufacturer, the relevant EU establishment or representative, current support contacts and the person authorised to submit a report. Link each product to its vulnerability intake channel, engineering owner and customer-notification method.

Next, write a one-page escalation rule. Customer support, resellers, researchers and developers need to know where suspected exploitation goes, which facts must be preserved and who can declare an incident severe. The process should function outside normal office hours because the regulation measures hours, not business days.

Run a short exercise using a believable scenario: a researcher supplies a proof of exploitation on Friday evening; a connected device begins exposing customer data; or a software component used in several versions is compromised. Can the team identify affected products, preserve logs, reach management, assess user risk, enter the reporting platform and prepare a truthful early warning without pretending the investigation is complete?

The commercial lesson reaches the supply chain

Importers, distributors, development contractors and component suppliers may receive the first warning even when the legal reporting duty belongs elsewhere. Contracts should specify how rapidly security information moves, who retains technical evidence and who communicates with users. A supplier agreement that promises notification only after a completed root-cause report may be incompatible with a manufacturer's 24-hour clock.

The September deadline is therefore less about producing a large compliance manual than removing ambiguity. A manufacturer needs to know which products are covered, what evidence triggers escalation, who makes the decision and how the report reaches ENISA. Those four answers are difficult to improvise while an exploit is active—and inexpensive to test before one is.

Explore More

Open the official CRA reporting guidanceCheck the reporting events, staged deadlines and current European Commission instructions.Prepare for the ENISA reporting platformReview current platform guidance, registration material and frequently asked questions from ENISA.

Research sources

Comments

Join the discussion. Please keep comments respectful and relevant to the article.

No comments yet. Be the first to comment.