A manufacturer triages a vulnerability report under the Cyber Resilience Act by confirming the report, scoring severity and exploitation evidence, deciding Article 14 reportability, and fixing in order of risk, as Annex I Part II requires.
Key takeaways
- Annex I Part II point (2) of the Cyber Resilience Act requires manufacturers to remediate vulnerabilities without delay, in relation to the risks posed, and sets no fixed number of days.
- An EPSS score is a forecast, so a high EPSS score raises priority but never makes a vulnerability "actively exploited" under Article 3(42).
- The Article 14 early warning is due within 24 hours of awareness of an actively exploited vulnerability, and an advisory embargo does not stop that clock.
- Annex I Part II point (4) allows a manufacturer to delay publication of a fixed vulnerability in duly justified cases, until users have had the possibility to patch.
- The end date of the support period must be specified at the time of purchase, with at least the month and the year, per Article 13(19).
What does the CRA require once a vulnerability report arrives?
The Cyber Resilience Act requires a documented process that identifies, assesses, fixes and discloses vulnerabilities for the whole support period. The obligations sit in Annex I Part II of Regulation (EU) 2024/2847 (CELEX 32024R2847), and the reporting duty sits in Article 14.
The Regulation does not name a triage method. Each obligation in the table below still depends on one, because a manufacturer cannot remediate "in relation to the risks posed" without first measuring the risk.
| Annex I Part II point | Obligation | What triage must produce |
|---|---|---|
| (1) | Identify and document vulnerabilities and components, including an SBOM | The affected components and versions |
| (2) | Address and remediate vulnerabilities without delay, in relation to the risks posed | A priority based on risk |
| (4) | Publicly disclose information about fixed vulnerabilities, including severity | A severity rating and an advisory text |
| (5) | Put in place and enforce a policy on coordinated vulnerability disclosure | Agreed dates with the reporter |
| (6) | Facilitate the sharing of information, including a contact address | An acknowledged report |
| (8) | Disseminate security updates without delay, free of charge, with advisory messages | A release decision |
What happens during security triage?
Security triage turns a raw report into a decision with an owner and a date. The first pass answers four questions. Is the report valid? Is it a duplicate? Which products and versions does it affect? Is there evidence of exploitation?
A useful second pass classifies the weakness. The Common Weakness Enumeration, maintained by MITRE, names the type of flaw, for example CWE-79 for cross-site scripting or CWE-787 for an out-of-bounds write. A CWE does not change the severity of one report. Counted over a year, CWE classes show which development practice keeps failing, which feeds the Annex I Part I risk assessment for the next release.
The output of triage is a record that a market surveillance authority can read later. It holds the date of receipt, the affected versions, the scores, the exploitation evidence, the Article 14 decision and the planned fix date.
Which signals set the priority?
Severity and likelihood are separate measurements, and a manufacturer needs both. CVSS measures how bad a vulnerability is if exploited. The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability that a CVE is exploited in the wild in the next 30 days.
| Signal | Source | What the signal answers | Limit |
|---|---|---|---|
| CVSS v3.1 or v4.0 base score | FIRST specification, scored by the manufacturer or the CNA | How severe is the impact? | Says nothing about likelihood |
| EPSS probability | FIRST, updated daily | How likely is exploitation in the next 30 days? | A forecast for published CVEs only |
| Exploitation evidence | CISA KEV catalogue, the EUVD, CSIRT alerts, own telemetry | Is a malicious actor exploiting it now? | Absence of evidence is not proof of safety |
| CWE class | MITRE CWE | What type of weakness is it? | Classifies, does not rank |
| Affected versions | SBOM matched against OSV or the NVD | Which shipped products contain it? | Only as good as the SBOM |
The line between EPSS and evidence matters for Article 14. Article 3(42) defines an actively exploited vulnerability as one "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". An EPSS score of 0.9 is a strong reason to fix first. An EPSS score is not reliable evidence of exploitation, so it never starts the 24-hour clock alone.
How do SCA and OSV find vulnerable components?
Software composition analysis identifies the open-source and third-party components in a product and checks each one against vulnerability databases. An SCA tool can produce the SBOM that Annex I Part II point (1) requires, and can show when a new advisory affects a product already on the market.
OSV is an open vulnerability format and database that records affected package versions per ecosystem, for example npm, PyPI or Maven. Version-precise matching avoids the false matches that matching on product names can produce. An OSV query needs a package name with its ecosystem, a package URL, or a commit hash. A component with none of these, for example a C library copied into firmware, gets no OSV result at all, so an empty result for that component means "not checked", not "not vulnerable".
When is an advisory embargo justified?
An advisory embargo is an agreed period during which the reporter, the manufacturer and any coordinator keep a vulnerability private until a fix is ready. The coordinated vulnerability disclosure policy required by Annex I Part II point (5) is the right place to state how long a default embargo lasts and when it can be extended.
The Regulation supports a delay after the fix as well. Annex I Part II point (4) allows a manufacturer, in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, to delay public information about a fixed vulnerability until users have had the possibility to apply the patch.
An embargo controls public disclosure only. The Article 14 notifications go to the CSIRT designated as coordinator and to ENISA, not to the public, and an embargo with a researcher does not delay them. Article 14(2)(b) lets the vulnerability notification state how sensitive the manufacturer considers the notified information to be.
When does a vulnerability need a war room?
A war room is a short-lived team that runs the technical fix, the regulatory notifications and the customer communication at the same time. An actively exploited vulnerability in a product on the EU market is the clearest trigger, because Article 14 sets three clocks that run in parallel with the engineering work.
| Article 14(2) step | Deadline | Owner in the war room |
|---|---|---|
| Early warning | Without undue delay, within 24 hours of awareness | Regulatory lead |
| Vulnerability notification | Without undue delay, within 72 hours of awareness | Regulatory lead with engineering input |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Regulatory lead |
| Fix and advisory | Without delay, per Annex I Part II points (2), (4) and (8) | Engineering and product security |
Since 11 September 2026 these duties apply to every in-scope product on the EU market, including products placed on the market before 11 December 2027, per Article 69(3) and Article 71(2).
How can a manufacturer show that remediation happens without delay?
Measure the time from receipt of a report to the release of a fix, and report the result by severity. Mean time to remediate is the name of that metric. The Regulation sets no target in days, so the evidence is the record of decisions, not a single number.
Three practices make the metric useful to an assessor. Report a median per severity band as well as the mean, because one long-tail case distorts an average. Record the reason when a fix takes longer than the internal target, for example a dependency upstream with no patch. Keep the clock for actively exploited vulnerabilities separate, because those cases carry the Article 14 deadlines.
What happens to triage at the end of the support period?
The support period must be at least five years, unless the product is expected to be in use for less time, per Article 13(8). Article 13(19) requires the end date, with at least the month and the year, to be specified at the time of purchase, and Annex II point 7 puts that end date in the user information.
An end-of-life policy states what happens after that date. Triage still receives reports about unsupported versions. The policy should say how the manufacturer answers them, for example with a confirmation that no update will follow and a recommendation to upgrade, so a reporter is never left without a reply.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex, CELEX 32024R2847. Article 3(42), Article 13(8) and (19), Article 14(2), Article 69(3), Article 71(2), Annex I Part II and Annex II point 7 were checked against the text on 20 and 21 October 2026.
- FIRST, Exploit Prediction Scoring System and CVSS v4.0 specification.
- MITRE, Common Weakness Enumeration.
- OSV schema and database.
- CISA, Known Exploited Vulnerabilities catalog.
Run triage and Article 14 in one place
CVD Portal records each report with its affected products, a CVSS calculator for v3.1 and v4.0, and the Article 14 decision. Stored SBOMs are scanned against OSV.dev. A daily watch checks the CVEs a company is exposed to for KEV listings and exploitation sightings and shows the EPSS probability next to them. EPSS never raises the exploitation level, and a person always records the Article 14 determination. See how Article 14 filing works or create a free portal.
Frequently asked questions
Does the Cyber Resilience Act set a deadline to fix a vulnerability?
No. Annex I Part II point (2) requires manufacturers to address and remediate vulnerabilities without delay, in relation to the risks posed to the product. The Regulation sets no number of days. The fixed clocks in Article 14 apply to notifications of actively exploited vulnerabilities, not to the fix.
Does a high EPSS score make a vulnerability actively exploited under the CRA?
No. Article 3(42) defines an actively exploited vulnerability as one with reliable evidence that a malicious actor has exploited it in a system without permission. EPSS is a probability forecast, so it can raise priority but cannot start the 24-hour clock of Article 14 alone.
Can a manufacturer delay publishing a security advisory under the CRA?
Yes, in duly justified cases. Annex I Part II point (4) allows a manufacturer to delay public information about a fixed vulnerability until users have had the possibility to apply the patch, where the manufacturer considers the security risks of publication to outweigh the security benefits.
Which signals should a manufacturer use to prioritise a vulnerability?
Use CVSS for severity, evidence of exploitation such as the CISA KEV catalogue for urgency, EPSS for the probability of exploitation in the next 30 days, CWE for the weakness class, and the affected product versions from the SBOM.