CRA vulnerability reporting: the 24h & 72h workflow

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe product-security incidents through ENISA's Single Reporting Platform. This guide turns Article 14 into a practical decision and delivery workflow.

Check what is reportable Plan the workflow

What must be reported?

Article 14 creates two mandatory triggers. It does not turn every discovered vulnerability, scanner finding or CVE into a 24-hour notification.

Actively exploited vulnerability

A vulnerability in the product for which there is reliable evidence that a malicious actor exploited it in a system without the system owner's permission. That is narrower than “exploitable” and narrower than “has a CVE.” CRA Article 3(42).

Severe product-security incident

An incident that negatively affects, or can negatively affect, protection of sensitive or important data or functions; or that led, or can lead, to malicious code running in the product or a user's systems. The protected properties are availability, authenticity, integrity and confidentiality. CRA Article 14(5).

Practical rule: triage every credible product-security signal, but start the mandatory clock only when the manufacturer becomes aware that one of these legal triggers is met. Record the evidence and the decision time. The reportability decision should be reviewed by qualified security and legal personnel.

A defensible four-question test

Scope
Is this an in-scope product with digital elements made available on the EU market?
Evidence
Is there reliable evidence of malicious exploitation, not only technical exploitability?
Severity
Alternatively, does the incident meet either Article 14(5) severity condition?
Awareness
When did the manufacturer have enough information to know the trigger was met?

The CRA reporting timeline

Both paths begin when the manufacturer becomes aware of the reportable event. The 24-hour and 72-hour limits are maximums: Article 14 also says to report without undue delay.

Stage	Actively exploited vulnerability	Severe incident
Within 24 hours	Early warning; include known Member States where the product was made available.	Early warning; state whether unlawful or malicious acts are suspected and include known affected-market Member States.
Within 72 hours	General nature of the vulnerability and exploit, mitigations taken, user actions and information sensitivity.	Nature and initial assessment, mitigations taken, user actions and information sensitivity.
Final report	No later than 14 days after a corrective or mitigating measure becomes available.	Within one month after the 72-hour incident notification.

One submission route

Submit through the CRA Single Reporting Platform to the relevant coordinator CSIRT; the information is simultaneously available to ENISA except in defined exceptional circumstances. Commission overview.

Users also need information

Article 14(8) separately requires manufacturers to inform impacted users—and where appropriate all users—of the event and the risk-reduction or corrective measures they can deploy.

Capture the facts before the clock starts

ENISA's current template distinguishes mandatory, conditional and optional fields at each stage. Your internal case record should collect the superset once, then generate the smallest accurate report available at each deadline.

Product identity

Manufacturer, product, version or model, product type and relevant category.

Clock evidence

Detection time, awareness time, decision owner and the evidence that established reportability.

Market reach

Member States where the affected product is known to have been made available.

Technical account

Nature of the vulnerability or incident, exploitation evidence, severity and expected impact.

Response

Measures already taken, measures users can take, patch or mitigation availability and rollout state.

Disclosure controls

Information sensitivity, exceptional-circumstance assessment and approval history.

The current ENISA field matrix includes product, report type, Member States, CVE/EUVD identifiers when available, mitigations, impact, sensitivity and final-report details. Verify fields against the live platform because ENISA says its guidance may change. See ENISA FAQ questions 16–17.

What a useful reporting workflow should do

The valuable layer sits before and around the regulator form: it joins product telemetry, PSIRT decisions, affected-product data, approvals, deadlines and user communications into one auditable case.

Important platform constraint

ENISA states that organisations may automate internal workflows, but no SRP API is provided at this stage. Build export, copy-assist and controlled manual submission—not an undocumented connector. ENISA FAQ 15.

Intake
Receive researcher disclosures, product telemetry, support escalations and third-party component alerts in one queue.
Triage
Link affected versions and markets; record exploitation evidence, Article 14(5) severity and the awareness decision.
Clock
Run parallel 24-hour and 72-hour SLAs with named owners, backup approvers and escalation before each breach.
Approve
Separate technical drafting, security sign-off and legal review without losing an immutable version history.
Submit
Prepare the exact SRP field set, record who submitted it and retain the receipt and every subsequent update.
Close
Track patch availability, user communication, final-report due date and evidence that mitigations reached affected users.

Minimum integrations

Issue tracker or PSIRT inbox, product/version catalogue, identity provider, alerting and evidence archive.

Minimum controls

Role-based access, backup assignees, immutable audit history, field-level sensitivity and export retention.

Acceptance test

Run a timed tabletop exercise from first signal to approved 24-hour report, then complete the 72-hour and final-report paths.

Where the SBOM fits—and where it does not

The CRA's vulnerability-handling requirements call for a machine-readable software bill of materials covering at least top-level dependencies. That requirement belongs to the main regime applying from 11 December 2027, not the early Article 14 reporting start date.

What it helps with

Find products and versions containing an affected component, identify owners and prioritize the impact investigation.

What it cannot decide

Whether reliable exploitation evidence exists, whether an incident is severe, when awareness occurred or what must be filed.

Treat the SBOM as an impact-analysis input to the case, not as a substitute for the reporting workflow. CRA Annex I, Part II(1).

Who needs this ready in 2026?

The early reporting rule matters to manufacturers of in-scope software, hardware and connected products sold in the EU—even when those products were placed on the market before the CRA applies in full.

IoT and connected-device manufacturers

Business and consumer software vendors

Industrial control and embedded-system makers

Non-EU manufacturers serving the EU market

Article 69(3) expressly applies Article 14 to in-scope products placed on the market before 11 December 2027. Scope and role analysis still matter: this page is an operational guide, not a legal opinion. Read the official regulation.

Related operational work

IoT and OT security engineering NIS2 supply-chain risk workflow

CRA reporting FAQ

Does every CRA vulnerability need to be reported within 24 hours?

No. Mandatory Article 14 reporting is triggered by an actively exploited vulnerability for which there is reliable evidence of malicious exploitation, or by a severe incident affecting product security. A CVE, theoretical exploitability or an unexploited defect is not by itself the mandatory trigger.

When do the CRA reporting obligations start?

Article 14 applies from 11 September 2026. The CRA applies in full from 11 December 2027, but the reporting duty starts earlier and also covers in-scope products placed on the EU market before full application.

Where does a manufacturer submit a CRA report?

The manufacturer submits once through ENISA's CRA Single Reporting Platform, selecting the CSIRT designated as coordinator. For an EU manufacturer, the coordinator is generally determined by the Member State of its main establishment under Article 14(7).

Can CRA reporting be automated through an ENISA API?

Not currently. ENISA says organisations may automate their internal reporting workflow, but no API will be provided at this stage. A practical system should therefore prepare approved, traceable submission data and support controlled entry into the SRP.

Is an SBOM the same as CRA vulnerability reporting?

No. The SBOM is part of the CRA vulnerability-handling requirements that apply with the main regime from 11 December 2027. It helps identify affected dependencies and products, but it does not replace the Article 14 reporting decision or the SRP notification.

Primary sources

Reviewed 1 September 2026. The regulation controls where a summary differs. ENISA's interface guidance is operational and may be updated as the SRP launches.