Cyber Resilience Act Article 14: reporting an exploited vulnerability

What already applies, and to what

Article 71(2) of Regulation (EU) 2024/2847 states that the Regulation applies from 11 December 2027, and then adds: however, Article 14 shall apply from 11 September 2026 and Chapter IV, Articles 35 to 51, shall apply from 11 June 2026.

Article 69(2) would ordinarily have limited the Regulation to products placed on the market after 11 December 2027, unless they undergo a substantial modification from that date. Article 69(3) removes that limit for the reporting duty specifically: by way of derogation from paragraph 2, the obligations laid down in Article 14 apply to all products with digital elements that fall within the scope of the Regulation and that have been placed on the market before 11 December 2027.

Scope comes from Article 2(1): the Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network. Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.

Article 2 also carves out several populations. Paragraph 2 excludes products covered by Regulation (EU) 2017/745 on medical devices, Regulation (EU) 2017/746 on in vitro diagnostics and Regulation (EU) 2019/2144 on vehicle type-approval. Paragraph 3 excludes products certified under Regulation (EU) 2018/1139 on civil aviation, paragraph 4 excludes marine equipment under Directive 2014/90/EU, paragraph 6 excludes spare parts manufactured to the same specifications as the components they replace, and paragraph 7 excludes products developed or modified exclusively for national security or defence purposes and products specifically designed to process classified information.

Who is a manufacturer

Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge.

Three phrases in that definition catch organizations that do not think of themselves as manufacturers. "Has products designed, developed or manufactured" reaches the company that outsources the entire build and puts its own badge on the result. "Software product" reaches a SaaS vendor's downloadable agent, its mobile app and its on-premises component. And "free of charge" reaches the open-source component you publish under your company name, and the firmware you give away with a device.

Two duties, two clocks

Article 14 contains two distinct reporting duties with separate triggers and separate chains. Article 14(1) and (2) cover an actively exploited vulnerability. Article 14(3) to (5) cover a severe incident having an impact on the security of the product. They share the first two marks and diverge at the third.

Track one: an actively exploited vulnerability

Article 3(42) defines an actively exploited vulnerability 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. The threshold is evidence of exploitation, not evidence of exploitability: a published proof of concept is not enough, and a researcher testing with permission is not enough either.

Article 14(2)(a) requires an early warning notification without undue delay and in any event within 24 hours of the manufacturer becoming aware of it, indicating where applicable the Member States on the territory of which the manufacturer is aware that its product has been made available.

Article 14(2)(b) requires a vulnerability notification, unless the relevant information has already been provided, without undue delay and in any event within 72 hours of becoming aware. It must provide general information, as available, about the product concerned, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken and any that users can take, and it must indicate, where applicable, how sensitive the manufacturer considers the notified information to be.

That sensitivity marking is worth attention. It is the manufacturer's own input into whether the notification is disseminated immediately across the Union or held back, and Article 16(2) reads it directly.

Article 14(2)(c) requires a final report, unless the relevant information has already been provided, no later than 14 days after a corrective or mitigating measure is available, containing at least a description of the vulnerability including its severity and impact; where available, information concerning any malicious actor that has exploited or is exploiting it; and details about the security update or other corrective measures made available to remedy it.

Track two: a severe incident affecting the product

Article 14(5) defines when an incident having an impact on the security of a product with digital elements is severe. It is severe where it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in the network and information systems of a user of the product.

The second limb is broad on purpose. A build-system compromise that could have put malicious code into a signed release is capable of leading to the execution of malicious code in a user's systems, whether or not a poisoned artefact ever shipped.

Article 14(4)(a) requires an early warning within 24 hours of becoming aware, including at least whether the incident is suspected of being caused by unlawful or malicious acts, and where applicable the Member States where the product has been made available. Article 14(4)(b) requires an incident notification within 72 hours, with general information about the nature of the incident, an initial assessment, corrective or mitigating measures taken and those users can take, and the sensitivity indication. Article 14(4)(c) requires a final report within one month of submitting that notification, containing at least a detailed description including severity and impact, the type of threat or root cause likely to have triggered it, and applied and ongoing mitigation measures.

That last list is word for word the NIS2 Article 23(4)(d) list. If you are also a NIS2 entity, the two final reports are close enough to be built from the same material, which is the only place in the four regimes where that is true.

One notification, two recipients, one platform

Article 14(1) and 14(3) both require the manufacturer to notify simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform established under Article 16. This is the only one of the four regimes whose first filing goes to two bodies at once, and it is not a courtesy copy: both are addressees.

