CRA vulnerability handling records
Sytance · Updated
Vulnerability handling records show how the manufacturer finds, documents, assesses, remediates, discloses, and communicates vulnerabilities during the support period.
Process duty
Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I.
Regulation (EU) 2024/2847, Article 13(8)
The duty starts when the product is placed on the market and continues during the support period. It covers the product and its components.
Main record types
Annex I requires the manufacturer to identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies.
Records should show how vulnerabilities were assessed, addressed, remediated, and distributed through security updates when needed.
Annex I requires a coordinated vulnerability disclosure policy. Annex VII asks for the policy and evidence of the contact address for vulnerability reports.
Annex I requires effective and regular tests and reviews of product security. Annex VII asks for reports of tests carried out to verify product and process conformity.
Example: from a component alert to closure
Consider a fictional parser vulnerability in a controller firmware release. The six records below form an example case history. They show how a team can connect intake, product impact and remediation; the sequence is not a CRA-prescribed form.
- Intake: record when the report arrived, its source, the component and vulnerability identifier, and the information available at that time. Preserve the original report.
- Product impact: use the SBOM and build records to identify candidate releases. Confirm whether an attacker can reach the affected parser in each supported configuration; record both the evidence and remaining uncertainty.
- Reporting decision: evaluate Article 14 immediately if there is evidence of active exploitation or a severe product-security incident. Record awareness times and submit required reports within the applicable deadlines while technical investigation continues.
- Treatment: assess the product risk, assign the fix or mitigation, and coordinate with the component maintainer where relevant. Retain the chosen action and its reason.
- Verification and release: test the corrected parser and the affected product functions, retain the tested build, and link the security update, distribution evidence and user instructions.
- Closure and follow-up: record the verified outcome, updated component inventory, user communication and disclosure. Keep any affected supported version without an effective remedy open for further action.
The case record should distinguish completion of the internal fix, submission of any required report, and delivery or installation of the update. For example, a fix may be published while some affected users still need to install it and require follow-up.
Annex VII link
Annex VII asks the technical documentation to include necessary information and specifications for the vulnerability-handling processes, including the SBOM, the coordinated vulnerability disclosure policy, the reporting contact, and secure update distribution.
- records that support the product's vulnerability history;
- records that explain how vulnerabilities are triaged and fixed;
- records that show update distribution and user communication;
- test and review reports that support conformity assessment.
The draft prEN 40000-1-3 page explains the current vulnerability-handling standard draft in more detail.
Records are not the report trigger
These records support vulnerability handling. Article 14 reporting is a separate duty triggered by actively exploited vulnerabilities and severe product-security incidents.