CRA ENISA 24-hour reporting — the early warning rule in operational detail

The Cyber Resilience Act introduces a mandatory reporting regime for actively exploited vulnerabilities and severe incidents in products with digital elements. From 11 September 2026 onwards, manufacturers must submit a three-tier report cascade to ENISA via a single reporting platform — the 24-hour early warning rule being the most demanding clock most manufacturers will encounter in their compliance work.

This article walks through the operational detail of CRA Article 14: what triggers reporting, what each tier of the cascade requires, how the ENISA single reporting platform routes to member-state CSIRTs, the relationship to coordinated vulnerability disclosure processes, and the penalties for failure to report.

What activates the reporting obligation

Article 14(1) covers actively exploited vulnerabilities:

"A manufacturer shall notify simultaneously the relevant CSIRT designated as a single point of contact in accordance with Article 12(1), point (c), of Directive (EU) 2022/2555, and ENISA of any actively exploited vulnerability contained in the product with digital elements that the manufacturer becomes aware of."

Article 14(2) covers severe incidents:

"A manufacturer shall notify simultaneously the relevant CSIRT designated as a single point of contact in accordance with Article 12(1), point (c), of Directive (EU) 2022/2555, and ENISA of any severe incident having an impact on the security of the product with digital elements that the manufacturer becomes aware of."

Two distinct triggers, same reporting cascade.

What is an "actively exploited vulnerability"?

Article 3(40) provides the definition:

"'actively exploited vulnerability' means a vulnerability for which there is reliable evidence that the execution of malicious code was carried out by an actor on a system without the permission of the system owner."

The key phrase is reliable evidence. The threshold is set at confirmed in-the-wild exploitation — not theoretical exploitation, not proof-of-concept, not disclosed-but-not-exploited.

Examples that do trigger reporting:

• Threat-intel report from a CSIRT confirming a vulnerability is being exploited against your product
• Customer forensic report showing compromise via your product's known vulnerability
• Honeypot detection of exploitation attempts matching your product's signature
• Public security advisory with documented in-the-wild exploitation

Examples that do not trigger reporting (but should be handled under standard CVD process):

• Disclosed CVE in your product without exploitation evidence
• Proof-of-concept demonstration at a security conference
• Researcher report describing exploitability without observed exploitation
• Vendor advisory from a component supplier about an upstream vulnerability

What is a "severe incident having an impact on security"?

Annex VI sets the severity criteria. An incident is severe if it:

• Has the capability to negatively affect the development, production, or maintenance of products with digital elements
• Has actually compromised confidentiality, integrity, or availability of data or functions stored, transmitted, or otherwise processed in the product
• Resulted in or could result in serious operational disruption or financial loss

The thresholds are intentionally broad. The regime incentivises over-reporting — under-reporting carries fine risk, over-reporting does not.

The three-tier cascade

Tier 1 — Early warning notification (24 hours from awareness)

Article 14(1)(a). Required content:

• Suspected malicious activity — is the cause suspected to be a malicious actor?
• Nature of the issue — initial description; what was exploited, how
• Affected products — model numbers, versions, approximate scale
• Member states concerned — where the manufacturer is established; where the products are distributed
• Initial point of contact — name and contact at the manufacturer

The early warning is intentionally short. The purpose is to alert ENISA and member-state CSIRTs so they can start coordinating, not to produce a complete technical document under time pressure.

Practical content for a Wi-Fi camera manufacturer:

Early Warning — DoC-2026-0042 — Issued: 25 Jun 2026 09:15 UTC

Manufacturer: Inovasense s.r.o., Slovakia
Initial contact: vladimir@inovasense.com

Nature: A buffer overflow in the firmware HTTP parser of the
ConnectedSensor X1 product allows remote code execution by
an unauthenticated attacker over the local network.

Suspected malicious activity: Yes — threat-intel reports from
CSIRT-DE indicate exploitation against deployed units in
Germany since 22 Jun 2026.

Affected products: ConnectedSensor X1, firmware versions
1.0.0 through 1.4.2. Approximately 12 000 units deployed
across Germany, Slovakia, Austria.

Member states concerned: SK (manufacturer), DE (primary
deployment), AT (secondary deployment).

Current remediation status: A patch (firmware 1.4.3) is in
preparation; release expected within 7 days.

Tier 2 — Vulnerability or incident notification (72 hours from awareness)

Article 14(1)(b). Required additions to the early warning:

