Cyber Resilience Act reporting is now mandatory: what has changed and what to do this quarter

By Kike Gandia · Hardware & OT · 9 min read

Illustration on a midnight-blue background: a chip with a vulnerability marked in red, a stopwatch with the first 24 hours highlighted in orange and the report travelling to a green envelope, with three deadlines on the timeline

On September 11, 2026, Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, became applicable. That same day ENISA deployed the initial operating capability of its Single Reporting Platform (SRP). Since then, a manufacturer of products with digital elements that becomes aware that a vulnerability in its product is being actively exploited, or of a severe incident affecting its security, has to report it within hours.

The question is no longer whether to report, but how reporting works in practice. The FAQ ENISA published alongside the platform answers several questions that were settled by guesswork before launch, and in at least one case the official answer runs against what was being recommended.

What has been mandatory since September 11. Reporting actively exploited vulnerabilities and severe incidents affecting the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA, through the Single Reporting Platform. It also covers products already on the market.

24h: early warning (from becoming aware)
72h: notification (from becoming aware)
14 days: final vulnerability report (from when a corrective measure exists)
1 month: final severe incident report (from the 72h notification)

What has happened and what is still ahead

December 11, 2025 — Delegated act on dissemination
The Commission adopts Delegated Regulation (EU) 2026/881, which sets the exceptional conditions under which a CSIRT may delay, on cybersecurity grounds, the dissemination of a notification to other CSIRTs.
September 10, 2026 — List of coordinating CSIRTs
ENISA publishes the list of CSIRTs designated as coordinators. For Spain, the entry points to INCIBE-CERT's incident response and CVE assignment and publication pages.
September 11, 2026 — Article 14 applies and the platform opens
The reporting obligation starts and the SRP goes live. In this first phase it only accepts the mandatory Article 14 notifications.
December 11, 2027 — Full application
Every requirement of the regulation becomes enforceable, and the reporting obligations of open-source software stewards under Article 24(3) apply.

What you have to report, and what you don't

Article 14 does not require you to report every vulnerability: only those being actively exploited, plus severe incidents. An incident is severe when it affects, or is capable of affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the user's systems (Article 14(5)).

Situation	Do you have to report?	Nuance
Actively exploited vulnerability in your product	Yes: 24h, 72h and 14 days	The final report runs from when a corrective or mitigating measure is available, not from awareness
Severe incident affecting the security of the product	Yes: 24h, 72h and one month	The final report runs from the 72-hour notification
Vulnerability with no sign of exploitation	Not under Article 14	It still has to be fixed; voluntary reporting under Article 15 is not yet available on the platform
Exploitation you already knew about before September 11, 2026	Not retroactively	If you become aware of the exploitation after that date, yes, even if the vulnerability was known earlier
Product placed on the market before December 2027	Yes	The reporting obligation covers the whole catalog within the regulation's scope, with no exemption for age

Each submission has a different minimum content. For a vulnerability, the early warning states the Member States where you know the product has been made available; the notification adds general information about the product, the general nature of the exploit and the vulnerability, and the corrective measures taken and those users can take; and the final report describes the vulnerability with its severity and impact, any available information on the malicious actor, and the details of the security update. For a severe incident the sequence runs in parallel: whether an unlawful or malicious act is suspected, an initial assessment and, at the end, the root cause and the mitigation measures applied and ongoing.

A separate obligation: informing users. Article 14(8) also requires you to inform the impacted users, and where appropriate all users, about the vulnerability or incident and the measures they can take. Reporting to the CSIRT does not discharge this obligation.

The platform's fine print

These are the answers in ENISA's FAQ that most affect how a team organizes itself to report:

