EU Cyber Resilience Act Reporting Requirements: Article 14 and the SRP

Julian Meroi · Published 6 October 2026 · Last reviewed 6 October 2026

Who must report, and from when?

Manufacturers of products within the CRA’s scope must comply with Article 14 from September 11, 2026. This includes products placed on the market before December 11, 2027. Article 69(3) expressly applies the reporting obligations to these earlier products. A product’s scope and the manufacturer’s role must therefore be established before applying this procedure. Article 71(2), Article 69(3), Article 2.

The obligation is triggered by awareness. According to the Commission guidance, a manufacturer that was already aware of active exploitation before September 11, 2026 is not required to report it retroactively. Where it becomes aware of active exploitation on or after that date, the obligation applies, even if the vulnerability itself was known earlier. Reporting also continues after a product’s support period has ended. The vulnerability-handling requirements of Annex I, Part II apply generally from December 11, 2027. They do not apply to products placed on the market before that date unless those products are substantially modified from that date, and they end with the product’s support period. Article 69(2), Commission guidance, ¶¶210 and 217, ENISA SRP FAQ, §13.

This guide addresses manufacturers. Open-source software stewards have a separate reporting provision in Article 24(3), applicable from December 11, 2027. An organization should assess its role for the relevant activity. Article 24(3), Article 71(2).

Which events trigger Cyber Resilience Act reporting?

Actively exploited vulnerabilities

Article 3(42) requires reliable evidence of exploitation by a malicious actor in a system without the owner’s permission. Article 14(1) requires the manufacturer to notify an actively exploited vulnerability contained in its product when it becomes aware of it. A vulnerability score, the existence of a CVE or the absence of a patch does not, by itself, establish this definition. Article 3(42), Article 14(1).

The Commission services’ FAQ §5.2 explains that a zero-day finding from good-faith testing, without evidence of malicious exploitation, does not trigger mandatory vulnerability reporting on that basis. Assess the facts against the legal definition. Commission FAQ, §5.2.

For integrated components, the Commission guidance ¶218 addresses whether the vulnerability is contained in, and has been exploited in, the manufacturer’s product. It distinguishes cases where the component vulnerability cannot be exploited in that product or has not been exploited in it. Record that assessment against the affected product and version; do not treat a supplier advisory alone as proof of exploitation in every downstream product. A component vulnerability that is not reportable for that manufacturer can still be notified voluntarily under Article 15. From December 11, 2027, for products within the scope of those obligations, Article 13(6) also requires the manufacturer to report a vulnerability identified in an integrated component to the person or entity manufacturing or maintaining it, and to address it under Annex I, Part II. Where an actively exploited vulnerability originates in a component that was itself placed on the market, the component’s manufacturer must also notify it. Commission guidance, ¶218, Commission FAQ, §5.4, Article 13(6).

Severe incidents affecting product security

Article 14(5) provides two alternative severity criteria. An incident is severe if it:

• negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
• has led, or is capable of leading, to malicious code being introduced or executed in the product or a user’s network and information systems.

The criteria include potential effects. A reporting assessment should consider both limbs. Article 14(3) and (5).

Reporting deadlines and required information

When does the manufacturer become aware?

The early warning and the 72-hour notification run from awareness. The final reports have their own triggers: the availability of a corrective or mitigating measure for a vulnerability, and the submission of the incident notification for a severe incident. The Commission guidance treats a manufacturer as aware when, after an initial assessment of a suspicious event or a third-party report, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has compromised its product’s security. The guidance expects that initial assessment to be carried out immediately and promptly, particularly where the risk may be significant. Recording when an event was first detected and when the assessment concluded documents how the awareness time was determined. Commission guidance, ¶¶211-214.

Both the early warning and the subsequent notification must be submitted without undue delay. The 24-hour and 72-hour periods are outer limits measured from awareness of the relevant event. The second period does not start when the early warning is submitted. Article 14(2)(a)-(b) and (4)(a)-(b).

The subsequent notification and final report are required unless the relevant information has already been provided. The vulnerability final report must include the vulnerability’s description, severity and impact; available information about the malicious actor; and details of the security update or other corrective measures made available. The incident final report must include a detailed description, severity and impact, the likely threat or root cause, and applied and ongoing mitigation measures. The receiving coordinating CSIRT may request an intermediate status report where necessary. Article 14(2), (4) and (6).

A mitigating measure can start the vulnerability final-report period before a permanent patch is ready. The incident deadline is one month, not a universal 30-day interval. These follow from the wording of Article 14(2)(c) and (4)(c).

Which authority receives the report?

