CRA vulnerability reporting: a 24-hour checklist for 2026

Hephaestus Technology9 November 202610 min read

AI Cyber Resilience Act IoT Compliance Security

Since 11 September 2026, CRA vulnerability reporting has been mandatory. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, according to the European Commission. Each case needs an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report. A small manufacturer with no security operations centre should name one decision-maker, two filers and a recipient CSIRT before the next incident arrives.

Key takeaways

Article 14 reporting has applied since 11 September 2026 and covers products already on the market, not only new ones.
The 24-hour and 72-hour clocks run from awareness. Awareness means a prompt initial assessment that gives reasonable certainty of active exploitation or a severe incident.
The final report is due 14 days after a corrective or mitigating measure is available for vulnerabilities, but one month after the 72-hour notification for severe incidents.
Flaws in supplier components count where they are actively exploited in your product.
Reporting to authorities does not replace informing affected users.

What does CRA vulnerability reporting require from 11 September 2026?

CRA vulnerability reporting requires manufacturers to notify two kinds of event: actively exploited vulnerabilities in their products, and severe incidents affecting product security. The Commission says you report once, through the Single Reporting Platform (SRP) that ENISA set up under Article 16. The notification goes to the CSIRT of the Member State where you have your main establishment. Unless "particularly exceptional circumstances" apply, it goes to ENISA at the same time.

The Cyber Resilience Act entered into force on 10 December 2024 (Cloud Security Alliance). Open-source software stewards join the reporting regime from 11 December 2027 (Commission). If you are still mapping the wider obligations, see our CRA worked example for an IoT startup.

Does the reporting duty apply to my product, including UK exporters and legacy devices?

Yes, if your product is on the EU market, and that includes devices shipped before the rules started. Reporting covers in-scope products placed on the market before 11 December 2027 as well as later ones. That position appears in Aegister (citing Article 69(3)), cvdportal and Merois. Addleshaw Goddard puts it plainly: "The reporting obligations are an express exception and apply regardless of when a product was placed on the market."

No retroactive reporting. You need not report exploitation you knew about before 11 September 2026. If you become aware on or after that date, the duty applies even to an older flaw (Merois).
End of support. Commission guidance C(2026) 5252 keeps reporting obligations running after the support period ends. Aegister cites its Section 9.1 for this, and cvdportal, Merois and Addleshaw Goddard say the same.
No SME exemption found. We found no source mentioning a small-business exemption from Article 14. Coordinator CSIRTs do provide helpdesk support on Article 14, particularly to micro, small and medium enterprises, under Article 17(6) (Aegister).

UK exporters. We found no source addressing UK manufacturers by name. If you have no EU main establishment, Article 14(7) picks the recipient CSIRT in this order (Merois):

The Member State of the authorised representative acting for most of your products.
Then the importer's Member State.
Then the distributor's.
Then the Member State with the most users.

Main establishment means where cybersecurity decisions about the products are predominantly taken. Failing that, it is where you employ most people in the EU (same source). Whether an Irish office or EU distributor gives a UK firm a main establishment is a question for legal advice. We did not verify how Northern Ireland is treated.

The CRA is separate from AI regulation. If your device also has AI features, check whether the EU AI Act applies to your business as its own question.

What counts as an "actively exploited vulnerability" or a "severe incident"?

Under Article 3(42), an actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Merois, Aegister). Merois adds that a high severity score, a published CVE or the absence of a patch does not by itself meet that definition.

A severe incident, under Article 14(5), is one that (Merois):

(a) 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
(b) has led or is capable of leading to malicious code being introduced or executed in the product, or in a user's network and information systems.

The finished-product manufacturer must report vulnerabilities in components it has integrated (Addleshaw Goddard, Aegister, cvdportal). cvdportal notes a limit. A component vulnerability is reportable only where it is actively exploited in your product. If the vulnerable code is unreachable, the mandatory report does not apply.

What are the 24-hour, 72-hour and final report deadlines?

The hourly deadlines run from awareness; the final report deadlines do not (Commission). The common shorthand "14-day final report" is right only for actively exploited vulnerabilities. Those 14 days count from when a corrective or mitigating measure is available, which can be a mitigation before any patch exists (Merois, Aegister). Severe incidents get one month from the 72-hour notification (Commission).

Report	Actively exploited vulnerability (Art. 14(2))	Severe incident (Art. 14(4))	Recipient
Early warning	Within 24 hours of awareness. Member States where the product is available, where applicable.	Within 24 hours. Whether unlawful or malicious acts are suspected, plus Member States.	Coordinator CSIRT and ENISA, via SRP
Notification	Within 72 hours of awareness. General product information, general nature of the exploit and vulnerability, corrective or mitigating measures taken, measures users can take, sensitivity of the information.	Within 72 hours. Nature of the incident, initial assessment, measures taken, measures users can take, sensitivity.	Same
Final report	No later than 14 days after a corrective or mitigating measure is available. Severity and impact, malicious actor (where available), update details.	Within one month of the 72-hour notification. Severity and impact, threat type or likely root cause, mitigation applied and ongoing.	Same
Intermediate report	Only if the coordinator CSIRT requests it (Art. 14(6)).	Same	Same

Content sources: Aegister, Merois.

How do I set up a CRA reporting process in 7 steps?

Set it up before an incident. These steps are our synthesis of the sources cited.

