Can You Triage in 24 Hours? Why Manual CRA Vulnerability Triage Breaks, and What to Automate First
The Cyber Resilience Act's reporting clock is short, and most of it is spent answering one question: are we affected? Teams that answer it from memory, spreadsheets and Slack threads will struggle to send an early warning inside 24 hours. Teams that can query their own SBOMs against a live feed of exploited vulnerabilities will not.
This is general guidance, not legal advice.
TL;DR
- Since 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products through ENISA's Single Reporting Platform: early warning within 24 hours, notification within 72 hours, and a final report 14 days after a corrective measure is available (Commission: CRA reporting).
- The slow part is rarely the form. It is working out whether a vulnerable component ships in a supported product, in which versions, and whether it is really being exploited.
- Automate the lookup (SBOM per release, feed matching, version-to-customer mapping). Keep the judgement human (is it exploited, do we report, what do we say).
- You can build a workable version in about 30 days without buying anything.
What the clock starts on
The CRA ties the obligation to the manufacturer becoming aware of an actively exploited vulnerability. Awareness is a fact pattern, not a feeling: an advisory lands, a customer reports abuse, a threat feed flags a component you ship. Write down, ahead of time, which signals count as "aware" for your organisation and who can declare it. If that decision takes three days of internal debate, the debate has used your 24 hours.
For how to judge whether something qualifies as actively exploited, see our guide to identifying an actively exploited vulnerability. For who owns the clock, see the CRA never says PSIRT.
Why manual triage breaks
Recent commentary is blunt about this. CSO Online (2 October 2026) quotes Joe Brinkley of Cobalt: "You just can't expect an analyst to catch a KEV alert, manually grep a static SBOM, and then dig through SIEM logs." The article points out that the relevant data usually lives in five or six disconnected systems: SIEM, threat feeds, KEV alerts, scanners, asset inventories and SBOMs.
None of that is a CRA requirement in itself. The CRA does not tell you which tools to use. But a 24-hour clock turns every slow lookup into a compliance risk.
The "are we affected?" chain
Every triage, automated or not, walks the same four questions:
- Which component? A KEV entry, vendor advisory or customer report names a library, firmware blob or protocol stack.
- Do we ship it? Search your SBOMs across all supported products and versions, including transitive dependencies where you have them.
- Is the vulnerable version actually out there? Map component versions to product releases, then releases to units or customers still running them.
- Is it being exploited against our product? Check logs, telemetry, support tickets and external reports. This is the step that decides whether Article 14 is triggered.
Questions 1 to 3 are lookups. Question 4 is judgement. Automate the first three so people can spend their 24 hours on the fourth.
What to automate first
1. Store an SBOM for every release, in a queryable place. A PDF in a shared drive is not queryable. Generate CycloneDX or SPDX in CI, and keep it in a store you can search by component name and version. Our SBOM starter guide covers formats. Note that the CRA expects a machine-readable SBOM but harmonised standards on the details are still being developed, so keep your pipeline format-flexible.
2. Match feeds against that store automatically. Pull the CISA Known Exploited Vulnerabilities catalogue and the advisories you already follow, and match them against stored SBOMs on a schedule. The output should be a short list: product, version, component, CVE. As Brinkley puts it in the CSO article, the infrastructure needs to "automatically query the SBOM, pinpoint affected assets, and cross-reference live telemetry".
3. Maintain a version-to-customer map. Know which releases are in the field, and which are past support. This answers "who is exposed?" and feeds your later user notifications.
4. Pre-draft the early warning. The 24-hour early warning is deliberately light. Prepare a template with product identity, suspected exploitation, and Member States affected where known, so a person fills in facts instead of writing from scratch.
What must stay human
- Deciding that exploitation is active rather than theoretical.
- Deciding to report, and what to say about impact.
- Choosing mitigation advice for users.
- Calling a severe incident when the facts are unclear.
An alert that auto-submits a report is a liability. An alert that wakes the right person with a pre-filled draft is the goal.
The other clocks
The 24h/72h structure also applies to severe incidents, with a final report within one month rather than 14 days (Checkmarx, 1 October 2026). If you also fall under NIS2 or GDPR, the same event may start more than one clock. We compare them in One Incident, Four Clocks.
A 30-day plan
Week 1: Define "aware", name the decision owner and a backup, and register on the Single Reporting Platform.
Week 2: Generate SBOMs for every supported release in CI and put them somewhere searchable.
Week 3: Wire a KEV feed match against that store. Send results to a channel someone actually watches.
Week 4: Run a tabletop. Inject a fictional KEV entry for a library you ship, start a stopwatch, and see how far you get in four hours, then in 24.
A tabletop outline you can reuse
- Inject: "A component in your gateway firmware appears on the KEV list at 09:00 on a Friday."
- Measure: time to identify affected products, time to confirm versions in the field, time to a go/no-go on exploitation, time to a submitted early warning.
- Debrief: which step was slowest, and was it a data problem or a decision problem?
If the slowest step was data, automate it. If it was a decision, write down who decides.
What is still moving
The detail of SBOM fields and vertical product standards is still being drafted, and the Commission's guidance is still being finalised in all languages. Build your pipeline so those details can change without rebuilding it. Official sources: Regulation (EU) 2024/2847, ENISA Single Reporting Platform.
Where to go next
See every date on the CRA deadlines page, and subscribe to The CRA Brief for updates as the standards land.
Related reading
CRA Automatic Security Updates: Default-On, Opt-Out, and Kept Separate From Feature Updates
The CRA expects security updates to install automatically by default, with an easy opt-out. Here is what that means in practice, where "where applicable" gives you room, and how to design it.
Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
Article 14 reporting has been live for three weeks. Here is what early users of ENISA's Single Reporting Platform report, what a "disclosure delay" does and does not change, and the four things worth doing this week.
CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The CRA says your SBOM must be machine-readable but not what fields it needs. Here is what goes inside, which CycloneDX and SPDX versions still count, and why VEX is optional.