Submit through the CRA Single Reporting Platform, using the appropriate coordinating CSIRT’s electronic endpoint. Article 14 requires notification simultaneously to that CSIRT and ENISA; Article 16 establishes the platform. Article 16(2) provides exceptional restrictions on dissemination. Those provisions concern sharing of the notification and do not provide a general extension of the manufacturer’s Article 14 submission deadlines. Article 14(1), (3), (7), Article 16.

For a manufacturer with a main establishment in the Union, use its Member State. Article 14(7) defines this through the predominant location of product cybersecurity decisions; if that Member State cannot be determined, it uses the Union establishment with the highest employee count.

For a manufacturer without a main establishment in the Union, apply the following order, using the information available to it:

1. The Member State of the authorized representative acting for the highest number of its products.
2. The Member State of the importer placing the highest number of its products on the market.
3. The Member State of the distributor making the highest number of its products available.
4. The Member State with the highest number of its product users.

Under the fourth criterion, subsequent notifications may go to the same coordinating CSIRT as the first report. Article 14(7).

The manufacturer selects the coordinating CSIRT in the platform. ENISA warns that a notification submitted to the wrong CSIRT may be invalidated and need to be resubmitted to the correct one, so record the routing assessment before an event occurs. ENISA SRP FAQ, §18.

Prepare platform access and keep a separate deadline record

Operational details checked October 6, 2026 against ENISA’s FAQ updated October 3:

• Assigned Representatives use personal EU Login accounts with MFA. ENISA advises initiating SRP registration when a notification is needed; EU Login can be prepared beforehand (§9).
• A manufacturer has one Primary Assigned Representative and up to 20 Secondary ones. Any of them can continue a submitted notification, but drafts stay visible only to their author. CSIRT validation of the association runs in parallel with reporting; an unverified association can submit up to 20 notifications before verification becomes mandatory (§9).
• The platform’s Assigned Representative role is distinct from an Article 18 authorized representative.
• The 72-hour counter currently uses early-warning submission plus 48 hours. Calculate the legal deadline from awareness (§26).
• During an outage, ENISA advises submitting when service returns; direct CSIRT contact, if necessary meanwhile, does not replace SRP submission (§25).
• Voluntary Article 15 reporting is not yet implemented in the platform (§27).

These platform instructions do not amend Article 14. ENISA SRP FAQ, §§9, 25-27, Article 18.

Inform affected users

Reporting to authorities and informing users are separate obligations. Article 14(8) requires the manufacturer to inform impacted users and, where appropriate, all users, about the vulnerability or incident and, where necessary, risk mitigation and corrective measures users can deploy. It also addresses structured, machine-readable information where appropriate. This paragraph does not specify a universal 24-hour user-notification deadline. If the manufacturer does not inform users in a timely manner, the notified CSIRTs may inform them where proportionate and necessary. Article 14(8).

According to the Commission guidance, informing users is risk-based and does not require public or indiscriminate disclosure. Detailed information can be limited to the users or customers concerned, particularly where public technical detail could facilitate exploitation. Separately, from December 11, 2027, for products within its scope, Annex I, Part II, point (4) requires manufacturers to publicly disclose information about fixed vulnerabilities once a security update has been made available. In duly justified cases, where the security risks of publication outweigh the benefits, they may delay public disclosure until users have had the possibility to apply the patch. Commission guidance, ¶¶220-221, Annex I, Part II.

Example implementation: an internal reporting record

The following is an example of implementation based on Article 14 and the Commission FAQ §5.1. This internal record format and its field names are not mandated by the CRA. The information legally required in a notification remains governed by Article 14.

The Commission FAQ §5.1 gives examples of awareness channels. It does not make monitoring every listed channel an Article 14 requirement. An internal approval process should support timely submission. Commission FAQ, §5.1.

Worked timing example

Assume a manufacturer becomes aware of an actively exploited vulnerability on October 6 at 10:00 UTC. Conservative internal targets, counted directly from that moment, are October 7 at 10:00 UTC for the early warning and October 9 at 10:00 UTC for the vulnerability notification. Both must still be submitted without undue delay. If a mitigating measure becomes available on October 8 at 10:00 UTC, the internal target for the final report is October 22 at 10:00 UTC, because that period runs from the measure’s availability rather than from awareness. Do not plan on weekends or public holidays pausing the 24-hour and 72-hour periods. This example applies Article 14(2); the record format and workflow are implementation suggestions.

Implementation support

Meroi Security can help define reporting responsibilities, prepare an escalation procedure and test it against a product-security scenario. Explore our Cyber Resilience Act compliance services or read Article 14 and its practitioner notes.

For a recorded walkthrough of what to report, when and where, watch our CRA reporting obligations webinar from February 2026. It was recorded before the obligations applied; this guide reflects the Commission and ENISA guidance current on its review date.