CRA Coordinated Vulnerability Disclosure: What Annex I Requires
Updated 20 September 20263 min read
Every manufacturer of a product with digital elements needs a way for outsiders to report vulnerabilities, and a policy for handling those reports. The Cyber Resilience Act turns both into legal requirements.
What the Regulation says
Annex I, Part II sets three requirements that belong together:
| Point | Requirement |
|---|---|
| 5 | Put in place and enforce a policy on coordinated vulnerability disclosure |
| 6 | Take measures to facilitate the sharing of information about potential vulnerabilities in the product and in third-party components, including by providing a contact address for reporting |
| 4 | Once a security update is available, share and publicly disclose information about fixed vulnerabilities: a description, how to identify the affected product, the impact, the severity and remediation guidance. Publication may be delayed in duly justified cases, until users have had the chance to apply the patch |
Two more provisions connect to it: - Annex II, item 2: users must be told the single point of contact for vulnerabilities, and where the policy can be found. - Annex VII, item 2: the policy, and evidence that a reporting contact exists, go into the technical documentation.
What a workable policy contains
The Regulation requires a policy; it does not dictate its wording. A policy that works in practice usually covers: - scope: which products and versions; - how to report: a dedicated address, and an encryption key if you offer one; - timescales: when you will acknowledge a report, stated separately from when you will fix it; - safe harbour: a commitment not to pursue researchers acting in good faith within the policy; - out-of-scope activity: data exfiltration, denial of service, social engineering of staff; - disclosure and credit: how public disclosure is coordinated, and how reporters are acknowledged.
ISO/IEC 29147, for receiving reports, and ISO/IEC 30111, for handling them internally, are useful references for structure. They do not give presumption of conformity with the CRA unless cited for that purpose in the Official Journal.
Make it findable
- Publish the policy on a reachable web page.
- Add a
security.txtfile at/.well-known/security.txt, following RFC 9116. ItsContactandExpiresfields are required, and the expiry date needs renewing. - Use the same contact in your user information, as Annex II item 2 requires.
- Recital 63: the single point of contact must not rely exclusively on automated tools.
A report is not automatically an Article 14 notification
A vulnerability reported to you by a researcher acting in good faith is not, on that basis alone, an actively exploited vulnerability. Recital 68: vulnerabilities discovered with no malicious intent, for good-faith testing, investigation, correction or disclosure, are not subject to mandatory notification. What triggers Article 14 is evidence of exploitation — see when a manufacturer becomes aware.
Sources
- Regulation (EU) 2024/2847, Annex I Part II points 4, 5 and 6; Annex II item 2; Annex VII item 2; recitals 63 and 68 — Official Journal of the European Union
- RFC 9116, A File Format to Aid in Security Vulnerability Disclosure
Position as at 20 September 2026. General information, not legal advice.