Cyber Resilience Act for Start-ups: How to Prepare Vulnerability Reports by 11 September 2026

From 11 September 2026, start-ups that manufacture connected hardware or software for the European Union market may have only 24 hours to issue an early warning after becoming aware of an actively exploited vulnerability or a severe security incident. A more detailed notification will normally be required within 72 hours. These reporting duties take effect before most other Cyber Resilience Act requirements become applicable on 11 December 2027, which means young businesses cannot postpone preparation until their wider compliance work is complete. Every affected start-up should understand which products fall within the rules, who is authorised to make a reporting decision and how reliable information will be collected when an incident occurs.

Why the September 2026 Reporting Deadline Matters

The Cyber Resilience Act, formally known as Regulation (EU) 2024/2847, entered into force on 10 December 2024. Most of its product security, conformity assessment and documentation requirements will apply from 11 December 2027. However, the vulnerability and incident reporting duties under Article 14 begin earlier, on 11 September 2026. This separate timetable is important because a business may still be preparing its wider compliance documentation while already being legally required to report certain security events.

The rules generally concern hardware and software products with digital elements that are made available on the EU market and can connect directly or indirectly to a device or network. This may include mobile applications, desktop software, operating systems, security tools, connected equipment and software components distributed as separate commercial products. A remote processing function may also fall within the scope where it is necessary for the product to perform one of its intended functions.

Company size does not automatically determine whether the reporting obligations apply. A small business may be considered a manufacturer when it develops a product, has one developed on its behalf or sells that product under its own name or trade mark. The obligations may therefore affect early-stage companies with limited staff, including businesses that distribute free software as part of a commercial activity. Certain protections may reduce exposure to administrative fines for microenterprises and small enterprises that miss the 24-hour deadline, but they do not remove the reporting obligation itself.

What Start-ups Must Report and When

The first reportable category is an actively exploited vulnerability. This does not include every software defect or weakness discovered during routine testing. A vulnerability becomes relevant for this reporting duty when reliable evidence shows that a malicious actor has exploited it without the permission of the system owner. Evidence may come from customer reports, internal monitoring, a security researcher, a supplier or an investigation into suspicious activity.

The second category is a severe incident affecting the security of a product with digital elements. An incident may be considered severe when it negatively affects, or could negatively affect, the availability, authenticity, integrity or confidentiality of important data or product functions. It may also qualify when it results in, or could result in, malicious code being introduced or executed within the product or a connected user system.

After becoming aware of a reportable event, the manufacturer must submit an early warning without undue delay and no later than 24 hours. A fuller notification must normally follow within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report must normally be submitted within one month after the 72-hour notification.

How to Build a Reliable Internal Reporting Process

A workable reporting process begins with clear responsibility. The start-up should appoint a primary CRA reporting owner and at least one deputy who can act during holidays, weekends or periods when senior managers are unavailable. The reporting owner does not need to carry out every technical investigation personally, but must be able to start the assessment, gather information and obtain approval without unnecessary delays.

A small internal response group should normally include representatives from engineering, product management, information security, legal or compliance, customer support and senior management. Each participant should know their role before an incident occurs. The procedure should state who records the initial report, who decides whether the event may fall within the CRA, who prepares the notification and who communicates with customers, suppliers or authorities.

The business should also define what it means to become aware of an incident or vulnerability. Security information may arrive through customer support, an employee inbox, automated monitoring, a public code repository, a supplier, an external researcher or a hosting provider. If these channels are not connected to one escalation process, important evidence may remain unnoticed while the legal reporting period continues to run.

Preparing the Information for Each Notification

The 24-hour early warning is intended to provide prompt notice rather than a complete technical investigation. Start-ups should prepare a short internal form that can be completed with the information available during the first hours. It should identify the manufacturer, the affected product, the type of event, the time of initial awareness and the main reason why the vulnerability or incident may be reportable.

The 72-hour notification requires a clearer operational picture. For a vulnerability, the company should be ready to describe the general nature of the weakness, affected product versions, known exploitation methods and available corrective or mitigating measures. For a severe incident, the information should include the time of detection, the estimated time of occurrence, affected product functions, known consequences and the measures already taken.

The final report should explain what happened, why it happened, which versions or customers were affected and how the risk was removed or reduced. It should be consistent with engineering records, security investigations, customer notices and release documentation. Before submission, one person should check the technical accuracy while another verifies dates, wording and consistency with previous notifications.

A Practical Readiness Plan Before 11 September 2026

The first step is to create an inventory of every digital product supplied in the European Union, including older versions that remain in active use. For each product, the start-up should record the legal manufacturer, commercial name, current versions, EU countries where it is available, important remote functions, third-party components and the responsible internal contact.

The second step is to approve the reporting procedure and establish access arrangements. Management should confirm the reporting owner, deputy, escalation contacts and approval authority. The company should also identify the relevant national Computer Security Incident Response Team and ensure that authorised employees can access the ENISA reporting service when the obligations begin.

The third step is to conduct a timed exercise based on a realistic incident. For example, the team may receive a credible report that an authentication flaw in a current product is being exploited against users. Participants should record the awareness time, assess whether the issue is reportable, identify affected versions and prepare an early warning within 24 hours. The exercise should also test whether the process works outside normal office hours.

Common Reporting Mistakes Start-ups Should Avoid

One of the most serious mistakes is waiting for a complete forensic investigation or a finished security update before beginning the reporting process. The legal deadlines are linked to the time when the manufacturer becomes aware of the relevant vulnerability or incident, not to the date when every technical question has been answered. A report may therefore need to be submitted while parts of the investigation remain open.

Another mistake is treating every security weakness as a mandatory CRA notification. A vulnerability found during internal testing is not automatically an actively exploited vulnerability, and a minor technical incident is not necessarily severe. The company should distinguish between the existence of a weakness, credible evidence of malicious exploitation and the possible effect of an incident on users or product security.

Finally, reporting should not be treated as an isolated administrative task. Every notification should be supported by product records, incident logs, supplier communications, technical evidence and customer guidance. Before 11 September 2026, management should confirm that product scope has been reviewed, responsible employees have been appointed, access arrangements have been tested and at least one reporting exercise has been completed.