CRA reporting duties for software makers since 11 Sep 2026

Since 11 September 2026, a manufacturer of software or any other product with digital elements sold in the EU has had to report actively exploited vulnerabilities and severe incidents in that product. The first warning is due within 24 hours of the manufacturer becoming aware, it goes through one platform run by ENISA, and the regulation as a whole applies from 11 December 2027.

Who has to report?

The regulation puts the duty on the manufacturer. Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark, whether for payment, monetisation or free of charge. A company that writes software for a client and does not sell it under its own name is therefore not obviously the reporting party. Whether a given contract makes it one is a question for a lawyer. Our reading is that the client, as the manufacturer, carries the duty, and will want its suppliers to pass on what they learn quickly.

"Product with digital elements" includes software and its remote data processing solutions. The Commission's July 2026 guidance explains that a cloud service built by or for the manufacturer to support a function of its product can count as a remote data processing solution, while a third-party software-as-a-service application the manufacturer merely licenses does not. The guidance is not binding. Only the Court of Justice of the European Union can give an authoritative interpretation.

Open-source software stewards are covered too, under Article 24(3). The Commission's reporting page says this applies from 11 December 2027.

What counts as reportable?

Two things trigger the duty, and both are defined in the regulation. The first is an actively exploited vulnerability, which Article 3(42) describes as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". A flaw found by a good-faith tester and fixed before anyone abused it is outside that definition. The Commission's FAQ, which its own preface says was prepared by Commission services and is not the Commission's official position, gives two examples of zero-days that are not reportable: one disclosed through a bug-bounty programme, and one found by a test laboratory working for the manufacturer, in both cases with no evidence of earlier malicious exploitation. The manufacturer may still report them voluntarily under Article 15.

The second is a severe incident. Under Article 14(5), this is an incident that negatively affects, or could negatively affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It also counts if it has led, or could lead, to malicious code being introduced or run in the product or in a user's network and information systems.

Third-party components are the third case to consider. A vulnerability in a third-party component is reportable by the product's manufacturer when it is actively exploited in that product. Under the guidance, a component flaw that cannot be exploited in the product, or has not been, is not subject to mandatory reporting, though the manufacturer still has to pass it upstream under Article 13(6).

What are the deadlines?

The clock starts when the manufacturer becomes aware, and Article 14(2) and (4) set three steps for each type of event.

• The early warning is due without undue delay and in any event within 24 hours of becoming aware, and for a vulnerability it names, where applicable, the Member States where the product is available, while for an incident it says at least whether unlawful or malicious acts are suspected.

• The notification is due within 72 hours of becoming aware, and it carries general information on the product, the nature of the exploit or incident, and the measures taken or that users can take.

• The final report is due no later than 14 days after a corrective or mitigating measure is available for a vulnerability, and within one month after the 72-hour notification for an incident.

The Commission's reporting page states the same deadlines. A CSIRT may also ask for an intermediate status report (Article 14(6)).

"Becoming aware" is not defined in the regulation, so a team has to decide for itself when its 24 hours began. The guidance says a manufacturer is regarded as aware when, after an initial assessment, it has "a reasonable degree of certainty" that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product's security. It adds that the emphasis is on carrying out that assessment promptly. Because the guidance is non-binding, a national authority could read the term differently.

Where do manufacturers report?

Article 14(1) and (3) require one notification, sent at the same time to the CSIRT designated as coordinator and to ENISA, through the single reporting platform that Article 16 tasks ENISA with establishing. Article 14(7) says the notification goes to the CSIRT of the Member State where the manufacturer has its main establishment in the Union, meaning where decisions on the cybersecurity of its products are mainly taken. If that cannot be determined, it is the Member State where the manufacturer has the most employees in the Union. A manufacturer with no establishment in the Union follows a fixed order, starting with the Member State of its authorised representative.

ENISA's launch announcement dated 11 September 2026 says it deployed the "initial operating capability" of the platform, and that a help desk is available for questions the published guidance does not answer. ENISA's platform page links the platform, user guidance, a glossary, FAQs and terms and conditions. It also records that the platform was upgraded to version 1.2.1 on 20 October 2026, and that its documentation was still being updated for that change.

A CSIRT may delay passing a notification on to other CSIRTs on cybersecurity grounds in exceptional cases. The Commission specified the conditions in Delegated Regulation (EU) 2026/881.

Does it apply to software already on the market?

Yes. Article 69(3) says Article 14 applies to all products within the regulation's scope that were placed on the market before 11 December 2027. The guidance adds that the reporting duty continues after a product's support period ends.

The duty has a limit in time, because it is not retroactive. The guidance says a manufacturer need not report a vulnerability whose active exploitation it already knew about before 11 September 2026. If it knew of a flaw before that date and saw exploitation only afterwards, the duty applies.

What else does Article 14 require, and what is the penalty?

Once aware, the manufacturer must also inform affected users, and where appropriate all users, about the vulnerability or incident and any steps they can take (Article 14(8)). The guidance says this is applied in a risk-based way and need not mean public disclosure. Under Article 17(4), the act of notifying does not by itself expose the notifier to increased liability.

Article 64(2) sets fines for non-compliance with Articles 13 and 14 of up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover in the previous financial year, whichever is higher. Member States set their own penalty rules under Article 64(1), so the practice in a given country may differ.

What should a software team check now?

This section is our addition. It turns Article 14 into questions for an internal runbook. It is not legal advice.

The first questions concern people and roles. Decide who the manufacturer is for each product and who files, remembering that the definition points to the company that markets the product under its own name. Name who can judge "reasonable certainty", because someone has to make the call that starts the 24-hour clock, at any hour. If you build or run part of a product for someone else, agree how fast you tell them about suspected exploitation, so they can meet 24 hours. Decide your main establishment as well, since it determines which national CSIRT receives your report.

The remaining checks concern preparation. Prepare the 24-hour content in advance: affected Member States, and for an incident whether malicious acts are suspected. Check which of your products and versions are older than 11 December 2027 and still in use, because they are covered. Prepare the user message from Article 14(8), including a machine-readable format where appropriate, and keep a log of when each event was first noticed, assessed and reported.

Regular security testing helps you find flaws before attackers do, which means fewer events to report. Our application security testing page describes what we test, and our security and data protection page describes how we handle incidents on client projects.

What we could not confirm

We could not open EUR-Lex directly, because it blocks automated requests. We read the Official Journal text of Regulation (EU) 2024/2847 as served by the EU Publications Office and linked EUR-Lex for readers. We did not read ENISA's user manual or glossary, so we do not describe registration or the form fields.

The Commission's guidance document we read is dated 27 July 2026 and states that it will be formally adopted when all language versions exist. The Commission's FAQ says the Commission "has also adopted" guidance. We could not confirm whether formal adoption has happened.

The Commission proposed a single entry point for incident reporting in November 2025. Its FAQ says the point would build on ENISA's CRA platform and would not change existing reporting obligations, and we could not confirm where the proposal stands. The sources we found are silent on how many reports have been filed and on enforcement by any national authority. Penalty laws of individual Member States were outside our check.