CRA vulnerability identification starts with knowing what is inside the product. Manufacturers should maintain component and version visibility, create the required machine-readable SBOM, receive vulnerability reports, monitor relevant vulnerability information, perform regular security testing and connect findings to the exact affected product versions. Identification is the beginning of vulnerability handling, not the same as remediation or Article 14 reporting.
Annex I Requires Vulnerabilities and Components to Be Identified and Documented
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements. Effective vulnerability handling therefore requires visibility into both product weaknesses and the components that can contain those weaknesses. A vulnerability alert is difficult to assess if the manufacturer cannot determine which product versions use the affected component. Product teams should maintain enough version and component information to connect external vulnerability information, internal testing results and customer reports to the products actually made available on the market.
- Identify product components.
- Track relevant component versions.
- Document discovered vulnerabilities.
- Map vulnerabilities to affected products and releases.
- Keep records usable throughout the support period.
The CRA Expressly Requires a Software Bill of Materials
Annex I Part II point 1 expressly includes drawing up a software bill of materials in a commonly used and machine-readable format. The SBOM must cover at least the top-level dependencies of the product. This establishes a minimum legal baseline rather than necessarily defining the most useful technical depth for every product. Manufacturers may choose to maintain deeper dependency information where it supports vulnerability management, supply-chain analysis or product maintenance. The SBOM should reflect the released product rather than a development environment that contains dependencies not present in production.
- Create an SBOM.
- Use a commonly used machine-readable format.
- Cover at least top-level dependencies.
- Associate the SBOM with product versions.
- Keep released-product information accurate.
An SBOM Is Not the Same as a Vulnerability List
An SBOM describes software components and dependencies. A vulnerability record describes a weakness or potential weakness and its relationship to the product. The two datasets support each other but should not be treated as interchangeable. A component can appear in an SBOM without having a known vulnerability. A product-specific vulnerability can also arise from the manufacturer's own code or configuration rather than a third-party component. Vulnerability identification therefore needs both component visibility and a process for recording product-specific security findings.
- Use the SBOM for component visibility.
- Maintain vulnerability records separately.
- Include first-party product vulnerabilities.
- Map third-party vulnerabilities to actual product use.
- Avoid treating component presence as automatic exploitability.
Component Version Accuracy Matters
Vulnerability information frequently applies only to particular component versions, configurations or features. A component name without reliable version information can therefore produce false positives or missed exposure. Manufacturers should connect build and release processes to component records so that they can determine what entered each marketed product version. Where dependencies are resolved dynamically during builds, reproducibility and evidence become particularly important. The objective is to answer a practical question when a new vulnerability appears: which supported product versions are actually affected?
- Track component versions.
- Associate components with product releases.
- Record relevant configuration differences.
- Preserve historical release information.
- Support rapid affected-product analysis.
Vulnerability Identification Includes More Than Public CVE Feeds
Public vulnerability databases are useful but cannot identify every product weakness. Manufacturers can also learn about vulnerabilities through internal testing, researchers, customers, suppliers, open-source maintainers, penetration testing, bug-report channels, dependency advisories and operational security analysis. Annex I Part II also requires a coordinated vulnerability disclosure policy and measures that facilitate reporting of potential vulnerabilities. The vulnerability-management process should therefore accept information from several sources and provide a consistent route for technical assessment.
- Monitor relevant public vulnerability information.
- Accept researcher and customer reports.
- Use supplier and maintainer advisories.
- Include internal security testing.
- Route findings into one traceable assessment process.
Regular Security Tests and Reviews Support Identification
Annex I Part II point 3 requires effective and regular tests and reviews of the security of the product with digital elements. These activities can identify weaknesses that are not yet represented in external vulnerability databases. The appropriate testing can include code review, automated analysis, dependency review, penetration testing, fuzzing, configuration review or other product-specific techniques. The CRA does not impose one identical testing programme on every product, but the manufacturer should be able to explain how testing and review contribute to discovering vulnerabilities during development and the support period.
- Define regular security review activities.
- Use testing appropriate to product risks.
- Record significant findings.
- Map findings to affected versions.
- Feed confirmed vulnerabilities into remediation.
Third-Party Components Need Product-Specific Assessment
A public advisory affecting a third-party component does not automatically mean every product containing that component is exploitable. The manufacturer should determine whether the affected version is present, whether the vulnerable functionality is used, whether product configuration changes exposure and what consequences could result. At the same time, a lack of immediate exploitability should not justify ignoring the component. The assessment and conclusion should be documented so that future product changes or new exploit information can be evaluated against the earlier decision.
- Confirm the affected component version.
- Determine whether vulnerable functionality is present.
- Assess product configuration and reachability.
- Document the product-specific conclusion.
- Reassess when relevant information changes.
Article 13 Requires Systematic Vulnerability Documentation
Article 13 requires manufacturers to systematically document relevant cybersecurity aspects concerning their products in a manner proportionate to the nature and cybersecurity risks, including vulnerabilities of which they become aware and relevant information provided by third parties. Vulnerability identification should therefore produce durable compliance records rather than temporary tickets that lose the reasoning once closed. Records can include discovery source, affected products, technical assessment, severity, exploitability analysis, remediation decision and links to evidence. The cybersecurity risk assessment should be updated where applicable.
- Maintain traceable vulnerability records.
- Capture relevant third-party information.
- Record affected product versions.
- Preserve technical assessment.
- Update the cybersecurity risk assessment where applicable.
Identification Is Separate From Article 14 Reporting
Identifying a vulnerability does not automatically mean that the vulnerability is reportable under Article 14. Article 14 has specific notification triggers, including actively exploited vulnerabilities. The vulnerability-identification process should determine what weakness exists and which products are affected. A separate reporting-assessment workflow should determine whether Article 14 criteria have been met. Keeping these stages distinct prevents teams from either reporting every ordinary vulnerability as though it were actively exploited or overlooking a reporting duty because the vulnerability was treated only as a normal engineering ticket.
- Identify and document all relevant vulnerabilities.
- Assess Article 14 triggers separately.
- Do not equate known vulnerability with active exploitation.
- Preserve evidence supporting the reporting decision.
Evidence for CRA Vulnerability Identification
Evidence can include SBOMs, component inventories, build records, dependency versions, vulnerability intake records, security-test results, vulnerability assessments and links between findings and affected product versions. Manufacturers should retain enough historical information to investigate vulnerabilities discovered after a newer product version has already been released. Automation can improve component and vulnerability visibility, but automated scanner output should not replace product-specific assessment. The strongest evidence connects the component or weakness, the affected product, the assessment and the subsequent handling decision.
- Machine-readable SBOM.
- Component and version inventory.
- Vulnerability intake records.
- Security-test findings.
- Affected-version mapping.
- Product-specific vulnerability assessment.
- Historical release evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.