CRA Article 14 reporting, explained

Two reports, not one sequence

Article 14 of Regulation (EU) 2024/2847 asks the manufacturer to notify an actively exploited vulnerability and a severe incident that has an impact on the security of the product with digital elements. They share the first two deadlines. They do not share the last one.

An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it. A severe incident is an incident with an impact on the security of the product. A bug that is neither of those is still a vulnerability-handling problem under Annex I. It is not, by itself, an Article 14 filing.

The dates for the rest of the regulation are on the CRA timeline. Article 14 has applied since 11 September 2026. The essential requirements, the technical file and CE marking apply from 11 December 2027.

When the clock starts

The 24-hour and 72-hour periods run from the manufacturer becoming aware. They do not run from the moment a fix is ready, and they do not wait until the analysis is finished. The final report for a vulnerability uses a different starting point: the day a corrective or mitigating measure is available.

Awareness is a fact you have to be able to point at. A researcher email, a customer report with a working exploit, or a line in your own telemetry can each be that fact. The runbook should say who is allowed to write the time down, and what sort of message is enough. If that rule is invented on the day, the early warning is already late.

Write the time, the person, and the evidence in one place. Email threads do not show this six months later.

The 24-hour early warning

The early warning is due without undue delay and in any event within 24 hours of awareness. It is a short alert. It indicates, where you know, the Member States on whose territory the product has been made available.

It does not have to contain the root cause. Holding it until the picture is complete is how the deadline is missed. Manufacturers that are micro or small enterprises are not meant to be fined for missing only this 24-hour deadline. The duty to send it still applies, and the 72-hour notification is a separate duty. The term is in the glossary.

The 72-hour notification

Unless you already provided the information, a notification follows within 72 hours of awareness. It gives general information, as available, about the product, the general nature of the exploit and of the vulnerability, or of the incident. It also covers corrective or mitigating measures already taken, and measures users can take.

It asks you to say how sensitive you consider the notified information to be. That is a judgement about the text you are filing, recorded at the time, not a label added later.

The final report

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available, unless that information was already provided. The 14 days start when the measure exists, not when you first became aware.

For a severe incident, the final report is due within one month after the 72-hour notification was submitted. Using the vulnerability rule for an incident, or the other way around, files the right story against the wrong clock.

A printable list of these stages is the Article 14 checklist.

Where the report goes

You submit once, through the Single Reporting Platform established under Article 16 and run by ENISA. The platform has been operational since 11 September 2026. The notification is addressed to the CSIRT of the Member State where the manufacturer has its main establishment, and it is made available to ENISA.

That CSIRT shares it with the CSIRTs of other Member States where the product has been made available. You do not file a separate early warning in each country. The Commission's reporting page describes that path.

Informing users is its own step. A filing on the platform does not replace a message to the people who have the product. Article 14 keeps those apart.

Products you already sell

Reporting applies to products with digital elements that have been made available on the Union market, including products placed there before 11 December 2027. A product placed before that date meets the full requirements only if it is substantially modified afterwards. The reporting duty does not wait for that modification.

The support period is the time you handle vulnerabilities under Annex I, and its end date is shown at purchase. It is not the switch that turns Article 14 off for a product you already made available.

Who decides

The manufacturer notifies. An importer or a distributor that sells under its own name, or that substantially changes the product, can take the manufacturer's duties on. An authorised representative does the tasks in a written mandate. The mandate does not, by itself, make the representative the person who decides to report.

Inside the company, three names matter: who may record awareness, who decides that the case is reportable, and who has access to the platform. Each needs a backup. The decision to report stays with you. A tool can hold the draft and the clock. It cannot take the decision.

What this looks like on a product

This is a fictional connected sensor. Nothing here is a client, and the times are made up so the clocks are easy to see.

On Tuesday at 09:10 a researcher emails the security address. The message includes a working exploit against firmware 2.4, which is still shipping. The on-call engineer records 09:10 as the moment the manufacturer became aware, and writes why the case is an actively exploited vulnerability. The named decider approves a short early warning the same morning. It names the product and the Member States where that firmware was sold. The representative copies it into the Single Reporting Platform.

By Thursday at 09:10 the 72-hour notification adds the general nature of the exploit, the mitigation already in place (remote debug is switched off), and what users can do. A patched firmware is ready the following week. The final report is sent within 14 days of that patch becoming available. The company keeps the submitted text, the times, and the name of the approver. Users get a separate note about the update. The platform filing is not that note.

When this description does not apply

An open-source software steward is not a manufacturer. The Commission states that stewards' reporting under Article 24(3) applies from 11 December 2027, not from 11 September 2026. Stewards are not subject to the penalties.

A pure SaaS product that is not the remote data processing a product needs in order to work is generally outside the regulation. Free open-source software that is not made available in the course of a commercial activity is outside it too. Some products are excluded because another EU law covers them, including medical devices, motor vehicles and certain aviation products.

Anyone may also notify a vulnerability, threat, incident or near miss on a voluntary basis through the same platform. Voluntary is not the manufacturer's Article 14 clock.

This is a reading of the regulation for product teams, checked on 16 October 2026. It is not legal advice. The text that counts is Regulation (EU) 2024/2847.

What we do

Sources

• Regulation (EU) 2024/2847, Articles 14, 16, 24 and 71
• European Commission, CRA reporting obligations
• European Commission, summary of the legislative text