The EU Cyber Resilience Act's Article 14 reporting obligation has applied since September 11, 2026 — fifteen months before the CRA's December 2027 deadline. Manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities to ENISA within 24 hours of discovery, with a 72-hour follow-up and a 14-day final report.
Status (updated 15 September 2026): Article 14 reporting obligations have applied since 11 September 2026. If you're mid-incident right now, jump straight to EU CRA Reporting Is Live: Your First 24 Hours for the runbook — this article covers how the ongoing regime works.
Nearly every EU Cyber Resilience Act explainer leads with December 11, 2027 — the date the full essential cybersecurity requirements, including mandatory SBOM documentation, become enforceable. That date is real, but it wasn't the obligation that arrived first.
September 11, 2026 is when the CRA's reporting obligations under Article 14 became applicable — fifteen months before the December 2027 deadline. Since that date, manufacturers of "products with digital elements" sold in the EU must report actively exploited vulnerabilities and severe security incidents on a fixed timeline, or face the same top-tier fines as a full essential-requirements violation.
This piece is deliberately narrow: how the Article 14 reporting regime works now that it's live, who it applies to, and the SBOM groundwork you need running today. For the broader picture — SBOM formats, VEX, and the December 2027 requirements — see SBOM and the EU Cyber Resilience Act; for the next milestone on the CRA calendar, see EU CRA CE Marking: The December 11, 2027 Deadline.
Accuracy note: every date, deadline, and penalty figure below is cross-checked against the European Commission's official Cyber Resilience Act policy page and the regulation's Article 14 and Article 64 text as published on EUR-Lex, not secondary summaries alone. If you're making compliance decisions from this article, verify against the current regulation text for your specific situation — this is not legal advice.
What Changed on 11 September 2026
Meeting that 24-hour window requires an SBOM and automated vulnerability tracking already running — you cannot inventory what's in your software in 24 hours once an incident has already started.
Article 14 of Regulation (EU) 2024/2847 — the CRA's reporting obligation — has applied since September 11, 2026. This was a separate, earlier phase-in date than the CRA's main essential cybersecurity requirements (which apply from December 11, 2027) and separate again from the notified-body designation requirements (June 11, 2026).
Two categories of event trigger the obligation:
- An actively exploited vulnerability in your product — a vulnerability that is confirmed to be used in an attack (the closest practical proxy is a listing on CISA's Known Exploited Vulnerabilities catalog), not merely discovered or theoretical
- A severe incident that has an impact on the security of the product with digital elements
A vulnerability you find and patch before anyone exploits it does not trigger this reporting duty — that's handled through your ordinary vulnerability-handling process. The obligation exists specifically for the "someone is actively attacking this" case.
The detail most coverage misses: the reporting obligation applies to products already on the EU market, not just new products placed after a future date. The CRA's "substantial modification" transition rule — where an existing product only becomes subject to the full essential requirements after it's substantially modified post-December 2027 — does not exempt it from Article 14 reporting. If your product was on the EU market on September 11, 2026 — or is placed on it at any point after — the reporting clock applies to it regardless of when it shipped.
The Reporting Workflow: 24 Hours, 72 Hours, 14 Days
The 24-hour and 72-hour deadlines are both measured from the moment you become aware of the actively exploited vulnerability or severe incident. The final-report deadline is different — it runs from when a corrective measure becomes available (vulnerabilities) or from the incident notification (severe incidents), not from the original awareness moment.
| Stage | Deadline | What's required |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | A first notification that an actively exploited vulnerability or severe incident has occurred |
| Notification | Within 72 hours of becoming aware | A fuller account: initial assessment, severity, impact, and any corrective or mitigating measures already taken |
| Final report | Within 14 days of a corrective measure becoming available (vulnerabilities) or within one month of the notification (severe incidents) | Full description of the vulnerability or incident, its severity and impact, and the remediation applied |
Reports go through the CRA Single Reporting Platform, built and operated by ENISA as the common entry point. You submit once, to the CSIRT designated as coordinator for the Member State of your main establishment, with the submission simultaneously made accessible to ENISA; the receiving CSIRT then disseminates it without delay to the CSIRTs of other Member States where your product is marketed (subject to limited exceptions). Manufacturers with no main establishment in the EU report through a different route — check Article 14's provisions for your specific situation. ENISA had the platform targeted for operational readiness alongside the reporting obligation on September 11, 2026 — if you haven't confirmed your registration and access are live, do it now rather than during your first incident.
Who Has to Report — and What It Costs to Miss
The CRA defines "manufacturer" broadly: any entity that places a product with digital elements on the EU market under its own name or trademark. That covers SaaS vendors distributing client applications or SDKs into the EU, companies embedding open-source components in commercial products, and hardware makers shipping firmware — even headquartered outside the EU.
The penalty tier is worth naming precisely, because it's commonly understated. Violations of Article 14 reporting obligations sit in the same top penalty tier as violating the CRA's essential cybersecurity requirements under Annex I — up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 64 penalties). That's not a lesser "process violation" tier; missing the reporting obligation carries the same maximum exposure as shipping a non-compliant product after December 2027.
Two narrow exemptions apply, and both are narrower than they're often described. Administrative fines specifically for missing the 24-hour early-warning deadline do not apply to microenterprises and small enterprises (Article 64) — that carve-out covers the early-warning step only, not the 72-hour notification or final-report steps, and it doesn't remove the underlying obligation to report at all. The second exemption is narrower than its usual description too: "open-source software stewards" under Article 24 are exempt from administrative fines, but they are squarely in scope and carry the same reporting duty as manufacturers since September 11, 2026. Being fine-exempt is not the same as being obligation-free. A hobbyist maintaining FOSS outside commercial activity is a separate case again — outside the regulation entirely, since supplying unmonetised FOSS is not a "commercial activity" (Recital 18) — and a company shipping that code in its own commercial product gets neither carve-out. See the FAQ below for the full three-way distinction.
Some manufacturers report under more than one regime at once. A financial entity is separately on the hook for DORA's ICT third-party risk requirements, and an essential or important entity under NIS2 carries its own supply chain security obligations — the SBOM and vulnerability-tracking evidence built for CRA reporting covers most of what both ask for too.
SBOM Prerequisite Checklist: What You Need Running Now
You cannot issue a 24-hour early warning about a vulnerability in a dependency you don't know you ship. The practical prerequisite is the same inventory-plus-monitoring pipeline the December 2027 SBOM requirement eventually formalizes — just running months sooner than most compliance calendars assumed. If you don't have this pipeline running yet, you're already inside the reporting regime — start here, then read EU CRA Reporting Is Live: Your First 24 Hours for what to do if an incident hits before you finish.
- Generate an SBOM from your lock files (
package-lock.json,composer.lock,requirements.txt,go.sum,Cargo.lock,Gemfile.lock,packages.lock.json,pom.xml) using a tool like Syft or the CycloneDX CLI — see our SBOM Requirements 2026 Checklist for a step-by-step version - Wire SBOM generation into CI so every release produces a current, dated inventory instead of a stale one-time snapshot
- Run continuous vulnerability scanning against that inventory — not a one-off audit, since the reporting clock starts the moment you become aware, and you can't become aware of something you never check
- Layer in exploitation intelligence — CVSS severity alone can't distinguish "theoretically vulnerable" from "actively exploited." CISA KEV status is the closest practical proxy for "actively exploited" that the reporting obligation itself is built around
- Identify your CSIRT coordinator for your Member State of main establishment now, before you're on a 24-hour clock and researching reporting channels for the first time
- Draft your internal escalation path — who confirms active exploitation, who drafts the early warning, who has authority to submit — before an incident forces you to improvise one
- Confirm your manufacturer status — SaaS vendor, OSS-in-commercial-product integrator, or hardware/firmware maker — since obligations and exemptions differ by role
How GeekWala's SBOM Generator Fits
GeekWala's SBOM generator produces a standards-compliant SBOM directly from your lock file, in SPDX or CycloneDX — the two commonly used, machine-readable SBOM formats the industry has converged on for this kind of documentation. That inventory feeds directly into GeekWala's dependency scanning, which enriches every match with EPSS exploitation-probability scoring and CISA KEV status — the same "is this actually being exploited" signal that determines whether a vulnerability triggers the Article 14 reporting clock.
The workflow this replaces is manual: someone periodically checks a handful of dependencies against a CVE feed, with no continuous signal for when a previously benign vulnerability becomes actively exploited. A 24-hour early-warning deadline needs standing monitoring, not periodic review.
Frequently Asked Questions
Does the Article 14 reporting obligation require a full SBOM, like December 2027 does?
No. Article 14 is a reporting obligation for actively exploited vulnerabilities and severe incidents — it doesn't itself mandate a published SBOM; that's part of the essential requirements applying from December 11, 2027. In practice you need SBOM-equivalent visibility already running, since you can't meet a 24-hour deadline for a component you haven't inventoried.
Does this apply to software already sold in the EU, or only to new releases?
It applies to products already on the market. The CRA's "substantial modification" transition rule, which lets pre-2027 products avoid the full essential requirements until modified, does not extend to Article 14 — that has applied since September 11, 2026 regardless of when the product shipped.
What counts as an "actively exploited vulnerability" versus a routine CVE?
A routine CVE is a known weakness, patched or not. An actively exploited vulnerability is confirmed to be used in real attacks — commonly evidenced by inclusion in the CISA Known Exploited Vulnerabilities catalog or direct confirmation against your product. A vulnerability you patch proactively, before exploitation is observed, does not trigger the reporting clock.
Who receives the report — a single EU authority, or my national regulator?
You submit once, through the CRA Single Reporting Platform operated by ENISA, addressed to the CSIRT coordinator for your Member State of main establishment, made simultaneously accessible to ENISA. That CSIRT then disseminates it without delay to the CSIRTs of other Member States where your product is marketed, so you aren't filing separately per country.
Are startups and small teams exempt from the reporting obligation itself?
No — the obligation applies regardless of company size. What's exempted for microenterprises and small enterprises is the administrative fine for missing the 24-hour early-warning deadline specifically (not the 72-hour or final-report steps); the duty to report still applies.
Open source is often lumped in here, but two separate mechanisms get confused. Someone maintaining free and open-source software outside any commercial activity falls outside the CRA entirely — supplying FOSS that is not monetised is not a "commercial activity" (Recital 18) — not a manufacturer, no obligations at all, so there is no fine to be exempt from. A distinct category, the "open-source software steward" under Article 24 (typically a foundation sustaining a FOSS product intended for commercial use), is in scope and carries real duties since September 11, 2026 — a documented cybersecurity policy and the same actively-exploited-vulnerability reporting obligation as a manufacturer — but is exempted from administrative fines under Article 64 for getting it wrong. A company shipping that open-source code inside its own commercial product is a manufacturer under Article 3 and gets neither carve-out.
The 24-hour clock is already running. Know what you're shipping.
Generate an SBOM from your lock file → and pair it with GeekWala's dependency scanning — EPSS exploitation probability and CISA KEV status on every match, so you can tell "vulnerable" from "actively exploited" before a regulator asks you to.