Article 16(1) makes ENISA responsible for establishing the platform and for its day-to-day operation, with an architecture that allows Member States and ENISA to run their own electronic notification end-points. Article 16(2) then requires the coordinator CSIRT that received the notification to disseminate it, without delay, via the platform to the CSIRTs of every Member State where the manufacturer indicated the product had been made available. Article 16(3) requires the coordinator CSIRTs to give their national market surveillance authorities the notified information those authorities need to enforce the Regulation.

So a single submission fans out to every affected Member State's CSIRT and, from there, into market surveillance. That is a very different information flow from NIS2, where your report reaches one national CSIRT and travels further only through the single point of contact.

Which CSIRT is yours

Article 14(7) settles the recipient. The notification goes to the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union. Main establishment means the Member State where the decisions related to the cybersecurity of the products are predominantly taken; if that cannot be determined, the Member State where the manufacturer has the establishment with the highest number of employees in the Union.

Where the manufacturer has no main establishment in the Union, the third subparagraph of Article 14(7) sets an ordered fallback based on the information available to the manufacturer: the Member State of the authorised representative acting for the highest number of its products; failing that, the Member State of the importer placing the highest number on the market; failing that, the Member State of the distributor making the highest number available; failing that, the Member State where the highest number of users are located. In that last case the manufacturer may keep reporting subsequent vulnerabilities and incidents to the same CSIRT it first reported to.

Working that chain out during an active exploitation is not a good use of the first hour. It is a determination to make once, write down, and put at the top of the runbook.

Telling your users

Article 14(8) is a separate duty and it is easy to miss because it sits after the reporting chain. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform the impacted users of the product, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures they can deploy to mitigate the impact, where appropriate in a structured, machine-readable format that is easily automatically processable.

The machine-readable clause is the CRA quietly requiring an advisory feed rather than a blog post. And the paragraph ends with a sanction that is unusual in this field: where the manufacturer fails to inform users in a timely manner, the notified CSIRTs designated as coordinators may provide the information to users themselves, where they consider it proportionate and necessary. A slow disclosure can become someone else's disclosure.

Delaying dissemination, and coordinated disclosure

A vulnerability with no fix available is dangerous to publish, and the Regulation makes room for that. The second subparagraph of Article 16(2) allows dissemination to be delayed on justified cybersecurity-related grounds for a period that is strictly necessary, including where a vulnerability is subject to a coordinated vulnerability disclosure procedure under Article 12(1) of Directive (EU) 2022/2555. The CSIRT withholding a notification must immediately inform ENISA, with the justification and an indication of when it intends to disseminate.

The third subparagraph of Article 16(2) goes further in particularly exceptional circumstances. Where the manufacturer indicates in its 72-hour vulnerability notification that the vulnerability has been actively exploited in no other Member State than that of the receiving CSIRT, or that further dissemination would supply information whose disclosure would be contrary to that Member State's essential interests, or that dissemination poses an imminent high cybersecurity risk, ENISA initially receives only the fact that a notification was made, general product information, the general nature of the exploit and the fact that security grounds were raised. Where ENISA considers on that basis that there is a systemic risk to the internal market, it recommends that the recipient CSIRT disseminate the full notification.

Article 16(6) covers the coordinated disclosure case directly: where the coordinator CSIRT learned of the actively exploited vulnerability as part of a coordinated vulnerability disclosure procedure, it may delay dissemination on justified grounds until the parties to that procedure consent, and that requirement does not prevent a manufacturer from notifying voluntarily under Article 15.

Article 14(9) required the Commission to adopt, by 11 December 2025, delegated acts specifying the terms and conditions for applying those cybersecurity-related grounds.

What else is running

CRA Article 14 attaches to the product. It does not replace anything that attaches to you as an operator.

If you are also an essential or important entity, NIS2 Article 23 runs in parallel for the disruption to your own services, to your own national CSIRT, on its own chain. If you are a financial entity, DORA Article 19 runs instead of NIS2 for the operator side, on a four-hour clock from classification. And if personal data were affected at any point, GDPR Article 33 runs to the data protection supervisory authority regardless of everything else.

The legislator knew. A recital to the CRA records the complementary reporting requirements laid down in Regulation (EU) 2016/679, Regulation (EU) 2022/2554, Directive 2002/58/EC and Directive (EU) 2022/2555, and encourages Member States to consider providing national single entry points for such reporting, while noting that using them must not affect the independence of the data protection and ePrivacy authorities. Until those entry points exist, the stacking is yours to manage, and the reporting clock finder will lay the applicable chains out in order.