• Severity assessment — CVSS score or equivalent
• Available mitigations or workarounds — what users can do while waiting for the patch
• Geographical spread — which member states, more precise unit counts
• Personal data assessment — was personal data compromised? (Triggers parallel GDPR Article 33 notification when yes)

Tier 3 — Final report (within 14 days of corrective measure availability)

Article 14(1)(c). Complete writeup:

• Detailed description of the vulnerability or incident
• Severity and impact confirmation
• Root cause analysis — what design or process failure permitted the vulnerability
• Corrective measures applied — patch, mitigation, recall, withdrawal
• Mitigations and updates made available to users — patch availability, distribution channel, install instructions

If the vulnerability remains unresolved past 14 days, monthly progress updates are required until the final report is submitted.

The ENISA single reporting platform

From 11 September 2026 the ENISA single reporting platform is the channel. The manufacturer files once; ENISA forwards to the relevant member-state CSIRT. The platform is described under Article 16 of CRA.

Operationally:

1. Manufacturer creates an account on the ENISA platform — typically once per organisation, with appropriate authorisation chains
2. For each report, the manufacturer enters the structured content (early warning → notification → final report) into the platform's form
3. The platform routes to the CSIRT designated as single point of contact under NIS2 Article 12(1)(c). Typically this is the CSIRT of the member state where the manufacturer is established, or the member state hosting the largest share of affected users
4. ENISA retains the reports and contributes them to the European Cybersecurity Centre coordinated response work

The platform is the single source of truth for CRA reporting. Email, fax, or direct CSIRT contact outside the platform is not the prescribed channel and does not satisfy Article 14.

Member-state CSIRT — who receives the report

NIS2 Article 12(1)(c) requires each member state to designate a CSIRT as single point of contact for CRA reports. The current 2026 designations:

The single-point-of-contact CSIRT may not be the same CSIRT that does day-to-day incident response — some member states have separate CSIRTs for different sectors. The CRA single-point-of-contact CSIRT routes internally to whichever team handles the specific incident type.

The relationship to coordinated vulnerability disclosure

CRA Annex I Part II item (5) requires manufacturers to operate a coordinated vulnerability disclosure (CVD) process throughout the support period:

"Put in place and enforce a policy on coordinated vulnerability disclosure."

CVD is an ongoing manufacturer process — accepting vulnerability reports from researchers, coordinating timing of disclosure, issuing CVEs and security advisories.

The Article 14 reporting cascade runs in addition to CVD when a CVD-surfaced vulnerability becomes actively exploited. Both happen:

• CVD researcher communication continues per the CVD policy
• 24-hour ENISA notification runs in parallel
• 72-hour notification adds the severity and mitigations
• Final report references both the CVD coordination and the corrective measure

Manufacturers typically publish a CSAF VEX statement at the end of the CVD process — describing which CVEs in their SBOM affect which product versions and whether each is actually exploitable. The VEX statement complements the Article 14 final report but does not replace it.

See SBOM CycloneDX vs SPDX for the VEX format detail.

Penalties under Article 64

Article 64 sets administrative fine ceilings:

• Failure to comply with Article 14 reporting obligations — up to €10 million or 2% of global annual turnover (whichever is higher)
• Misleading or incomplete information to a Notified Body or competent authority — up to €5 million or 1%
• Other Article 14 procedural failures — capped under member-state national implementing law

The signer of the Declaration of Conformity is personally named in proceedings — the legal entity is liable, but the individual signatory's identity is on the file.

Member states implement the fines through national procedures. Some apply the regulatory ceiling directly; others tier the fines based on factors such as duration, intent, and prior compliance history.

Common reporting mistakes

From the Inovasense practice working with manufacturers preparing for September 2026:

• No 24/7 monitoring of inbound CSIRT communications. The 24-hour clock starts when the manufacturer becomes aware. A CSIRT email arriving on Friday evening with the manufacturer's first response on Monday morning has already burned 60 of the 24 hours.
• No internal escalation path. First-line support receives the CSIRT report; the report sits in a ticket queue while escalation criteria are unclear.
• No platform account set up before the first incident. Creating the ENISA platform account during an incident wastes the early-warning window.
• Confusing severity assessment with full root cause analysis. The 72-hour notification needs the severity, not a complete RCA. The RCA goes in the final report.
• Reporting only when fully resolved. Article 14 requires the cascade — early warning first, then notification, then final report. Filing only the final report misses the 24-hour and 72-hour obligations.
• No parallel GDPR breach notification when personal data is compromised. GDPR Article 33 runs separately and goes to the data protection authority, not to ENISA.
• No documentation of the "awareness" timestamp. If challenged, the manufacturer must defend when awareness occurred. Internal triage logs should timestamp every relevant event.

