Regulation (EU) 2024/2847

Statutory CRA reporting alongside the firmware fix. Exposure verification, staged 24h and 72h ENISA notifications, and support-period Linux maintenance for device manufacturers.

Mandatory Article 14 reporting has applied since 11 September 2026, and full vulnerability-handling obligations apply from 11 December 2027. Firmdura verifies whether an incident or exploited CVE actually reaches your shipped configuration and prepares ENISA dossiers while the patch builds.

Statutory milestones · Regulation (EU) 2024/2847 CRA deadlines and thresholds at a glance.

24 hours
Early warning (Article 14, in effect) Initial alert via ENISA's Single Reporting Platform after awareness of active exploitation or a severe incident.
72 hours
Vulnerability or incident notification Affected firmware branches, nature of the exploit or impact, and interim mitigations while remediation proceeds.
14d / 1m
Final statutory report Within 14 days of a corrective release for exploited CVEs, or within 1 month for severe incidents.
11 Dec 27
Main CRA & support period (Article 13(8)) Security updates across expected use (in general at least 5 years); fines up to EUR 15M or 2.5% turnover (Article 64).

Regulatory & engineering precision

Two distinct duties: Article 14 reporting vs. Article 13 vulnerability handling.

Treating every scanner CVE as a 24-hour reporting emergency wastes engineering capacity, while waiting for a finished patch before assessing an exploited flaw misses statutory deadlines.

Dimension	Article 14 mandatory reporting	Article 13 vulnerability handling
Application date	In force since 11 September 2026 across covered products	Main obligations apply from 11 December 2027 (subject to transition rules)
Triggering scope	Actively exploited vulnerabilities contained in the product and severe incidents affecting product security	Relevant vulnerabilities affecting the product across its declared support period (in general at least five years)
Timing requirement	24h early warning, 72h notification, and final report within 14 days of a corrective measure (or 1 month for severe incidents)	Assess relevance and risk and provide appropriate security updates or documented mitigations without delay
Unreachable third-party code	Not reportable if the vulnerable code path cannot be exploited in the shipped product configuration	May be documented as non-applicable in VEX / technical records rather than forcing an unnecessary patch release

Governance boundary: Firmdura supplies the technical exposure analysis, draft dossiers, and firmware repairs. You retain product risk decisions, authorized ENISA submission sign-off, and legal responsibility as manufacturer.

Coordinated execution

How ENISA reporting and firmware remediation run in parallel.

Commission CRA guidance briefing

Stage 1 · 0 to 24 hours

Exposure check & early warning

Engineering track: Verify against pinned build flags and symbols whether the affected component and vulnerable call path are actually compiled.
ENISA dossier track: Record awareness timestamp and prepare the 24-hour early warning draft if active exploitation or severe impact applies.

Stage 2 · Within 72 hours

Notification & candidate build

Engineering track: Adapt upstream patches, run candidate firmware builds, and identify immediate configuration workarounds where needed.
ENISA dossier track: Assemble affected version ranges, exploitation mechanics, and interim mitigations formatted for the Single Reporting Platform.

Stage 3 · 14d / 1m closure

Signed release & final report

Engineering track: Deliver regression-tested merge request and verification logs for your team's review, signing, and OTA rollout.
ENISA dossier track: Link the 14-day vulnerability closure report (or 1-month incident report) directly to your released advisory and build record.

Primary legal sources: Regulation (EU) 2024/2847 (EUR-Lex) · European Commission CRA · Commission CRA reporting rules · ENISA platform briefing

Regulatory & technical Q&A

Manufacturer questions on CRA reporting and support periods.

Does an actively exploited CVE in an open-source library automatically trigger a 24-hour ENISA report?

Only if exploitable in your product. Under the European Commission's July 2026 CRA implementation guidance, if a library is present in the image but the vulnerable function or build option is disabled or unreachable, mandatory Article 14 reporting is not triggered. Fast build and symbol verification lets you establish that within 24 hours.

Are connected devices placed on the EU market before 11 December 2027 exempt from Article 14 reporting?

No. While units placed on the market before 11 December 2027 are generally exempt from the full essential requirements unless substantially modified, Article 14 reporting has applied since 11 September 2026 across in-scope products, including non-EU manufacturers selling into the EU. See our EU refrigeration controller incident briefing.

Is CRA reporting restricted to Linux kernel vulnerabilities?

No. Regulation (EU) 2024/2847 covers the product with digital elements as a whole, including user-space cryptographic libraries, network daemons, web interfaces, and manufacturer applications alongside the kernel.

Align engineering triage with your statutory reporting workflow.

Connect your pinned Yocto, Buildroot, OpenWrt, or Debian/CIP branches to repeatable exposure checks and structured ENISA notification preparation.