The CRA vulnerability-handling requirements are not limited to patching. They create a complete operating model covering visibility, intake, assessment, remediation, verification, disclosure, researcher communication and delivery of security updates.
Point 1: Identify and Document Vulnerabilities and Components
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements. This includes drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. The SBOM supports component visibility, but it is not itself the complete vulnerability record. Manufacturers also need to understand which product versions contain a component and whether a reported component vulnerability affects those versions.
- Maintain component visibility.
- Create the required SBOM.
- Track relevant versions.
- Connect component vulnerabilities to affected products.
Point 2: Address and Remediate Vulnerabilities Without Delay
Part II point 2 requires manufacturers, in relation to the risks posed to their products, to address and remediate vulnerabilities without delay, including by providing security updates. The requirement is risk-based rather than a universal fixed remediation deadline for every vulnerability. Where technically feasible, new security updates should be provided separately from functionality updates so users do not need unrelated new features merely to obtain a security correction.
- Assess the product-specific risk.
- Prioritise remediation accordingly.
- Provide security updates where needed.
- Separate security and functionality updates where technically feasible.
Point 3: Apply Effective and Regular Tests and Reviews
Part II point 3 requires effective and regular tests and reviews of product security. Testing can reveal vulnerabilities before external discovery and can verify that remediation actually fixes the relevant weakness. The CRA does not prescribe one universal testing method. The appropriate mix can include automated analysis, dependency analysis, security regression tests, manual review and adversarial testing where justified by the product risk.
- Test security regularly.
- Review product security.
- Use risk-appropriate methods.
- Retest significant vulnerability fixes.
Point 4: Share Information About Fixed Vulnerabilities
Once a security update has been made available, Part II point 4 requires manufacturers to share and publicly disclose information about fixed vulnerabilities. The information includes a vulnerability description, information allowing users to identify affected products, impact and severity, and clear information helping users remediate the vulnerability. In duly justified cases, publication may be delayed where the manufacturer considers the security risks of publication to outweigh the security benefits until users have had the possibility to apply the relevant patch.
- Describe the fixed vulnerability.
- Identify affected products.
- Explain impact and severity.
- Provide remediation information.
- Use delayed disclosure only where justified.
Point 5: Operate Coordinated Vulnerability Disclosure
Part II point 5 requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure. The policy should create a predictable route for security researchers and other reporters and should connect directly to the internal vulnerability-management process. A policy that exists publicly but does not lead to intake, triage and remediation would not provide an effective operational process.
- Publish the CVD policy.
- Define reporting expectations.
- Route reports to responsible teams.
- Coordinate remediation and disclosure.
Point 6: Facilitate Vulnerability Reporting
Part II point 6 requires manufacturers to take measures to facilitate the sharing of information about potential vulnerabilities in their products and third-party components. This includes providing a contact address for reporting vulnerabilities discovered in the product. Annex II also requires user information to identify the single point of contact where vulnerability information can be reported and received and where the manufacturer's coordinated vulnerability disclosure policy can be found.
- Provide a vulnerability contact address.
- Keep the reporting route accessible.
- Accept reports about relevant third-party components.
- Connect the public contact to the internal case-management process.
Point 7: Securely Distribute Updates
Part II point 7 requires mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically. Secure distribution is not just hosting a download file. The update path should protect authenticity, integrity and correct targeting so users receive the intended security correction rather than an unauthorised or corrupted package.
- Protect update authenticity.
- Protect update integrity.
- Target the correct product and version.
- Test distribution and installation.
Point 8: Disseminate Security Updates Without Delay
Part II point 8 requires available security updates addressing identified security issues to be disseminated without delay. Except for the Regulation's specific agreement possibility for tailor-made products supplied to a business user, such security updates are to be provided free of charge and accompanied by advisory messages containing relevant information, including possible action users need to take.
- Make available fixes reach users promptly.
- Provide relevant advisory information.
- Identify user action where necessary.
- Apply the specific tailor-made business-product exception carefully.
The Eight Requirements Form One Operational Chain
The eight Annex I Part II requirements are most effective when implemented as one process. Component visibility supports detection. Intake feeds triage. Triage identifies affected versions. Remediation produces fixes. Testing verifies those fixes. Secure distribution gets the update to users. Disclosure explains the issue and remediation. The coordinated vulnerability disclosure policy provides an ongoing path for new reports. Treating each point as isolated paperwork makes it easier for vulnerabilities to fall between teams.
- Connect component data to vulnerability cases.
- Connect cases to remediation owners.
- Connect remediation to testing.
- Connect release to disclosure and user communication.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.