The Cyber Resilience Act is the EU law that imposes mandatory cybersecurity requirements on products with digital elements, from a mobile app to a connected camera. It was adopted as Regulation (EU) 2024/2847 and came into force on 10 December 2024, but its obligations arrive in stages. The first has applied since 11 September 2026. Since that day, every manufacturer that makes digital products available in the European Union must report actively exploited vulnerabilities and severe incidents, with an initial warning within 24 hours. The bulk of the regulation does not apply until 11 December 2027. For fifteen months a fully enforceable duty to report will coexist with a set of technical requirements that cannot yet be enforced. The full scope of the regulation, with product classification and CE marking, is in our guide to what the Cyber Resilience Act is and which companies it covers.
If you need a lawyer to help you comply with the Cyber Resilience Act, request a free initial assessment.
Article 14 imposes two different reporting duties. The first covers vulnerabilities in the product that are being actively exploited. The second covers severe incidents having an impact on the security of the product. Both are triggered when the manufacturer becomes aware of the event, not when it confirms or diagnoses it.
The distinction matters because the deadlines are identical but the content of the reports is not, and because a single event can fit both cases at once.
A vulnerability is considered actively exploited when there is reliable evidence that a third party has taken advantage of it in a system without the owner’s permission. The definition does not require damage to have occurred or data to have been exfiltrated. Carrying out the attack is enough.
The duty covers vulnerabilities in the product as a whole, including those in third-party components integrated into it. A manufacturer is not released by arguing that the flaw lies in an open-source library it did not write. If that library ships inside its product, the vulnerability is its own for reporting purposes.
As well as notifying the authority, the manufacturer must inform the affected users of the product without undue delay and, where appropriate, tell them which corrective or mitigating measures they can take.
An incident is severe when it negatively affects the product’s ability to protect the availability, authenticity, integrity or confidentiality of the data or functions it handles. It is also severe when it leads, or could lead, to malicious code being introduced or executed in the product or in the user’s network and information systems.
The threshold is measured on the product, not on the organisation. An intrusion into the manufacturer’s corporate systems that does not degrade the security of the product on the market falls outside Article 14, although it may trigger other rules such as the NIS2 Directive or the GDPR breach notification duty.
The regime is built on three successive communications about the same event. An early warning within 24 hours, a full notification within 72 hours and a final report whose deadline depends on whether a vulnerability or an incident was reported. The early warning and the full notification run from when the manufacturer became aware of the event. The final report has its own starting point, which is not awareness.
| Deadline | Communication | Minimum content |
|---|---|---|
| 24 hours | Early warning | Indication that there is active exploitation or a severe incident, and the Member States where the product is available |
| 72 hours | Full notification | Technical data, severity and impact, and corrective measures taken or available to users |
| 14 days | Final report on a vulnerability | Counted from when a corrective measure is available. Description of the flaw, severity, impact and fix applied |
| 1 month | Final report on a severe incident | Counted from the 72-hour notification. Nature, likely root cause and mitigation measures |
The 24-hour clock is the real point of friction. It starts running with awareness, not with diagnosis. A company that receives a report from an external researcher on a Friday afternoon has until Saturday afternoon to send the early warning, even if its technical team has not yet been able to reproduce the flaw.
The reporting obligation falls exclusively on the manufacturer, meaning whoever develops the product or has it developed and markets it under its own name or trademark. Importers and distributors do not report to the authority. They must inform the manufacturer without undue delay when they identify a vulnerability, but they do not start the 24-hour clock.
The regulation places open-source software stewards in a category of their own, with a more limited duty than the manufacturer’s. They report actively exploited vulnerabilities in the products they develop, without being subject to the rest of the conformity regime.
Being a manufacturer does not depend on having a factory. A software company that sells a management application under its brand is a manufacturer for the purposes of the regulation, even if development is outsourced and there is not a single physical component in the product.
The reporting obligation covers all products with digital elements placed on the market before 11 December 2027, however old they are. A router sold in 2019 or a discontinued line with no support are within it. This follows from Article 69(3), which expressly excludes Article 14 from the transitional regime.
Article 69(2) releases products placed on the market before that date from the essential requirements of Annex I as long as they are not substantially modified. That relief does not extend to reporting. A manufacturer may not be required to redesign an old product and yet be required to report, within 24 hours, an exploited vulnerability in that same product.
The duty is triggered by awareness, not by the date of sale. What counts are the vulnerabilities and incidents the manufacturer becomes aware of from 11 September 2026, not those it already knew about before. That does not make the past irrelevant, because an old vulnerability that becomes actively exploited after that date does give rise to a reportable event.
The Cyber Resilience Act Single Reporting Platform has been in service since 11 September 2026, the date on which ENISA deployed its initial operational capability, and is at portal.cra-srp.enisa.europa.eu. It is the channel through which manufacturers report actively exploited vulnerabilities and severe incidents, and it works on the principle of reporting once to reach all the competent authorities.
Distribution is automatic. The incident response team that receives the report shares it without delay with the other CSIRTs of the Member States where the product is available, and ENISA receives it at the same time. The manufacturer does not repeat the process country by country, which was the scenario Article 14 sought to avoid.
Emailing the national CSIRT does not meet the obligation, even if you already have a relationship with that team. The platform is the single channel and forwarding to the other Member States concerned happens within the system itself.
Access to the platform requires registering in advance. Each company appoints Assigned Representatives, with a primary role and secondary roles, and ENISA publishes a specific manual for that profile alongside the terms and conditions of the service, in force since 10 September 2026.
The order matters. The 24-hour clock runs from when the manufacturer becomes aware of the exploited vulnerability, not from when it manages to log into the portal. A company that starts registering on the day of the incident spends on paperwork the hours it needs for the technical analysis.
The launch is manual. No application programming interface is available, so automatic integration with internal vulnerability management tools will have to wait. The version in service is the initial operational capability, and ENISA will extend its features over the coming months based on user experience.
Three operational limits shape day-to-day work. Accounts not yet validated can submit up to twenty notifications before validation becomes mandatory. Voluntary reporting under Article 15 was not included in the launch and will come in a later phase with no announced date. And if the platform is not operational, the manufacturer can contact its CSIRT directly, although the notification will then have to go through the system.
On 4 September 2026 ENISA published the list of CSIRTs designated as coordinators in the twenty-seven Member States. Spain routes its notifications through INCIBE-CERT, with two separate channels, one for incidents and another for vulnerability coordination and CVE assignment. Until that date the Spanish recipient was unknown.
The reporting obligations reach open-source software stewards from 11 December 2027, the same date on which the bulk of the regulation applies. Until then Article 14 binds manufacturers, as the European Commission states in its reporting documentation.
Where the manufacturer has no establishment in the Union, responsibility follows a chain. First the authorised representative, then the importer, then the distributor and, as a last resort, the Member State where the largest number of users is located.
INCIBE-CERT being listed by ENISA as Spain’s coordinating CSIRT settles who receives the reports, not who supervises the market or who imposes penalties. These are separate functions and only the first has been settled. The European channel came into service before the national enforcement arm.
Spain reached 11 September without having formally designated its authorities under the regulation, and as of October 2026 it still has not done so. The draft royal decree that is to do so assigns market surveillance to the Secretary of State for Telecommunications and Digital Infrastructure and the role of notifying authority to the National Cryptologic Centre (CCN). The Spanish competition authority (CNMC) issued its report IPN/CNMC/007/26 (in Spanish) on 13 May 2026 and the text is still being processed.
The lack of designation suspends nothing. The Cyber Resilience Act is directly applicable and needs no national implementing law to be binding. What remains unresolved is who investigates and who imposes penalties in Spain, not whether the obligation exists.
It is the same pattern already seen with the transposition of NIS2, where the national legislative delay coexisted with fully enforceable European obligations. The two should not be confused. A full review of this overlap is in our guide to the digital regulatory framework in Spain and the European Union.
Article 64 sets three tiers of administrative fines and in each one the higher of the fixed amount and the percentage of worldwide annual turnover applies. Breaching the reporting duty falls in the highest tier.
Fines are imposed by the national market surveillance authorities, which in Spain again depends on the pending royal decree. The practical short-term risk is not so much an immediate fine as an accumulation of documented breaches that an authority will be able to review once it is in place. The full regime, with the exceptions and product withdrawal, is in our analysis of Cyber Resilience Act penalties.
Preparation is organisational before it is technical. The obligation already applies, and the urgent task is not to redesign the product but to set up the process that makes a 24-hour deadline achievable. These are the seven points to have settled.
A company in Valencia, which we will call Domotek, manufactures connected thermostats and sells them in Spain, Portugal and France. An independent researcher writes to it on a Friday at 6 pm with evidence that a flaw in the pairing module is being used to access several customers’ home networks.
The clock starts at 6 pm on Friday, not on Monday when the product team reads the email. Domotek has until 6 pm on Saturday to send the early warning, stating that there is active exploitation and that the product is sold in three Member States. It has until 6 pm on Monday for the full notification, with technical data and available measures. The notification is submitted to the Spanish coordinating CSIRT, which passes it on to Portugal and France without Domotek having to send it three times.
At the same time, and without waiting for the final report, it must warn the affected users and tell them what they can do while the patch arrives.
In cybersecurity compliance, the point of failure is rarely technical. It is internal governance. The vulnerability is detected in time, but nobody has been given written authority to declare that it is active exploitation and start the clock. It is worth setting out who takes that decision, who takes it if that person cannot be reached and at what exact moment the company is considered to have become aware.
Yes. The Cyber Resilience Act covers products with digital elements, a category that includes software placed on the market on its own. An application, a plug-in or a software tool distributed as a product is within it. Pure SaaS is generally outside it, except for remote data processing that forms part of a product. If it is sold under your brand, you are the manufacturer and reporting is your responsibility.
No. The Article 14 duty is limited to actively exploited vulnerabilities and severe incidents. A vulnerability found in an internal audit and fixed before anyone takes advantage of it is not reported, although it must be handled in line with the requirements that will apply from December 2027.
The 24-hour deadline runs just the same. The regulation does not provide for any suspension at weekends or on public holidays. That is why the escalation procedure must designate people who can be reached outside office hours and set out in writing who can send the early warning if the main person responsible is absent.
You can delegate the physical act of submitting it, but not the responsibility. The manufacturer answers to the authority. If the provider misses the deadline, the fine goes to the company that markets the product, so the contract should set internal deadlines shorter than those of the regulation.
Yes. Registration as an Assigned Representative comes first and cannot be sorted out on the day of the incident. The 24-hour deadline for the early warning starts running when the company becomes aware of the exploited vulnerability, regardless of whether it already has access to the portal. Companies with products with digital elements on the EU market should register now, not when the problem arises.
No. The notification is submitted once on the single platform and reaches the incident response team of the Member State where the company has its main establishment. That team shares it without delay with the other CSIRTs of the territories where the product is available, and ENISA receives it at the same time. The manufacturer does not repeat the process.
If you make products with digital elements available in the European Union and your reporting process is not yet in place, the obligation has applied to you since 11 September 2026. At Innovatech we help manufacturers and software companies set up the procedure, review contracts across the supply chain and respond once the clock has started. Tell us about your case and we will review it.
Marta Suárez-Mansilla is Managing Partner of Innovatech Legal and a Spanish lawyer (abogada), Madrid Bar (ICAM), working in technology law. She completed Harvard Law School's Copyright course and BerkeleyX's Blockchain programme, and has advised technology companies for more than eight years.