Nearly every EU Cyber Resilience Act explainer leads with December 11, 2027 — the date full essential cybersecurity requirements, including mandatory SBOM documentation, become enforceable. That date is real, but it isn't the deadline that hits first.
September 11, 2026 is when the CRA's reporting obligations under Article 14 become applicable — fifteen months earlier. From 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: what changes on September 11, 2026, how the reporting workflow works, who it applies to, and the SBOM groundwork you need in place before then. For the broader picture — SBOM formats, VEX, and the December 2027 requirements — see SBOM and the EU Cyber Resilience Act.
Accuracy note: every date, deadline, and penalty figure below is cross-checked against the European Commission's official CRA reporting summary 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 Changes on September 11, 2026
Article 14 of Regulation (EU) 2024/2847 — the CRA's reporting obligation — applies from September 11, 2026. This is 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, 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 is on the EU market on September 11, 2026, 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. The platform is expected to be operational by September 11, 2026, with a testing window beforehand — as of mid-2026 it's still under active development, so build in time to register and test rather than assuming day-one availability.
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). That's not a lesser "process violation" tier; missing the September 2026 reporting deadline 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 from 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.
SBOM Prerequisite Checklist: What to Have in Place Before September 2026
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 assume.
- 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 September 11, 2026 deadline 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 well before September 2026, 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 new releases after September 2026?
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 applies from 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 from 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.
Know what you're shipping before the 24-hour clock starts.
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.
