Cyber Resilience Act Article 14 Reporting Obligations: A Practical Guide for Manufacturers

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to EU authorities on timelines measured in hours. Drawing on Mustanir Ali's experience supporting manufacturers under the EU Radio Equipment Directive, this article covers the reporting triggers, staged timelines, severity thresholds, and CSIRT routing.

Drawing on Mustanir Ali's experience as Element's representative in developing the EN 18031 cybersecurity standards and his work supporting manufacturers under the EU Radio Equipment Directive, this article explains exactly what the Cyber Resilience Act Article 14 requires: the reporting triggers, the staged timelines, how to judge severity, and which national authority to report to.

Three Things Manufacturers Get Wrong About the CRA Reporting Obligations

Most coverage of the Cyber Resilience Act focuses on December 2027. That is the wrong deadline to be planning around if your concern is the reporting obligations. Before getting into what Article 14 requires, it is worth addressing the three assumptions that consistently trip manufacturers up.

The first is the deadline. The full CRA, covering conformity assessment, secure-by-design requirements, and the essential cybersecurity requirements, comes into force on 11 December 2027. Article 14 is different. The reporting obligations apply from 11 September 2026, more than a year earlier. Manufacturers who have been planning against 2027 are already closer to their first binding CRA obligation than they realize.

The second is scope. Most manufacturers assume the reporting obligations apply to new products they are bringing to market. They do not. They apply to products already on the EU market on the date the obligations take effect. They also continue beyond a product's designated support period, while it remains in use. A product that reached the end of support last year is still subject to Article 14 if it is still in use on the EU market.

The third is the most commonly misunderstood. When the reporting obligations come up in conversation, Mustanir Ali, Element's Head of Cyber Product Assurance, notes that manufacturers almost always ask the same follow-up question: Does this mean we need a full vulnerability handling process in place by September 2026? The answer is no. The CRA's vulnerability handling requirements, set out in Annex I, are not legally binding until 11 December 2027. Until then, the only legal requirement is to report actively exploited vulnerabilities and severe incidents. The reporting obligation and the vulnerability handling obligation are separate, on different timelines, and require different preparations.

What Is the Difference Between Article 13 and Article 14 of the CRA?

Article 13 of the CRA sets out the general obligations of manufacturers, including conformity assessment and technical documentation. Article 14 creates a specific, time-bound duty: to notify authorities when certain cybersecurity events occur. The practical distinction that matters most: Article 13 obligations apply from 11 December 2027. Article 14 reporting obligations apply from 11 September 2026. A manufacturer who is not yet fully CRA-compliant is still fully subject to Article 14 from September 2026. The reporting obligation does not wait for the vulnerability handling obligation to catch up.

What Triggers a Reporting Obligation Under CRA Article 14?

Article 14 creates reporting obligations for two distinct situations. The first is an actively exploited vulnerability: a vulnerability that a malicious actor has found and is using. Once a manufacturer becomes aware that their product is being actively exploited, the Article 14 clock starts. The second is a severe incident: any incident that negatively affects, or is capable of negatively affecting, a product's ability to protect sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code. The CRA borrows its definition of an incident from the NIS2 Directive. If neither condition is met, there is no Article 14 reporting obligation and the manufacturer follows its normal internal vulnerability handling process.

How to Determine Whether an Incident Is Severe

The severity definition turns on the phrase "capable of negatively affecting." In practice, this means exploitable.

"An easy test of severity is: is it exploitable? If it is exploitable in the particular context and implementation of the product, then it is severe, and if it's severe, it needs to be reported."
Mustanir Ali, Head of Cyber Product Assurance, Element

Many potential vulnerabilities exist in products without being exploitable in that product's specific context. A vulnerability in a third-party component may be severe in some deployments and irrelevant in others, depending on how the component is used, what interfaces are exposed, and what data the product handles. Once a vulnerability becomes exploitable in the specific context of the product, it meets the threshold and is therefore severe. Triggers for severity assessment include third-party vulnerability disclosures, internal pen testing, detection of attempted attacks, or misconfiguration events that reveal security implications.

