A field-level template for recording components, vulnerability decisions, security updates, disclosure work, and technical documentation evidence under the EU Cyber Resilience Act.
Use it to connect engineering vulnerability work to CRA Annex I Part II, Article 13, Article 14, and Annex VII evidence without treating the SBOM as a public-format checklist.
Structured answer sets in this page tree.
Cited legal and guidance references.
The CRA makes component awareness part of vulnerability handling. Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including a in a commonly used, machine-readable format covering at least top-level dependencies. Annex VII places the SBOM, vulnerability handling process, disclosure policy, reporting contact, and secure update mechanism inside the technical documentation framework. These product and technical-documentation duties generally apply from 11 December 2027; Article 14 reporting starts on 11 September 2026 and also covers earlier in-scope products. This template is a controlled working record. It is not an official form and does not replace the product-specific cybersecurity risk assessment.
Start each SBOM and vulnerability record by fixing the exact product version it applies to. CRA technical documentation must identify the product, software versions affecting compliance, support-period information, and the vulnerability handling process. Product security or another named security owner should maintain the operational record; engineering, release, supplier, support, and regulatory owners should supply and approve the evidence they control.
Do not use one generic SBOM label for every build. Exposure, remediation, and user advisory decisions depend on the released version, supported branch, and update channel.
The CRA requires an SBOM in a commonly used, machine-readable format and says it must cover at least top-level dependencies. Regulation (EU) 2024/2847 does not name CycloneDX, SPDX, or another specific format; Article 13(24) allows the Commission to specify the format and elements by implementing act. Keep the record format-neutral until an applicable legal act, harmonised standard, customer requirement, or conformity route sets a more specific rule.
The useful operational record is broader than a dependency export. It should show why each integrated component does or does not affect the product's CRA risk assessment, vulnerability exposure, and update path.
SSOT can keep component records, vulnerability triage, Article 14 checks, advisories, update evidence, and technical documentation links in one governed workflow.
Track component inventory, vulnerability decisions, disclosure status, update evidence, and technical-file links in one governed system.
Check whether your SBOM, CVD policy, vulnerability triage, update process, and technical documentation evidence are connected.
Every vulnerability record should separate intake facts from legal-reporting conclusions. The CRA vulnerability handling duty applies broadly during the , while mandatory Article 14 reporting is triggered only for actively exploited vulnerabilities in the product and severe incidents affecting product security.
Record the awareness basis and decide whether the issue is an . The Commission FAQ explains that mandatory reporting is not triggered merely because a flaw exists or is found in good-faith testing without reliable evidence of malicious exploitation.
Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed, including through security updates, and to apply effective and regular security tests and reviews. The template should therefore track the chosen remedy and the evidence that it worked.
Avoid hard-coded severity-to-deadline tables unless they are based on your own policy and risk assessment. The CRA source material supports a risk-based remedy path, not one universal patch deadline for all vulnerabilities.
Annex I Part II requires a policy, a reporting contact, and measures for sharing information about vulnerabilities, including vulnerabilities in third-party components contained in the product. ENISA's vulnerability disclosure material also describes CVD as a multi-party process that coordinates reporting, fixing, mitigation, and public disclosure.
For integrated components, the finished-product manufacturer still has to handle the vulnerability in the finished product. If the component maintainer cannot fix it, the record should show the product-level alternative.
Link the SBOM and vulnerability record to the CRA technical file. Annex VII expressly includes the SBOM where applicable, the vulnerability handling process, coordinated disclosure policy, evidence of the reporting contact, and the technical solutions chosen for secure update distribution.
Keep confidential technical documentation separate from public advisories. The CRA does not generally require public release of the technical documentation or SBOM, although users must receive required user information and may be given SBOM access if the manufacturer chooses to make it available.
"Coordinated Vulnerability Disclosure is crucial for protecting users"
"manufacturers shall, in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay"
"software bill of materials in a commonly used and machine-readable format"