CRA Reporting Obligations: Article 14 Deadlines and Process

Since September 11, 2026, Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, has required manufacturers to report two kinds of events: actively exploited vulnerabilities in their products with digital elements, and severe incidents having an impact on the security of those products. Each report goes through ENISA's single reporting platform to the CSIRT designated as coordinator, normally in the Member State of the manufacturer's main EU establishment, and to ENISA at the same time. The manufacturer owes an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available for a vulnerability, or within one month after the notification for an incident. It must also inform impacted users. The duty covers products placed on the market before the CRA's main obligations apply on December 11, 2027.

What must manufacturers report under CRA Article 14?

Article 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of." Article 14(3) does the same for any severe incident having an impact on the security of the product. Both go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform that Article 16 tasks ENISA with running. The Commission's CRA reporting page sets out the same clocks.

Article 14(7) fixes the recipient. A manufacturer notifies the coordinating CSIRT of the Member State where it has its main establishment in the EU, meaning where decisions on the cybersecurity of its products are mainly taken, or failing that the EU establishment with the most employees. A manufacturer with no EU establishment works down a fixed order: the Member State of the authorised representative acting for the most of its products, then the importer, then the distributor, and finally the Member State with the most users of its products. The coordinating CSIRT passes the notification to the CSIRTs of every Member State where the product is available (Article 16(2)) and may delay that only on cybersecurity grounds, under terms set by Delegated Regulation (EU) 2026/881, adopted December 11, 2025 and published April 20, 2026.

Article 14 sits in the top penalty tier of Article 64: up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher. Article 64(10) spares microenterprises and small enterprises from fines for missing the 24-hour early warning deadline; the obligation itself, and fines for breaching the later stages, still apply to them.

How does CRA reporting compare with NIS2, GDPR, and SEC rules?

A single event can trigger several regimes, each with its own trigger, recipient, and clock. A manufacturer that is also an essential or important entity under NIS2, processes personal data, and files with the US Securities and Exchange Commission can owe four reports on one breach.

The CRA clock is the only one in that table that runs from awareness of a vulnerability being exploited, even when no incident at the manufacturer has occurred. The SEC rule, adopted in July 2023 and summarized in the SEC's announcement, runs from the materiality decision, which is why manufacturers that file with the SEC need the CRA decision and the materiality decision recorded separately.

What counts as an actively exploited vulnerability?

Article 3(42) defines it 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." Three elements decide the question: reliable evidence, a malicious actor, and use against a system without the owner's permission. The definition does not limit the system to one that belongs to the manufacturer or its customers. Recital 68 adds that vulnerabilities discovered with no malicious intent, for good faith testing, investigation, correction, or disclosure, should not be subject to mandatory notification, so a finding from your own penetration test or a researcher's report does not start the clock on its own.

CISA's Known Exploited Vulnerabilities catalog uses a close cousin of that test: it lists a vulnerability only with reliable evidence of active exploitation, and it states that scanning, security research, and proof-of-concept code do not count. A KEV entry for a CVE contained in your product is therefore a strong signal, and it should put a triage decision in front of your product security team the same day.

Article 14(1) covers any actively exploited vulnerability "contained in the product," and the text makes no exception for third-party components. On that text, an exploited library inside your product is your report to make, and Article 13(6) separately requires you to tell the person or entity maintaining the component. A current software bill of materials is what lets a team answer within hours which products contain the exploited component, which is why our guide to SBOM requirements matters for reporting as much as for compliance.

What is a severe incident under the CRA?

Article 14(5) treats an incident as severe in two cases: it negatively affects, or could negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or it has led, or could lead, to malicious code being introduced or executed in the product or in a user's network and information systems. Article 3(44) defines the broader class of incidents having an impact on the security of the product.

Recital 68 gives the clearest example: an incident that compromises the manufacturer's development, production, or maintenance processes, such as an attacker introducing malicious code into the release channel that delivers security updates. A stolen code-signing key or a tampered build server deserves the same triage, because either could let an attacker put malicious code on users' devices, which is the second limb of Article 14(5). The reporting process therefore has to watch the build and release environment as closely as the product in the field.

When does a manufacturer become aware?