The Article 14 Reporting Timelines

Article 14 sets staged timelines for both triggers. The timelines run from the point at which a manufacturer becomes aware of the issue. For an actively exploited vulnerability:

• Within 24 hours: submit an early warning notification to ENISA and/or the relevant national CSIRT (Computer Security Incident Response Team).
• Within 72 hours: submit a vulnerability notification with a description and details of corrective and mitigating measures taken or available.
• Within 14 days: submit a final report describing the vulnerability, any malicious actors involved, how it can be corrected, and what mitigating measures are in place.

For a severe incident, the first two steps are identical, but the final report extends to one month, covering the incident, its root cause, and the mitigating measures taken. These timelines require the reporting process to be in place before an incident occurs, not figured out afterwards.

The ENISA Single Reporting Platform: A Practical Problem

Article 16 of the CRA requires ENISA to establish a single reporting platform giving each EU member state CSIRT its own electronic notification endpoint. A manufacturer reports to one CSIRT; that CSIRT circulates the report to ENISA and other relevant CSIRTs. There is a practical problem most Article 14 explainers skip over. At the time of writing, the platform is not yet live. ENISA has confirmed it will be operational by 11 September 2026 and has indicated a testing period will take place before that date. Registration instructions and dry-run support materials were expected from ENISA in June 2026. Manufacturers should monitor the ENISA Single Reporting Platform page now and register as soon as access opens, given that the 24-hour reporting clock does not stop for onboarding. Manufacturers should monitor the CSIRTs Network for updates on platform availability and identify their relevant CSIRT now, so the routing decision is already made when the platform launches.

Which CSIRT to Report To

For EU-established manufacturers, the relevant CSIRT is in the member state where cybersecurity decisions for the manufacturer's products are predominantly made, not necessarily the largest site. If indeterminate, it defaults to the member state with the most employees in the Union.

For manufacturers with no EU presence, the obligation still applies. Placing products on the EU market is sufficient to bring Article 14 into effect. The CSIRT is determined in the following order:

• The member state of the authorized representative, if one has been appointed.
• Otherwise, the member state of the importer placing the highest number of products on the EU market.
• Otherwise, the member state of the distributor placing the most products on the market.
• Otherwise, the member state with the highest number of users of the product.

The final point is particularly relevant for legacy products no longer being actively placed on the market. Article 14 obligations continue while they remain in use. For many legacy portfolios, user distribution data is the only basis for making the CSIRT determination.

How Vulnerability Handling Connects to Article 14 in Practice

Even though the Annex I vulnerability handling requirements are not legally binding until December 2027, there is a practical reason to build toward them before September 2026. A manufacturer cannot report what it cannot detect. Having a means of discovering vulnerabilities, whether through an SBOM, regular security testing, a third-party disclosure channel, or component supplier notifications, is what makes Article 14 compliance operationally possible. Without that detection process, a manufacturer may be in breach of Article 14 not because they failed to report, but because they never knew there was something to report. For a full explanation of the Annex I requirements and how to build toward them, see our EU Cyber Resilience Act compliance webinar.

What Manufacturers Should Put in Place Before September 2026

The September 2026 deadline requires preparation that cannot start on the day. There are four steps to address before the obligations take effect.

First, identify your portfolio scope. Determine which products are subject to Article 14, including legacy products already on the market and products beyond their support period. For manufacturers with no EU presence, identify the importer or distributor placing the highest number on the market, or map your user base by member state.

Second, identify the relevant CSIRT. Use the CSIRTs Network now so the routing decision is made before the platform goes live. Understand the submission requirements for that CSIRT before an incident occurs.

