From 11 September 2026 the manufacturer of a product with digital elements must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware of them, a full notification within 72 hours, then a final report. Reporting is done on ENISA’s single platform, and it also applies to software already on sale.
The reporting obligations are one of the parts of the Cyber Resilience Act, Regulation (EU) 2024/2847, that apply before the rest of the text. The regulation applies in full from 11 December 2027.
What are the reporting obligations of the Cyber Resilience Act?
The manufacturer must report two things: actively exploited vulnerabilities and severe incidents having an impact on the security of the product. For both, the Commission’s page on the reporting obligations sets three deadlines:
- an early warning within 24 hours of the manufacturer becoming aware;
- a full notification within 72 hours;
- a final report, which for an exploited vulnerability must be sent within 14 days of a corrective measure being available, and for a severe incident within one month of the 72-hour notification.
The 24 hours start from the moment you learn of the problem. For anyone with a product on the market, that means knowing already today who receives the alert, even on a Saturday, and who is able to send the early warning.
How does ENISA’s reporting platform work?
You report once only, on the CRA Single Reporting Platform, which ENISA has developed and runs. The notification goes to the CSIRT designated as coordinator, which forwards it to the CSIRTs of the other Member States where the product is available, and at the same time it is made available to ENISA.
The platform has been live since 11 September 2026 in its first operational capability. ENISA writes that it will extend its functions in the coming months, and it has opened a help desk for questions that the published guides do not cover.
Who is the manufacturer that must report?
It is whoever develops or manufactures products with digital elements, or has them designed, developed or manufactured by others, and markets them under their own name or trademark. Against payment, with other forms of monetisation or free of charge. The definition is the one in the summary of the text published by the Commission services, which states that it does not represent its official position.
The second half of the sentence is what matters. A company that has an app or a portal developed by a software house and sells it to its own customers under its own brand seems to fall within the description, even if it has not written a line of code. This is our reading of the summary, and it should be checked against your own contract.
The same summary says that the manufacturer sets a support period, during which it ensures that vulnerabilities are handled, and that the date on which it ends, month and year, must be clearly indicated at the time of purchase.
Do the obligations also apply to software already sold?
The reporting ones do. The FAQs on the Cyber Resilience Act from the Commission services (1.4 and 5.3), a document that states it has no binding interpretative value, explain this with Article 69 of the regulation.
The general rule, in Article 69(2) according to the FAQs, is that a product placed on the market before 11 December 2027 must comply with the requirements of the regulation only if it undergoes a substantial modification from that date. The reporting obligations of Article 14 are an exception, under Article 69(3): from 11 September 2026 they apply to all products with digital elements within the scope of the regulation, including those placed on the market before.
There are three dates to keep in mind. The regulation has been in force since 10 December 2024, reporting is mandatory from 11 September 2026, and from 11 December 2027 the regulation applies in full.
For a product already sold that falls within the regulation, then, the reporting obligation applies today. The requirements will concern it only if it is substantially modified from 11 December 2027.
Is custom software excluded from the CRA?
No. The Commission FAQs (4.2.5) talk about “tailor-made” products, adapted to a particular purpose for a particular business user, and among the examples is software custom-developed for the needs of a specific company. For these products the manufacturer may depart from two essential requirements:
- secure by default configuration (Annex I, Part I, point 2(b));
- the provision of security updates free of charge (Annex I, Part II, point 8).
It can do so only if manufacturer and user have explicitly agreed different contractual terms. The FAQs then expect the manufacturer to put in the technical documentation the evidence that the product really is tailor-made. Vulnerability reporting does not appear among the two requirements.
There is also a negative example: a CRM platform sold to several companies is not tailor-made, even if the supplier allows some minor customisation.
Does the CRA apply to software used in-house and to SaaS?
For own use, the FAQs (1.5) say that a product manufactured for own use is not placed on the market, and the Cyber Resilience Act does not cover it. The example they give is the development and configuration tools that a manufacturer develops for itself. For software that a company has developed by a supplier and uses internally, the FAQs give no answer: the question should be put to a lawyer, with the contract to hand.
For the cloud the answer is less clear-cut. The FAQs (1.2) say that a standalone Software-as-a-Service, designed and developed outside the responsibility of the manufacturer of a product with digital elements, is not in itself a product with digital elements. It does, however, fall within the regulation if it matches the definition of “remote data processing” in Article 3(2). The Commission has announced separate guidance on this concept. Until it exists, for an app that works with its own backend in the cloud we would treat the backend as part of the product: it is our own caution.
What should the contract with the supplier say?
Who the manufacturer is, who does the reporting and within how many hours the supplier gives notice. These are the first lines we would put in writing if you sell a product developed by others, because the 24 hours can only be met if whoever discovers the problem and whoever reports it have already agreed. This is our reading as a software house, not a Commission text. The full list:
- who the manufacturer is, and therefore who submits the report on ENISA’s platform;
- the internal timescales between supplier and client: within how many hours the supplier gives notice, through which channel, and who decides whether the vulnerability is actively exploited;
- the list of third-party components (the SBOM, the software bill of materials) and who keeps it up to date, because a vulnerability can sit in a library that neither of the two wrote;
- the length of the support period and the response times of maintenance during that period;
- for a custom product, an explicit clause on any derogations and the evidence to keep in the technical documentation.
For your own case, who is the manufacturer and what to write, the answer comes from a lawyer who knows the product and the contract.
Two facts about dotenv, for anyone assessing a supplier. We are certified UNI CEI EN ISO/IEC 27001:2024 for the design, development and support of software solutions and applications: the certificate is on the certifications page. It is a standard on information security management, and it does not certify that a product complies with the Cyber Resilience Act. And the source code belongs to whoever paid for the work, and stays theirs even if one day they choose another supplier.
What to do now about the Cyber Resilience Act?
A list: which products the company markets under its own name, who developed them, which are still in use and by whom. With that list you can see for which products the question of the manufacturer arises, and with which supplier an agreement on timescales needs to be written. For a lighter step, ENISA’s guides on the platform and section 5 of the Commission FAQs are devoted to the reporting obligations.
If the product is an app or a portal to be built, on the web app development page we describe the phases through which we develop one, up to deployment and periodic updates with bug fixes, and three projects we have delivered. From there you can ask for a first call.