[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:en:the-coordinated-vulnerability-disclosure-policy-the-cra-requires":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"en","the-coordinated-vulnerability-disclosure-policy-the-cra-requires","The coordinated vulnerability disclosure policy the CRA requires: three provisions, and a one-page policy that meets them","Annex I, Part II, point 5 of the Cyber Resilience Act requires every manufacturer in scope to put in place and enforce a coordinated vulnerability disclosure policy. Article 13(17) requires a single point of contact for reporting that is easy to find and not limited to automated tools; Annex II, point 2 requires the contact and the policy's location in the user information; Annex VII, point 2(b) puts both in the technical file. What each provision asks, what a policy must say, and what it must not promise.","2026-09-11","\nOf the [eight vulnerability-handling requirements](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) in Annex I, Part II of the Cyber Resilience Act, Regulation (EU) 2024\u002F2847, the coordinated vulnerability disclosure policy is the one most small manufacturers have never written and can write in an afternoon. It is also the one a researcher, a customer and a market surveillance authority will all look for by name. Three provisions define it.\n\n## Provision one: the policy itself, Annex I, Part II, point 5\n\nManufacturers shall \"put in place and enforce a policy on coordinated vulnerability disclosure\". Two verbs. **Put in place**: a written policy exists and is published where a reporter can find it. **Enforce**: the organisation follows it, which means it names who receives reports, what happens next, and in what time.\n\nPoint 5 does not prescribe the contents. Point 6 next to it does part of the work: manufacturers shall \"take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities\". And point 4 sets what happens once a fix exists: fixed vulnerabilities are publicly disclosed, with a description, the affected products, impact, severity and how users remediate, unless publication would do more harm than good, in which case disclosure may be delayed until users have had the chance to update.\n\n## Provision two: the single point of contact, Article 13(17)\n\nArticle 13(17) requires manufacturers to designate a single point of contact \"to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities\". The point of contact must be \"easily identifiable by the users\", included in the Annex II user information, and it \"shall allow users to choose their preferred means of communication and shall not limit such means to automated tools\".\n\nThat last clause rules out a contact that is only a web form or only a bot. A security email address, alongside whatever form or bug-bounty platform you also use, meets it. A PGP key or another way to send details confidentially is not required by the text but is what a reporter will expect.\n\n## Provision three: where it is published and filed\n\n**Annex II, point 2**: the product's user information must include \"the single point of contact where information about vulnerabilities of the product with digital elements can be reported and received, and where the manufacturer's policy on coordinated vulnerability disclosure can be found\". So the policy has a public location, and the user information points at it.\n\n**Annex VII, point 2(b)**: the [technical file](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point) contains \"the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities\". The policy is a controlled document with a version and a date, not only a web page.\n\nThe same policy is also what [Article 24](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software) asks of open-source software stewards, in the form of a documented cybersecurity policy that fosters vulnerability handling and voluntary reporting.\n\n## What a one-page policy has to say\n\n1. **Scope.** Which products and versions the policy covers, and the [support period](\u002Farticles\u002Fhow-long-is-the-cra-support-period) during which reports are acted on.\n2. **How to report.** The single point of contact: at minimum an email address, plus any form or platform; how to send details confidentially; what to include (product, version, steps to reproduce, impact).\n3. **What the reporter can expect.** An acknowledgement within a stated time; an assessment and a first response within a stated time; updates while the vulnerability is being handled. Choose times you will keep; a promise of 48 hours you cannot meet is worse than five working days you can.\n4. **How you handle it.** Triage, severity, remediation \"without delay\" (point 2), a security update separate from feature updates where feasible, and the disclosure under point 4 once the update is available. Where the reporter is also the source of an actively exploited vulnerability, the [Article 14 clocks](\u002Farticles\u002Fwhat-you-have-to-report-under-the-cra-the-two-triggers-defined) run in parallel and the policy should say so.\n5. **Disclosure and credit.** When and how you publish fixed vulnerabilities, whether you credit reporters, and the ground for delaying publication (point 4: where the security risk of publishing outweighs the benefit, until users can update).\n6. **Safe harbour.** A statement that good-faith research within the policy's terms will not be the subject of legal action by you. This is not required by the Regulation, and it is what makes researchers report to you rather than about you.\n7. **Owner and version.** Who owns the policy, its version and date, and where the current version is published.\n\n## What it must not promise\n\nNot a bounty, unless you run one. Not a fix by a date you cannot control. Not confidentiality you cannot keep, since Article 14 may require notifying the CSIRT and informing users. And not a claim that the product has no vulnerabilities: Part I, point 2(a) is about known exploitable vulnerabilities at release, and the whole point of a disclosure policy is that new ones will be found.\n\nPublish it at a stable URL, put that URL in the user information, file the dated version with the technical documentation, and put the contact address in the same three places. That is three provisions met with one page.\n\n## Sources\n\n- Regulation (EU) 2024\u002F2847, Annex I, Part II, points 2, 4, 5 and 6; Article 13(17) (quoted); Annex II, point 2 (quoted); Annex VII, point 2(b) (quoted); Article 24 for stewards; Article 14 for the reporting clocks. Read from the Official Journal text on EUR-Lex on 11 September 2026.\n\nThis is not legal advice. The three provisions are short enough to paste into the policy's own preamble, which is where a careful reader will look for them.\n",1789383985605]