The CRA does not define the moment of awareness, and the 24-hour and 72-hour deadlines run from it. The Commission addresses the reporting obligations in Section 9.1 of its July 2026 guidance on applying the CRA and in Section 5 of its implementation FAQ, and your counsel should read both before you write the trigger into your procedure. Whatever trigger you adopt, record four timestamps for every candidate event: the first signal, the start of triage, the point at which the evidence met the definition, and the submission. ENISA's platform asks for fewer fields at the early warning stage and adds detail at later stages, so the early warning should carry what is known at 24 hours instead of waiting for certainty.

What goes in each CRA report?

For a vulnerability, the early warning names the Member States where the manufacturer knows the product is available. The 72-hour notification adds general product information, the nature of the exploit and of the vulnerability, the corrective or mitigating measures taken and those users can take, and how sensitive the manufacturer considers the information. The final report describes the vulnerability with its severity and impact, the malicious actor where known, and the security update or other corrective measure made available.

For a severe incident, the early warning states at least whether unlawful or malicious acts are suspected. The 72-hour notification covers the nature of the incident, an initial assessment, and the measures taken and available to users, and the final report, due one month after the notification, gives a detailed description, the likely threat type or root cause, and the mitigation applied and ongoing. On either track, the coordinating CSIRT may request an intermediate report on status updates (Article 14(6)).

Article 14(8) adds a duty to inform impacted users, and all users where appropriate, about the vulnerability or incident and the risk mitigation and corrective measures they can take, in a structured, machine-readable format that is easily automatically processable where appropriate. If the manufacturer does not do so in time, the notified CSIRTs may inform users themselves where they consider it proportionate and necessary.

Which products and manufacturers does the reporting duty cover?

Article 69(3) applies Article 14 to every product with digital elements within the CRA's scope that was placed on the market before December 11, 2027, without the substantial modification condition that governs the rest of the regulation. A device placed on the market in 2023 is therefore inside the reporting duty today. Our explainer on the Cyber Resilience Act covers the scope test and the exclusions that decide which products are in scope at all.

Importers and distributors do not report under Article 14, but Articles 19 and 20 require them to tell the manufacturer about a vulnerability without undue delay and to inform market surveillance authorities immediately when a product presents a significant cybersecurity risk. Open-source software stewards report only to the extent they are involved in developing the products concerned, and ENISA states that their reporting obligations under Article 24(3) apply from December 11, 2027. Article 15 lets manufacturers and anyone else report vulnerabilities, cyber threats, incidents, and near misses voluntarily, and when someone other than the manufacturer reports an actively exploited vulnerability or severe incident, the coordinating CSIRT must inform the manufacturer without undue delay.

How does ENISA's single reporting platform work?

ENISA launched the single reporting platform on September 11, 2026 at initial operating capability. According to ENISA's platform FAQ (updated September 17, 2026), access runs through named individuals called assigned representatives, each signing in with a personal EU Login account protected by multi-factor authentication. One primary representative registers the manufacturer, selects the coordinating CSIRT, and can invite up to 20 secondary representatives once the association is verified, and the CSIRT runs that verification while the first notifications can already be submitted. The manufacturer selects the coordinating CSIRT itself, and ENISA warns that a wrong choice can invalidate the notification.

At launch the platform accepted only mandatory reports from manufacturers, in English, through a web interface with no API, and voluntary reporting under Article 15 is planned for a later phase. ENISA asks manufacturers to register only when they need to notify, so the preparation happens offline: decide who your representatives are, make sure they have EU Login accounts with multi-factor authentication, document your main establishment and coordinating CSIRT, and map your templates to the platform's fields. If the platform is down, ENISA's FAQ says to submit once it is back and allows contacting the CSIRT directly in the meantime, but the notification must still be filed through the platform.

How do you build a CRA reporting process?

The 24-hour clock leaves no time to design a process during an event. If you already run a product security incident response team (PSIRT), a vulnerability management program, and an incident response plan, the work is connecting them to the Article 14 definitions and the platform. A process that holds up has these parts.

