What to do with a vulnerability finding: CRA triage explained
Your scanner flagged a CVE — now what? The CRA triage flow: assess severity and reachability, then decide fix-now, planned fix, not applicable, or accepted risk — and record every decision as the compliance artifact.
Not sure if you’re in scope?
Run the free 3-minute scope check for your product and get your risk class, deadlines and obligations.
Check if the CRA applies to youIn short
When vulnerability monitoring or an SBOM scan surfaces a finding, the CRA does not require you to fix everything — it requires you to triage each finding and record the decision. Assess severity, exploitability and whether the vulnerable component is actually reachable in your product, then choose one of four outcomes: fix now, planned fix, not applicable, or accepted risk with justification. Every decision must be recorded as part of your vulnerability-handling process; the record is the compliance artifact. If a vulnerability is being actively exploited, it stops being triage and becomes a reportable incident — the 24-hour ENISA clock starts.
You run an SBOM scan or your monitoring fires an alert, and a CVE lands on your desk. The instinct is either to panic-patch or to ignore it. The EU Cyber Resilience Act asks for neither. It asks for a decision — a defensible, written one — on every finding. The Black Duck OSSRA report has found an average of 581 vulnerabilities per commercial codebase (it varies by year and report), so "fix everything immediately" is not a plan. Triage is.
This guide walks the decision flow from a raw finding to a recorded outcome, and shows the one line that turns ordinary triage into a reportable incident.
Not sure the CRA applies to your product? Run the free 3-minute scope check first.
What the CRA actually requires
The CRA (Regulation (EU) 2024/2847) does not say "have zero vulnerabilities." No product with digital elements ever will. What it requires is a vulnerability-handling process: you identify and document the components in your product, you monitor them for new vulnerabilities, and you handle each one without undue delay. "Handle" is the load-bearing word — it means reach a decision and act on it, not necessarily patch on sight.
The part teams miss is the second half of the duty: the process only exists if it is recorded. A fix you shipped without a note explaining why leaves no trail; an authority or an enterprise customer asking "how did you assess CVE-2026-XXXX?" cannot be answered by "we looked at it." Under the CRA the record of your decision is the compliance artifact — not the fix itself.
Step 1: is it exploitable, and is it reachable?
Before you decide what to do, you assess two things that a raw CVE score does not tell you:
- Severity and exploitability. Start with the CVSS score, but do not stop there. Is there a known exploit in the wild? Is it in EPSS or a CISA-style known-exploited list? A critical-scoring bug with no public exploit and a paid-hardware precondition is a different animal from a medium-scoring one being sprayed across the internet.
- Reachability. Is the vulnerable component actually used in your product, in the code path that ships? A library can appear in your SBOM but be dead code, a build-time-only dependency, or a function you never call. A vulnerability in a feature you compile out is not the same risk as one in your network-facing parser.
Most of the noise from a scanner dies at this step. The finding that survives — reachable, exploitable, in the shipped product — is the one that needs a real decision.
Step 2: choose one of four outcomes
Every finding resolves to exactly one of these. Recording which one, and why, is the whole exercise.
| Decision | When it applies | What you record |
|---|---|---|
| Fix now / security update | Reachable, exploitable, meaningful severity. The finding is a live risk to users. | The CVE, the affected versions, the fix or mitigation, and the date the security update shipped. |
| Planned fix | Real but lower-urgency: reachable but hard to exploit, or a fix that needs a coordinated release. | The decision to schedule, the target release or date, and the interim mitigation if any. |
| Not applicable / not reachable | The component is present but the vulnerable code path is not used, compiled out, or unreachable in your product. | The reasoning for non-reachability — which is the evidence you will be asked for. |
| Accepted risk (with justification) | Reachable but the residual risk is judged acceptable — e.g. a trusted-network-only feature, or a compensating control. | The justification, who signed off, and a review date to revisit it. |
Two of these four — "not applicable" and "accepted risk" — are the ones people treat as "do nothing." Under the CRA they are the opposite: they are decisions that must be argued in writing. "Not reachable" with no explanation is not a triage outcome; it is a gap. The justification is what protects you when someone re-opens the finding a year later.
Step 3: record it — the record is the artifact
Whichever outcome you pick, the entry in your vulnerability-handling log is the deliverable. A usable record for one finding contains: the identifier (CVE or advisory), the affected component and version from your SBOM, the assessed severity and reachability, the decision, the justification, the owner, and the date. Do that per finding, per product, and you have a vulnerability-handling process that survives an audit — because the process is the log.
This is also where a spreadsheet quietly fails: it captures the decision but not the link back to which product version and which SBOM entry the finding applies to, and it never tells you when a "planned fix" or an "accepted risk" is overdue for review.
Most findings are noise, but every real one needs a written decision — and a spreadsheet loses the link between the CVE, the product version and who signed off.
Nordchecks matches new vulnerabilities against your SBOM, filters out what is not reachable, and records each triage decision as the CRA-ready artifact automatically.
Try Nordchecks freeThe escalation line: when triage becomes an incident
There is one condition that takes a finding out of the triage flow entirely. If the vulnerability is being actively exploited — there is evidence someone is using it against your product in the wild, not merely that a CVE exists — it is no longer something you schedule. It is a reportable incident, and the 24-hour ENISA clock starts from the moment you become aware.
From 11 September 2026, a manufacturer aware of an actively exploited vulnerability must file an early warning to ENISA and its national CSIRT within 24 hours, weekends included, followed by a notification within 72 hours and a final report within 14 days. The trigger is exploitation, not severity: a modest-scoring bug that is being exploited outranks a critical one that is not. The moment your assessment in Step 1 finds active exploitation, stop triaging and start reporting — see our ENISA 24-hour reporting guide for the exact filings and our incident reporting clock for how the deadlines run.
The support-period duty behind all of this
Triage only matters because you owe your users fixes. Under the CRA, for the product's support period — at least 5 years unless the expected use is shorter — you must make security updates available for handled vulnerabilities. Two details matter for triage. First, security updates are a separate obligation from feature updates: you cannot bundle a security fix behind a paid upgrade, and you cannot let it lapse because the product is "end of sale." Second, security updates must be provided free of charge. A "planned fix" that never ships, or a fix locked behind a paywall, is not compliance — it is the gap the support-period duty exists to close.
The triage flow, summarised
- Finding arrives (scan or monitoring alert) → match it against your SBOM
- Assess: severity, exploitability, and is the component reachable in the shipped product?
- Actively exploited? → stop; it is a reportable incident, start the 24-hour clock
- Otherwise decide one: fix now, planned fix, not applicable, or accepted risk
- Record the decision, the justification, the owner and the date — this is the artifact
- Ship security updates free for the support period, and revisit every "planned" and "accepted" item on its review date
Get this running and vulnerability findings stop being emergencies. The same discipline — SBOM, monitoring, a written decision per finding — is most of what the December 2027 full-compliance deadline expects anyway. If you would rather not wire it together in a spreadsheet, CRA compliance software keeps the SBOM, the monitoring and the triage log in one place so each decision is recorded as you make it.
Start with the foundation: check your product's scope and risk class free — three minutes, no signup.