Name your coordinator CSIRT and record why. Apply the main-establishment test or the Article 14(7) order. Citing ENISA's SRP FAQ, Merois warns that choosing the wrong CSIRT may invalidate the notification.
Name two filers. Have a primary and a deputy, so leave or illness does not cost you a deadline.
Name who decides "reasonable certainty". Commission guidance says awareness arises when a prompt initial assessment gives a reasonable degree of certainty (cvdportal). One person and a deputy make and timestamp that call. If triage is automated or AI-assisted, keep the decision with an accountable human.
Map products to markets and suppliers. The early warning lists the Member States where the product is available, and component flaws need upstream contacts.
Keep a clock log. Record awareness, early warning and notification times, the date a corrective or mitigating measure became available, and the one-month date.
Draft a user notice. Reporting to authorities and informing users are separate obligations. Article 14(8) requires the user-facing step (Merois).
Write an outage plan. Decide who contacts your CSIRT directly, and how you record failed filing attempts, if you cannot reach the platform.

Steps 3 and 4 depend on evidence your product can produce: logs, update-channel integrity, version telemetry. If your firmware cannot tell you which versions are in the field, that is an engineering gap. Our build stage covers embedded firmware and IoT work.

What should we do in the first 24 hours after we learn of an exploit?

Assess fast, decide, then file a short early warning. The fuller detail belongs in the 72-hour notification and the final report (see the table above).

Log when the report or alert arrived.
Start the initial assessment immediately; the guidance expects promptness (cvdportal, Aegister).
When the decision-maker reaches reasonable certainty, log that as awareness. The 24 hours start here.
Gather the early-warning content (Aegister, Merois). For a vulnerability, list the Member States where the product is available, where applicable. For a severe incident, also say whether unlawful or malicious acts are suspected. Check ENISA's current SRP guidance for the exact form fields.
Submit through the SRP.
In parallel, start the user-notification decision and contact any affected supplier.
Diary the 72-hour notification deadline from the moment of awareness, not from when you filed the early warning.

How does ENISA's Single Reporting Platform work, and who receives the report?

The SRP is ENISA's web portal at portal.cra-srp.enisa.europa.eu (Merois), set up under Article 16 (Commission). You file once. The report reaches your coordinator CSIRT and ENISA at the same time, unless particularly exceptional circumstances apply.

The coordinator CSIRT shares the report with CSIRTs in other Member States where the product is available. It may delay this on cybersecurity grounds, and the Commission notes that a delegated act sets the conditions for such a delay (Commission). Registration steps, user roles and validation are set by ENISA and individual CSIRTs. Read ENISA's current SRP documentation now rather than during an incident.

Ireland: we did not verify which body is Ireland's coordinator CSIRT under the CRA, how it handles validation, or Ireland's CRA market surveillance arrangements. Confirm these with ENISA directly.

What mistakes do small teams make?

The most common mistakes are about timing, triggers and recipients:

Starting the clock on a score or CVE. A severity score, a CVE or a missing patch does not by itself meet the definition (Merois). A slow assessment is not safe either, because the guidance expects promptness.
Waiting for a patch. The 14-day vulnerability clock runs from a corrective or mitigating measure, which can come before a patch (Merois).
Counting the incident month from awareness. It runs from the 72-hour notification (Commission).
Reporting every supplier CVE. A component flaw is reportable where it is actively exploited in your product, not merely present (cvdportal).
Choosing the CSIRT by attack location. It follows your main establishment, or the Article 14(7) order (Commission, Merois).
Treating the SRP as user notification. Informing users is a separate Article 14(8) obligation.

CRA reporting readiness checklist

[ ] Coordinator CSIRT named, with main-establishment or Article 14(7) reasoning recorded
[ ] Primary and deputy filer named
[ ] Owner and deputy for the reasonable-certainty decision
[ ] Written definitions from Articles 3(42) and 14(5)
[ ] Clock log template (awareness, 24h, 72h, corrective or mitigating measure date, one-month date)
[ ] Member States list per product
[ ] Supplier contact list
[ ] User-notification template
[ ] Platform outage plan
[ ] Owner for each final report

Frequently asked questions

Do CRA reporting obligations apply to products sold before 2027?

Yes. Reporting applies to in-scope products placed on the market before 11 December 2027 as well as later ones. You need not report exploitation you knew about before 11 September 2026. Awareness on or after that date triggers the duty even for an older flaw.

When is the CRA final report due?

For an actively exploited vulnerability, it is due no later than 14 days after a corrective or mitigating measure is available, which can be before a full patch. For a severe incident, it is due within one month of the 72-hour notification. Neither deadline runs from awareness.

Does a vulnerability in a supplier's component have to be reported?

Yes, if it is actively exploited in your product: the finished-product manufacturer reports. Where the vulnerable code is unreachable in your product, the mandatory report does not apply. You should still contact the supplier.

Does a published CVE or high severity score start the 24-hour clock?

No. The definition requires reliable evidence that a malicious actor exploited the vulnerability without the system owner's permission. A score, a CVE or the absence of a patch does not by itself meet that test.

Does the CRA reporting duty apply to UK manufacturers?

We found no source addressing UK firms by name. Article 14(7) sets the recipient CSIRT for manufacturers without an EU main establishment. The order runs from the authorised representative's Member State to the importer's, then the distributor's, then the Member State with the most users. Take legal advice on your own structure.

Is there an exemption for small businesses?

We found no SME exemption from Article 14. Coordinator CSIRTs provide helpdesk support on Article 14, particularly to micro, small and medium enterprises, under Article 17(6).

If you want help with the product side of CRA readiness, book a free 30-minute call with Hephaestus.

Cover photo by ThisIsEngineering on Pexels.