The Clock, Restated
Our April roadmap laid out the full CRA compliance timeline and a quarter-by-quarter checklist. Three months later, the milestone that matters most has moved from "coming up" to "imminent": from September 11, 2026, CRA-scoped manufacturers must report actively exploited vulnerabilities and severe incidents through a single mandatory channel, on an aggressive clock.
| Report | Deadline | Content |
|---|---|---|
| Early warning | 24 hours from awareness | Initial notification that an actively exploited vulnerability exists |
| Full notification | 72 hours from awareness | Detailed assessment, including severity and initial impact |
| Final report | 14 days after a corrective measure is available | Root cause, remediation, and full impact assessment (for exploited vulnerabilities) |
| Severe incident final report | Within 1 month | Equivalent closing report for qualifying severe incidents, as opposed to vulnerabilities |
Reporting happens once, through the CRA Single Reporting Platform (SRP), addressed to the CSIRT where the manufacturer has its main establishment — with the information made available to ENISA simultaneously in the ordinary course, barring exceptional circumstances. One submission, routed correctly, is meant to satisfy the obligation across the relevant national and EU-level recipients.
As of June 29, 2026, the ENISA Single Reporting Platform had not gone live. The stated expectation is that it will be operational by the September 11 date of application, with a testing period beforehand — but that leaves a narrowing window for manufacturers to validate their submission process, integrations, and internal escalation paths against the actual production system before the obligation becomes enforceable.
This Is Not Only About New Products
One detail from the April roadmap is worth restating with more force now that the deadline is close: the reporting obligation is not limited to products newly launched or actively in development. It applies retroactively to products already placed on the EU market before the CRA enters full application — meaning organizations cannot scope their CRA program to "whatever we ship next" and consider themselves covered.
If your organization has products with digital elements already sold into the EU — including ones no longer under active development — those products are in scope for the September 11 reporting obligation if a qualifying vulnerability or incident affects them. An inactive product team is not the same thing as an out-of-scope product.
The NVD Collision Nobody Planned For
Separately from anything CRA-related, NIST changed how the National Vulnerability Database prioritizes its own work — and the timing could not be worse for organizations trying to build a 24-hour vulnerability triage pipeline this summer.
Starting April 15, 2026, NIST moved to a selective enrichment model, driven by a 263% increase in CVE submission volume between 2020 and 2025. Under the new policy, NVD prioritizes enrichment — CVSS scoring and supporting detail — for CVEs that appear in CISA's Known Exploited Vulnerabilities (KEV) catalog, affect software used within the U.S. federal government, or qualify as critical software under EO 14028. Everything else is still listed, but treated as lowest priority and not enriched on any defined timeline. CVEs with an NVD publish date earlier than March 1, 2026 that had not yet been enriched were moved into a "Not Scheduled" backlog category entirely.
On June 17, 2026, NVD separately began providing Stakeholder-Specific Vulnerability Categorization (SSVC) data alongside traditional CVSS scores, sourced from CISA as an Authorized Data Publisher — a genuine improvement in decision-support quality, but one that inherits the same prioritization gap: it is only available for CVEs NVD actually gets around to processing.
| NVD Change | Effective | Effect on CRA Triage |
|---|---|---|
| Selective enrichment (KEV / federal / EO 14028 only) | April 15, 2026 | Most open source components used in EU CRA-scoped products fall outside the priority list |
| Pre-March-2026 backlog → "Not Scheduled" | April 15, 2026 | Older CVEs in your dependency tree may never receive a CVSS score from NVD |
| SSVC data via CISA-ADP | June 17, 2026 | Better decision support, but only for CVEs that do get processed |
For a U.S. federal contractor, this reprioritization is arguably rational — NVD is directing scarce analyst time toward the vulnerabilities most likely to matter to its primary audience. For a European manufacturer trying to determine, within 24 hours, whether a vulnerability in a general-purpose open source dependency is severe enough to trigger an ENISA early warning, it means the authoritative U.S. government source they may have been leaning on can no longer be assumed to answer that question quickly, or at all.
There is a broader accountability thread here too: a federal watchdog review concluded that without significant changes to how the NVD program is run, it will not be able to fulfill its mission, and gave NIST until July 25, 2026 to submit a formal action plan. That date lands two weeks after this article — worth watching, since any resulting changes will land squarely inside the CRA's final compliance runway.
What This Means in Practice
The practical conclusion is the same one we reached after 2025's NVD backlog crisis, now with sharper urgency: an EU CRA vulnerability triage process cannot be built on the assumption that NVD will hand you a severity score inside your reporting window. Organizations need triage capability that draws on multiple sources — OSV, GitHub Advisory Database, vendor advisories, and internal exploitability assessment — so that a component sitting in NVD's "Not Scheduled" backlog does not also sit unscored in your own CRA reporting pipeline.
Where Organizations Actually Stand, Three Months In
Against the Q2 2026 milestones set out in April, most organizations we talk to are behind on at least one item — and for a specific, external reason on the ENISA side:
- Product classification — largely on track where teams started in Q1; still incomplete at organizations that treated CRA as a Q3 problem.
- SBOM generation in build pipelines — the most consistently completed milestone, unsurprising given most CRA-scoped organizations already had SBOM programs pre-dating the regulation.
- ENISA SRP registration and test submissions — effectively blocked for everyone, since the platform itself was not live as of late June. This is not an organizational failure; it is a dependency on infrastructure the manufacturer does not control.
- Vulnerability triage process — the milestone most exposed by the NVD changes above. A triage process designed around NVD as the primary severity source needs revisiting now, not in August.
Multi-Source Vulnerability Intelligence for CRA Triage
Fossity aggregates vulnerability data from NVD, OSV, GitHub Advisory Database, and ecosystem-specific sources into a single prioritized feed — so your 24-hour CRA triage window does not depend on whether NIST has gotten around to enriching a given CVE. Get the severity signal you need on your timeline, not NVD's.
Build Your CRA Triage Pipeline with Fossity →The Remaining 63 Days
- Now: Stress-test your vulnerability triage process against components that will not receive a fast NVD score — confirm you have a fallback severity source.
- Now: Confirm which legacy, already-shipped products fall inside CRA scope, not just current development lines.
- As SRP testing opens: Register and complete a test submission the moment ENISA's platform accepts one — do not wait for September 11 to discover an integration problem.
- Before September 11: Run a tabletop exercise: simulate an actively exploited vulnerability disclosure and time your organization's path from detection to a compliant 24-hour early warning.
- After September 11: Treat the first live reporting cycle as a process audit, not just a compliance event — the gaps that show up under real time pressure are the ones tabletop exercises miss.