• One intake for vulnerability reports and exploitation signals, tied to the single point of contact in Article 13(17) and the coordinated vulnerability disclosure policy in Annex I, Part II, and watched every day of the year.
• Defined evidence sources for exploitation: threat intelligence feeds, honeypots, customer and incident response reports, researcher reports, and the KEV catalog, each with an owner.
• Triage against Article 3(42) and Article 14(5) with a written decision record: evidence, decision, decision-maker, and the four timestamps.
• Draft templates for each stage on both tracks, written to the platform's fields and approved in advance by legal and communications.
• A 24-hour on-call owner with authority to submit, backed by registered platform representatives and a documented coordinating CSIRT.
• Rules for embargoes in coordinated disclosure, including when to ask the CSIRT to delay dissemination under Article 16.
• Supplier contracts that require component vendors to tell you about exploitation fast, and SBOMs that find affected products in hours.
• A user advisory process that meets Article 14(8), with machine-readable advisories where appropriate.

Feed the same intake into your vulnerability management program, so the emergency path for an exploited vulnerability and the report to the CSIRT start from the same ticket. Then rehearse it: a timed exercise that runs an exploited component through triage, the early warning, and the user advisory shows whether the 24-hour clock can be met before a real event tests it.

How BD Emerson helps with CRA reporting readiness

BD Emerson's Cyber Resilience Act compliance team builds Article 14 reporting readiness with product security, engineering, and legal staff: we map the definitions into PSIRT triage criteria and decision records, write the templates for both tracks, document the main establishment and coordinating CSIRT, plan platform access, and connect the process to your SBOMs and vulnerability management. We then test it in tabletop exercises built on realistic product scenarios, such as an exploited third-party library or a compromised update server, and our incident response team supports the investigation behind a severe incident. Whether a specific event meets the Article 14 definitions, and what a report says, are decisions for your counsel, and we can work at their direction.

Frequently asked questions

Who do manufacturers report to under the CRA? Manufacturers report through ENISA's single reporting platform to the CSIRT designated as coordinator in the Member State of their main EU establishment, and ENISA receives the notification at the same time. A manufacturer with no EU establishment uses the Member State of its authorised representative, then its importer, then its distributor, and finally the Member State with the most users of its products. The coordinating CSIRT shares the notification with the CSIRTs where the product is available.

Do vulnerabilities found in penetration tests or bug bounty programs have to be reported under the CRA? A vulnerability found in a penetration test or a bug bounty program does not, by itself, trigger a CRA report. Article 14 applies to actively exploited vulnerabilities, which require reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission. Recital 68 says vulnerabilities discovered for good faith testing, investigation, correction, or disclosure should not be subject to mandatory notification. They still belong in your Annex I, Part II vulnerability handling.

Does CRA reporting apply to products sold before December 2027? Article 69(3) applies the Article 14 reporting duty to every product with digital elements within the CRA's scope that was placed on the market before December 11, 2027. The substantial modification condition that limits the rest of the regulation for older products does not apply to reporting, so legacy products have been covered since September 11, 2026.

What happens if a manufacturer misses the 24-hour CRA deadline? Article 64 places breaches of Article 14 in the top fine tier: up to EUR 15 million or 2.5 percent of total worldwide annual turnover, whichever is higher, with the amount set according to factors such as the nature, gravity, and duration of the breach. Article 64(10) exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline, although the obligation itself still applies to them.

Do manufacturers have to report exploited vulnerabilities in open-source components? Article 14(1) covers any actively exploited vulnerability contained in the product, and the text makes no exception for third-party or open-source components, so the manufacturer of the product reports it. Article 13(6) also requires the manufacturer to report the vulnerability to the person or entity maintaining the component. Open-source software stewards have their own limited reporting duty under Article 24, which ENISA says applies from December 11, 2027.

Can anyone report a vulnerability voluntarily under the CRA? Article 15 lets manufacturers and any other person report vulnerabilities, cyber threats, incidents, and near misses voluntarily to a CSIRT designated as coordinator or to ENISA, and voluntary reporting does not impose additional obligations on the reporter. ENISA's single reporting platform accepted only mandatory manufacturer reports at launch, with voluntary reporting planned for a later phase, so other reporters should contact their national CSIRT directly.

If your product security team has not yet run an exploited-vulnerability scenario against the 24-hour clock, our Cyber Resilience Act compliance team can design the triage criteria and templates, plan your platform access, and test the process with your engineering and legal staff in a tabletop exercise.