CRA vulnerability handling documentation should explain how the manufacturer operates the complete Part II vulnerability lifecycle. It should not be limited to a policy document. The technical file should make it possible to identify components, receive vulnerability reports, assess affected product versions, prioritise and remediate vulnerabilities, verify fixes, distribute security updates securely and retain evidence of the decisions made.
Annex VII Expressly Requires Vulnerability Handling Documentation
Annex VII point 2(b) requires necessary information and specifications about the vulnerability handling processes put in place by the manufacturer. The technical documentation must therefore describe the manufacturer's process rather than merely state that vulnerabilities are handled. The documented process should be detailed enough to show how the manufacturer supports the Part II essential cybersecurity requirements and how the process applies to the relevant product with digital elements.
- Document the vulnerability handling process.
- Identify responsible teams and roles.
- Connect the process to Annex I Part II.
- Identify relevant product versions.
- Keep the process documentation current.
Include the Software Bill of Materials Process
Annex VII point 2(b) specifically includes the software bill of materials. Annex I Part II also requires manufacturers to identify and document vulnerabilities and components and to draw up an SBOM in a commonly used and machine-readable format covering at least top-level dependencies. Documentation should therefore identify how SBOMs are generated, associated with product releases, updated and used during vulnerability assessment.
- SBOM generation method.
- Supported machine-readable format.
- Product-version association.
- Dependency update process.
- Historical SBOM retention.
- Use during vulnerability triage.
An SBOM Does Not Replace a Vulnerability Register
An SBOM records software components and dependencies. A vulnerability register records known or suspected weaknesses, affected products, assessment status and remediation decisions. The datasets can be linked, but they serve different purposes. A product-specific vulnerability can exist in first-party code and therefore may not appear through dependency matching. Similarly, the presence of a vulnerable component does not automatically prove that the product is exploitable. Vulnerability handling documentation should explain how component information is converted into product-specific assessment.
- SBOM records components.
- Vulnerability records track weaknesses.
- Include first-party findings.
- Assess third-party findings in product context.
- Map affected vulnerabilities to product versions.
Document Vulnerability Intake
The process should explain how vulnerability information enters the organisation. Article 13 requires manufacturers to have appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. Those sources can include researchers, users, customers, suppliers, open-source maintainers, internal testing, public advisories and automated dependency monitoring. Manufacturers should also systematically document relevant cybersecurity aspects, including vulnerabilities of which they become aware and relevant information supplied by third parties. Intake procedures should prevent important findings from being lost across separate support, engineering and security channels.
- Researcher reports.
- Customer reports.
- Internal testing.
- Supplier advisories.
- Public vulnerability information.
- Dependency-monitoring output.
Provide and Document the Vulnerability Reporting Contact
Annex VII requires evidence of the provision of a contact address for reporting vulnerabilities. Annex I Part II also requires measures facilitating the sharing of information about potential vulnerabilities, including a contact address. The documentation should identify the reporting channel, responsible owner and operational workflow behind it. A published address that is not monitored reliably does not provide an effective vulnerability intake mechanism.
- Published reporting address.
- Responsible monitoring team.
- Routing procedure.
- Acknowledgement process where used.
- Backup or escalation path.
Document the Coordinated Vulnerability Disclosure Policy
Annex VII point 2(b) expressly includes the coordinated vulnerability disclosure policy. The documentation should identify where the policy is published or maintained and how reports are processed. Useful elements can include reporting instructions, expected information, communication channels, researcher interaction and the manufacturer's approach to coordinated remediation and disclosure. The CRA establishes the requirement for the policy but does not prescribe one universal policy template.
- Policy location.
- Reporting instructions.
- Communication process.
- Coordination responsibilities.
- Disclosure workflow.
- Policy review ownership.
Document Vulnerability Triage and Product Impact Analysis
The vulnerability process should explain how reports are validated and mapped to affected product versions. Technical triage can confirm whether the weakness exists, whether the relevant component or functionality is present, which versions are affected, whether exploitation is feasible and what security consequence can result. Product-specific analysis prevents both dismissing meaningful findings and treating every third-party advisory as automatic evidence of exploitable product risk.
- Validate the reported condition.
- Identify affected product versions.
- Assess exploitability.
- Assess security consequence.
- Record the technical conclusion.
Connect Vulnerability Assessment to Article 13 Risk Records
Article 13 requires manufacturers to systematically document relevant cybersecurity aspects and, where applicable, update the cybersecurity risk assessment. The vulnerability process should therefore define when a new finding changes an existing risk scenario or creates a new one. A newly discovered remotely exploitable weakness can invalidate an earlier assessment based on stronger assumptions. The updated risk record should remain traceable to the vulnerability that triggered the change.
- Review affected risk records.
- Create new scenarios where necessary.
- Update attack feasibility.
- Update impact where necessary.
- Preserve the trigger for reassessment.
Document Remediation Decision Making
Annex I Part II requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product. Process documentation should explain how remediation is prioritised, assigned, developed, reviewed and approved. It should also distinguish temporary mitigation from permanent remediation. Individual vulnerability records can retain the detailed decision, while the process document describes the common workflow and responsibilities.
- Risk-based prioritisation.
- Remediation owner.
- Target product versions.
- Temporary mitigation.
- Permanent remediation.
- Closure criteria.
Document Security Update Development and Verification
Where remediation requires a security update, the process should explain how the update is built, reviewed and verified. Security fixes should be tested against the original vulnerability and relevant regression conditions. Where technically feasible, Part II requires new security updates to be provided separately from functionality updates. Documentation should identify how release engineering distinguishes security fixes and how affected versions are selected.
- Security-fix development.
- Affected-version selection.
- Verification of the fix.
- Regression testing.
- Security-only release handling where technically feasible.
Document Secure Distribution of Updates
Annex VII expressly requires a description of the technical solutions chosen for secure distribution of updates. The documentation can describe signing, authenticity verification, integrity checks, protected metadata, distribution infrastructure, key management and failure behaviour. This evidence should match the architecture and marketed product rather than describe an update system that exists only in development.
- Update signing.
- Authenticity verification.
- Integrity verification.
- Signing-key protection.
- Distribution infrastructure.
- Failure and rejection behaviour.
Document Vulnerability Disclosure and Security Advisories
Part II requires information about fixed vulnerabilities once security updates become available, subject to the Regulation's justified-delay qualification. The vulnerability handling process should identify who prepares security advisories, how affected products are identified, which impact and severity information is included and how users receive remediation information. This public disclosure process is distinct from Article 14 regulatory reporting.
- Security advisory owner.
- Affected-product identification.
- Impact and severity information.
- User remediation instructions.
- Justified disclosure-delay process where applicable.
Keep Article 14 Reporting Separate From Vulnerability Handling
Routine vulnerability handling and Article 14 regulatory reporting are related but not identical. The process should contain a clear decision point for determining whether a vulnerability or incident meets the applicable reporting trigger. The manufacturer can continue remediation regardless of whether reporting is required. Separate records help prevent teams from assuming that every vulnerability is reportable or that an engineering fix removes a reporting obligation that has already arisen.
- Maintain vulnerability handling for all relevant findings.
- Assess Article 14 triggers separately.
- Record regulatory reporting decisions.
- Coordinate reporting and remediation timelines.
Document Support-Period Responsibilities
Article 13 requires effective vulnerability handling when the product is placed on the market and throughout the support period. The process documentation should identify how responsibilities continue after initial release, including vulnerability monitoring, component maintenance, remediation, security updates and communication. Changes in team structure or product ownership should not leave supported products without an operational vulnerability-handling owner.
- Supported product versions.
- Monitoring responsibilities.
- Remediation ownership.
- Security-update responsibility.
- End-of-support transition.
Evidence for Vulnerability Handling Processes
The technical documentation can reference controlled evidence such as the SBOM process, coordinated vulnerability disclosure policy, vulnerability-reporting contact evidence, vulnerability workflow, triage records, remediation records, security-update specifications, test results and security advisories. The process documentation should identify document owners, versions and review dates so that conformity evidence remains aligned with actual operational practice.
- SBOM and SBOM process.
- Coordinated vulnerability disclosure policy.
- Reporting-contact evidence.
- Vulnerability workflow.
- Remediation records.
- Secure update design.
- Security advisory records.
- Process review history.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.