The CRA vulnerability reporting obligation starts on 11 September 2026. That is five months away. The reporting timeline under Article 14 is demanding: a 24-hour early warning when a vulnerability is actively exploited, a 72-hour notification with initial details, and a final report within a month of discovery. Teams without a working vulnerability intake and classification process will not meet that cadence.
CRA Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. Most other manufacturer obligations apply from 11 December 2027. The September date is the better forcing function because it requires a working process, not just a policy document.
WHAT_THE_REPORTING_TIMELINE_ACTUALLY_REQUIRES
The 24-hour early warning is the hard one. It assumes your team can identify that a vulnerability is being actively exploited, classify it as significant, and file an initial report to ENISA — within one working day of discovery, not within one working day of completing the investigation. That requires a detection path, a written classification criteria document, and clear ownership for who initiates the filing. Most organisations do not have that sequence documented today.
The 72-hour notification expands on the early warning with a description of the vulnerability, an initial severity assessment, and available mitigation information. The 30-day final report then requires the full picture: timeline, root cause, complete impact scope, and remediation steps taken.
"Regulation lands as workflow long before it lands as paperwork."
SBOM_AND_ASSET_INVENTORY
ENISA has published guidance on SBOM practices in the context of the CRA. The practical requirement is being able to identify which of your products contain a given component when a vulnerability in that component is publicly disclosed. Without SBOM practice, finding out which products are affected by a new CVE is a manual archaeology exercise that takes days. With one, it is a query against a maintained list.
- Maintain a live inventory of products, supported versions, and their component dependencies — not a static document from the last major release cycle.
- Define what "actively exploited vulnerability" means in your classification criteria now, before the first real event forces a judgment call under pressure.
- Document the intake-to-report escalation path with named owners at each decision point, including who can approve a regulatory filing.
- Run a tabletop exercise against the Article 14 reporting timeline before September 2026 — not after.
THE_2027_WORK_STARTS_NOW
The December 2027 general obligations require security by design, secure defaults, documented update mechanisms, and formalized post-sale support commitments. Most software organizations have not yet written those down in a form that would survive a conformity assessment. Starting the product documentation, vulnerability handling policy, and secure development evidence now creates a much cleaner path to that milestone than treating it as a separate compliance program in late 2026.