Third, define your severity threshold. Agree internally on how you will apply the exploitability test. Document which product contexts, interfaces, and data types would make a given vulnerability exploitable, and therefore severe, for each product category.

Fourth, build a detection and response process capable of a 24-hour early warning response. It does not need to be fully Annex I-compliant by September 2026, but it must be functional: monitoring, disclosure channels, and a triage process that can assess severity quickly.

Article 14 is the CRA's most immediate obligation. It applies from 11 September 2026 to all products with digital elements on the EU market, runs on timelines that leave no room for improvisation, and the platform manufacturers will use to submit reports is not yet live. Three points matter above all others: September 2026 is not a future-product problem, it is a current-portfolio problem; reporting and vulnerability handling are separate obligations on separate timelines; and a manufacturer cannot report what it cannot detect.

To watch Mustanir Ali walk through the Article 14 obligations in detail, see our Cyber Resilience Act reporting obligations on-demand webinar. For the full CRA picture, including conformity assessment, secure-by-design requirements, and the December 2027 deadline, watch our EU Cyber Resilience Act compliance webinar. To discuss what Article 14 means for your specific product portfolio, speak to Element's cybersecurity team using the form below.

 

Frequently Asked Questions

Q1: What does NOT trigger a CRA Article 14 reporting obligation?

Not every vulnerability or security event triggers an Article 14 reporting obligation. A vulnerability you discover and fix before it is exploited does not need to be reported through the CRA Single Reporting Platform. Routine security patches, precautionary updates, and vulnerabilities that are not actively being exploited fall outside the Article 14 scope. The obligation applies only when a malicious actor is actively using a vulnerability against a product, or when an incident meets the severity threshold of being capable of negatively affecting a product's ability to protect sensitive data or functions. For a detailed explanation of how to apply the severity test, read Element’s Cyber Resilience Act Article 14 reporting obligations guide.

Q2: What are the Cyber Resilience Act reporting obligations for manufacturers?

From 11 September 2026, the Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT. Reports follow a staged timeline: an early warning within 24 hours of becoming aware, a technical notification within 72 hours, and a final report within 14 days for actively exploited vulnerabilities or within one month for severe incidents. These obligations apply to all products already on the EU market, not only new products placed after the deadline. For a full walkthrough of the requirements, watch Element’s Cyber Resilience Act compliance webinar.

Q3: What is the difference between Article 13 and Article 14 of the Cyber Resilience Act?

Article 13 sets out the general manufacturer obligations under the CRA, including conformity assessment, technical documentation, and CE marking. These apply from 11 December 2027. Article 14 creates a specific, time-bound duty to report certain cybersecurity events to authorities. This applies from 11 September 2026. A manufacturer that is not yet fully CRA-compliant under Article 13 is still fully subject to Article 14 from September 2026. The two obligations run on different timelines and require separate preparation. For a full overview of both, watch Element’s EU CRA compliance webinar.

Q4: Do the Cyber Resilience Act reporting obligations apply to products already on the market?

Yes. The reporting obligations under Article 14 apply from 11 September 2026 to all products with digital elements available on the EU market, including those placed there before that date. A product that reached the end of its support period is still subject to Article 14 obligations while it remains in use. This is one of the most commonly misunderstood aspects of the regulation. Manufacturers should audit their full product portfolio, including legacy products, before September 2026. Element’s IoT cybersecurity testing and certification team can help you assess your portfolio scope ahead of the deadline.

Q5: How do I prepare for the Cyber Resilience Act reporting obligations before September 2026?

Preparation requires four steps before the deadline. First, identify which products in your portfolio are in scope, including legacy products already on the market. Second, identify the relevant national CSIRT for your products using the CSIRTs Network. Third, define your internal severity threshold so you can triage quickly when an issue occurs. Fourth, build a detection and response process capable of issuing an early warning within 24 hours. 

To watch Mustanir Ali cover these steps in full, see Element's Cyber Resilience Act Article 14 reporting obligations webinar.