How Cenitia helps

Cenitia integrates with the manufacturer's CVD process to track potentially reportable vulnerabilities through the triage workflow. When a vulnerability is escalated to "actively exploited" status, Cenitia produces the structured content for the 24-hour early warning, 72-hour notification, and final report in the format the ENISA platform expects. The Cenitia notification system raises out-of-hours alerts when CSIRT communications arrive — preventing the most common 24-hour-clock failure mode.

For products requiring extensive incident response operations or Notified Body coordination on CRA Annex IV critical products, our parent company Inovasense provides operational support.

Frequently asked questions

What exactly must I include in the 24-hour early warning notification?

Under CRA Article 14(1), the early warning must include: an indication of whether the vulnerability is suspected of being caused by a malicious actor; an initial description of the nature of the issue and the products affected; the member states where the manufacturer is established and intends to remedy; and an initial point of contact at the manufacturer. The early warning is intentionally minimal — its purpose is to alert ENISA and CSIRTs, not to require a full technical writeup under time pressure.

What additional information goes into the 72-hour notification?

The 72-hour notification under CRA Article 14(2) adds: an assessment of the severity of the vulnerability or incident (typically using CVSS or equivalent); a description of available mitigations or workarounds; an indication of the geographical spread of affected products — which member states, approximate number of units affected; whether personal data was likely compromised (which may also trigger parallel GDPR Article 33 notification).

When is the final report due?

Within 14 days from the date a corrective or mitigating measure becomes available. The final report under CRA Article 14(3) includes: a complete description of the vulnerability or incident; severity and impact assessment; root cause analysis; corrective measures applied; and the mitigations and updates made available to users. If the vulnerability remains unresolved at any intermediate point, monthly progress updates are required.

Where exactly does the report go?

From 11 September 2026 onwards, CRA Article 14 reports go to the ENISA single reporting platform. ENISA forwards the report to the CSIRT designated as single point of contact in a member state — typically the CSIRT of the member state where the manufacturer is established, or the member state hosting the largest share of affected users. The manufacturer files once via the ENISA platform; the routing to member-state CSIRT happens automatically.

What constitutes 'awareness' that starts the 24-hour clock?

Article 14(1) refers to becoming aware of an actively exploited vulnerability or severe incident. 'Awareness' in practice means the moment the manufacturer has reliable evidence — typically a confirmed report from a CSIRT, a customer with forensic evidence, an internal triage finding, or a public disclosure with exploitation evidence. Rumours, unconfirmed press reports, and theoretical proof-of-concept demonstrations without in-the-wild evidence do not start the clock. Document the awareness moment to defend the 24-hour timestamp if challenged.

What happens if I'm not sure whether to report?

The CRA regime incentivises over-reporting. Failure to report a reportable event carries fines up to €10 million or 2% of global annual turnover under Article 64. Reporting an event that turns out not to require reporting carries no penalty — ENISA and the CSIRT simply close the report. When uncertain, report and let the authorities determine relevance.

How does CRA reporting interact with the existing CVD process?

Coordinated Vulnerability Disclosure (CVD) is an ongoing manufacturer process governed by CRA Annex I Part II item (5). When a CVD process surfaces an actively exploited vulnerability, the Article 14 reporting cascade activates in parallel — the 24-hour ENISA report runs alongside the CVD researcher communication. Both must happen. The CVD researcher is informed of the manufacturer's timeline including the ENISA notification step.

Related from the Library

• CRA Annex I explained — the essential requirements the Article 14 reporting protects
• CRA timeline and reporting obligations — the pillar context for September 2026 and December 2027
• SBOM CycloneDX vs SPDX — VEX format used in final reports
• CRA vs NIS2 overlap — parallel NIS2 reporting obligations

Further reading

• Cyber Resilience Act Article 14 — Reporting obligations of manufacturers
• Cyber Resilience Act Annex VI — Severity criteria for severe incidents
• NIS2 Article 12 — designation of CSIRTs
• ENISA CRA implementation guidance
• OASIS CSAF — Common Security Advisory Framework

Last reviewed: 25 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.