Under the CRA, vulnerability handling is a formal obligation for manufacturers. It’s detailed across several articles and Annex I, and includes both proactive management and regulated reporting steps.
What the CRA Requires
The main obligations are laid out in Annex I, Part II (points 1 to 8), and Article 14. Here’s a breakdown of what’s required:
- Maintain a Software Bill of Materials (SBOM) and document known vulnerabilities (Annex I, Part II, point 1)
- Have internal procedures to detect, report, and fix vulnerabilities (Annex I, Part II, point 2)
- Regularly test and review the product’s security features (Annex I, Part II, point 3)
- Inform users of fixed vulnerabilities unless doing so increases risks (Annex I, Part II, point 4)
- Set up and publish a coordinated vulnerability disclosure policy (Annex I, Part II, point 5)
- Provide a dedicated contact point for vulnerability reports (Annex I, Part II, point 6 and Article 13(17))
- Ensure secure distribution of updates and clear communication to users (Annex I, Part II, points 7 and 8)
You must also respond to incidents quickly. Article 14 mandates:
- Notify ENISA and the CSIRT designated as coordinator within 24 hours after becoming aware of an actively exploited vulnerability (Article 14(1)-(2))
- Provide a vulnerability notification within 72 hours with relevant technical details (Article 14(2)(b))
- Submit a final report within 14 days after a fix is available (Article 14(2)(c))
- Inform affected users and suggest corrective measures (Article 14(8))
All reporting goes through ENISA’s single reporting platform, which is described in Article 16.
If you delay public disclosure for cybersecurity reasons, the justification and duration must meet the conditions to be set by the Commission under Article 14(9).
Implementation Considerations
These requirements mean manufacturers need to establish:
- A documented vulnerability handling policy, integrated into the software development and maintenance lifecycle (Annex I, Part II, point 2)
- An up-to-date SBOM and procedures to track vulnerabilities in included components, including third-party and open-source (Annex I, Part II, point 1; Article 13(6))
- A contact point and disclosure mechanism accessible to external researchers and users (Annex I, Part II, point 6; Article 13(17))
- Mechanisms to inform users of known vulnerabilities and publish fixes without delay (Annex I, Part II, point 4; Article 13(8))
Timeline and Support Periods
Manufacturers must handle vulnerabilities during the full declared support period of the product, which must be at least 5 years unless justified otherwise (Article 13(8), last paragraph). This includes vulnerabilities in any integrated component or dependency (Article 13(6)).
Security updates made available must remain accessible for at least 10 years or for the remainder of the support period, whichever is longer (Article 13(9)).
Having a clear, tested, and well-communicated vulnerability handling process is not just good security practice—it’s now a legal requirement. If you’re drafting or reviewing your policy, feel free to share it here for feedback or input.