The CRA vulnerability reporting obligation starts on 11 September 2026. That is just over three months away. The Article 14 reporting timeline is demanding: a 24-hour early warning, a 72-hour notification with initial details, and a final report deadline that depends on the event type. Teams without a working vulnerability intake and classification process will not meet that cadence.
The next CRA milestone is 11 June 2026, when provisions on notification of conformity assessment bodies start applying and Member States must designate notifying authorities. 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 for product teams because it requires a working reporting 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. Final reports then require the full picture: timeline, root cause, complete impact scope, and remediation steps taken. For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure is available. For severe incidents, it is due within one month.
"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.
SBOM_TOOLING_AND_PRACTICAL_IMPLEMENTATION
A Software Bill of Materials is a machine-readable list of the components — libraries, frameworks, and dependencies — that make up a released product. The CRA does not mandate a specific SBOM format, but the two formats with broad tooling support are SPDX and CycloneDX. Both are supported by the major SBOM generation tools, and both are accepted by ENISA in its published guidance on SBOM practices for the CRA.
SBOM generation is integrated into most modern build pipelines through tools like Syft, cdxgen, or native support in package managers. The generation step is usually straightforward. The harder operational problem is maintaining SBOM accuracy over time: every dependency update, every build configuration change, and every new third-party library needs to be reflected in the SBOM for the corresponding release. An SBOM that is generated once at initial compliance work and not updated with releases provides false confidence and will fail its purpose in a CVE response scenario.
The use case SBOM solves for the CRA is rapid component identification during vulnerability disclosure. When a new CVE is published for a widely-used library, the question is immediate: which of your products and which released versions contain that component? Without SBOM practice, answering that question requires manual archaeology across every product's dependency tree, often taking days. With an up-to-date SBOM per released version, it is a query against a maintained list that takes minutes.
- Integrate SBOM generation into the release pipeline, not as a separate manual step. SBOMs generated outside the build process have provenance problems that create issues in audit and CVE response scenarios.
- Store SBOMs per released version, not just for the current version. Historical SBOM records are needed to respond to vulnerabilities in past releases that may still be in use.
- Choose a format with tooling support and stick to it — SPDX and CycloneDX both work; mixing formats across products creates query and analysis problems.
- Test the CVE response workflow: given a new CVE for a known component, can you identify all affected product versions and released instances within one hour? If not, the SBOM implementation is not yet operationally useful.
RUNNING_A_TABLETOP_AGAINST_ARTICLE_14
A tabletop exercise for the Article 14 reporting timeline involves a facilitator presenting a realistic scenario — an actively exploited vulnerability discovered in your product — and walking the response team through the 24-hour early warning, 72-hour notification, and final-report obligations in real time. The objective is not to produce a perfect simulated report. It is to identify where the process breaks down before September 2026 rather than during the first real event.
The breaks that surface most reliably in tabletop exercises are: no documented definition of what "actively exploited" means for your classification criteria, no agreed escalation path from the engineering team that discovers the vulnerability to the person authorized to file the ENISA report, missing technical information required for the 72-hour notification (affected versions, severity, available mitigations), and unclear ownership of the final report when the incident spanned multiple teams.
Running the tabletop before the September 2026 deadline gives you time to update the classification criteria, update the escalation documentation, and assign clear ownership for each reporting obligation. Running it after the deadline means your first real event is also your first real test of a process that has never been exercised.