Once One notification per event: Even if the manufacturer has several subsidiaries in the EU or a parent company outside it, each exploited vulnerability or severe incident is reported once. Coordinating internally so reports are not duplicated is the manufacturer's responsibility.
CSIRT Picking the wrong CSIRT invalidates the report: The recipient is the coordinating CSIRT of the Member State of the main establishment, where cybersecurity decisions about the products are predominantly taken. If that cannot be determined, the Member State with the most employees in the EU applies. If you pick the wrong CSIRT, the notification may be invalidated and have to be resubmitted.
72h The platform's counter runs early: In the current release, the 72-hour counter shows the due time 48 hours after the early warning is submitted, because it counts from that submission rather than from awareness. A notification can show as overdue before it is: the clock that counts is yours.
Manual Browser only, English only: The platform has no API in this phase and is available in English only. Voluntary reporting under Article 15 and a possible API will come in later phases.
Sign-up Register when you need to report: ENISA advises registering and starting validation only when you need to submit a notification. With an EU Login account with two-factor authentication already in place, registration takes a few minutes, and the CSIRT's validation runs in parallel: in the meantime you can submit up to twenty notifications for that manufacturer.
Non-EU No establishment in the EU: The CSIRT is determined in this order: that of the Member State of the authorized representative, then the importer, then the distributor and, as a last resort, the Member State with the most users of the product.

Advice worth revisiting. Before launch, the standard advice was to register on the platform in advance. The official recommendation is the opposite: registration takes minutes when you need it. What cannot be improvised on the day of the incident is everything else: EU Login accounts with two-factor authentication for the people who will file, the coordinating CSIRT identified, and the product data at hand.

Spain: who receives your report

For a manufacturer whose main establishment is in Spain, the coordinating CSIRT is INCIBE-CERT: Spain's entry on the ENISA list points to its incident response and vulnerability coordination pages. The notification does not go through the usual national channels but through the ENISA platform, which delivers it simultaneously to the CSIRT and to the agency.

The other half of the picture, the market surveillance authority, is still pending. In December 2025 Spain's Secretariat of State for Telecommunications and Digital Infrastructure opened a public consultation on the rule that will designate the CRA authorities, proposing that it take on market surveillance itself, that the National Cryptologic Center (CCN) act as notifying authority, and that INCIBE serve as technical laboratory, without public powers. As of this article we have not found that rule published in the BOE (Spain's Official State Gazette). That suspends nothing: the regulation is directly applicable and the reporting obligation is already enforceable. The details are in the CRA guide for manufacturers.

What to do this quarter

1 — Identify the recipient and the owners
Determine your coordinating CSIRT based on your main establishment and decide who files. Those people need an EU Login account with two-factor authentication before anything happens.
2 — Define what "becoming aware" means
It is the event that starts the clock and the one you will have to prove. Put in writing who decides that a vulnerability is actively exploited and on what criteria: incoming reports, CSIRT advisories, public catalogs of exploited vulnerabilities or your own telemetry.
3 — Set up two timers
The final report for a vulnerability runs from when the corrective measure exists; for a severe incident, from the 72-hour notification. Track them outside the platform, which currently calculates the 72-hour deadline from the early warning.
4 — Keep the intake channel open
Without a channel for receiving vulnerability reports (security.txt, a security contact form or a disclosure program), you will find out late, or from someone else.
5 — Prepare the user communication
A template for the Article 14(8) information, with who approves it and which channel it goes out through, so you are not drafting it with the clock running.
6 — Inventory what is already on the market
The obligation reaches old and discontinued products. You need to know which product lines are still in customers' hands and who can prepare a fix for each one.
7 — Rehearse it
A tabletop exercise with a fictitious exploited vulnerability shows in a single morning where the first twenty-four hours get lost.

What comes next

The next milestone is December 11, 2027, when the regulation applies in full. In parallel, the Digital Omnibus proposal the Commission tabled on November 19, 2025 includes a single reporting point for cybersecurity and data incidents. It is still a proposal: according to the European Parliament's tracker, updated September 20, 2026, the Council vote on its negotiating mandate scheduled for June 26 was canceled, and Parliament's draft report has drawn more than 1,750 amendments. Don't design your reporting process around it.

If you want to place your product before working on the process, the interactive CRA classifier tells you which category it falls into, and the CRA scoping form sizes the work. The full CRA timeline is in the Cyber Resilience Act timeline, the rest of EU digital regulation in the EU compliance calendar, and if you want us to build it with you, see our CRA compliance consulting.

Topics

#Cyber-Resilience-Act #CRA #ENISA #Vulnerability-reporting #INCIBE-CERT #Compliance

Keep reading

Sources

Size your compliance work with the CRA scoping form