Of the eight vulnerability-handling requirements in Annex I, Part II of the Cyber Resilience Act, Regulation (EU) 2024/2847, 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.

Provision one: the policy itself, Annex I, Part II, point 5

Manufacturers 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.

Point 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.

Provision two: the single point of contact, Article 13(17)

Article 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".

That 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.

Provision three: where it is published and filed

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.

Annex VII, point 2(b): the technical file 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.

The same policy is also what Article 24 asks of open-source software stewards, in the form of a documented cybersecurity policy that fosters vulnerability handling and voluntary reporting.

What a one-page policy has to say

  1. Scope. Which products and versions the policy covers, and the support period during which reports are acted on.
  2. 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).
  3. 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.
  4. 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 run in parallel and the policy should say so.
  5. 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).
  6. 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.
  7. Owner and version. Who owns the policy, its version and date, and where the current version is published.

What it must not promise

Not 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.

Publish 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.

Sources

  • Regulation (EU) 2024/2847, 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.

This 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.