Coordinated Vulnerability Disclosure: 7 Essential CRA Steps

Coordinated vulnerability disclosure stops being optional for anyone selling connected products in the EU. The Cyber Resilience Act requires a policy, and the word it uses is not “publish” — it is enforce.

NIS2 built the other half two years earlier: a designated CSIRT in every Member State whose job is to broker the conversation between a researcher and you, anonymously if the researcher asks.

What the CRA requires of coordinated vulnerability disclosure

Annex I, Part II, point (5) is one line: manufacturers shall put in place and enforce a policy on coordinated vulnerability disclosure.

“And enforce” is doing the work. A published policy that nobody follows when a report actually arrives is not compliance with this requirement — it is evidence against it, because the policy states the process you failed to run.

Article 13(8) makes the internal side explicit. Manufacturers must have appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate potential vulnerabilities reported from internal or external sources.

From internal sources too. A finding raised by your own engineer enters the same pipeline as one from a stranger — which is not how most organisations run it. Internal findings usually go to a backlog and external ones to a security inbox, and only the second has a defined clock.

Coordinated vulnerability disclosure covers your components

Annex I, Part II, point (6) requires manufacturers to take measures to facilitate the sharing of information about potential vulnerabilities in their product as well as in third-party components contained in that product, including by providing a contact address for reporting.

So a researcher who finds a flaw in a library you bundle must have a route to you. You cannot direct them upstream and consider the matter closed — and this is precisely where your SBOM becomes operational rather than documentary. It is how you answer “do we ship that component?” in minutes rather than days.

Where the policy has to be findable

Two provisions govern discoverability, and they are usually half-implemented.

Annex II, point (2) requires the information and instructions to the user to state the single point of contact where vulnerabilities can be reported and received, and where the manufacturer’s coordinated vulnerability disclosure policy can be found. Both facts, in the user information.

Article 13(17) then constrains that contact. It must be easily identifiable, it must allow users to choose their preferred means of communication, and it shall not limit such means to automated tools.

A web form with no email address does not satisfy Article 13(17). Neither does a chatbot with no human route. That single sentence rules out the cheapest implementation most product teams reach for.

And under Annex VII, point 2(b), the coordinated vulnerability disclosure policy belongs in the technical documentation alongside the SBOM and the contact address — so it is assessed, not merely posted.

NIS2 gives reporters a route that bypasses you

NIS2 Article 12(1) requires each Member State to designate one of its CSIRTs as a coordinator for the purposes of coordinated vulnerability disclosure, acting as a trusted intermediary. Its tasks include identifying and contacting the entities concerned, assisting the person reporting, and negotiating disclosure timelines and managing vulnerabilities that affect multiple entities.

Members States must ensure people can report anonymously where they so request, and the coordinator must ensure diligent follow-up and preserve that anonymity.

The consequence for a manufacturer is worth stating plainly: a researcher who cannot reach you, or who does not trust your process, has a state-backed alternative that will contact you anyway — and the disclosure timeline then gets negotiated by someone else. A working intake channel is not just a legal box; it is how you stay in the conversation.

Article 12(2) adds the European vulnerability database, developed and maintained by ENISA after consulting the Cooperation Group.

The researcher liability problem

Recital 75 of the CRA is unusually candid. It acknowledges that people researching vulnerabilities could in some Member States be exposed to criminal and civil liability, and encourages Member States to adopt guidelines on non-prosecution of information security researchers and exemption from civil liability.

The Regulation does not require a coordinated vulnerability disclosure policy to offer a safe harbour. But reporters look for one, and its absence quietly suppresses the reports you would rather receive than read about. A short statement that you will not pursue good-faith research conducted within your stated scope costs nothing and materially changes intake volume.

Recital 76 also confirms what a policy should contain: a structured process through which vulnerabilities are reported in a manner allowing the manufacturer to diagnose and remedy them before detailed information is disclosed to third parties or the public. It suggests publishing security policies in machine-readable format, and notes that bug bounty programmes are a legitimate way to incentivise reporting.

The clock running underneath coordinated vulnerability disclosure

Coordinated vulnerability disclosure is not a standalone process. If a reported vulnerability turns out to be actively exploited, CRA Article 14 imposes an early-warning obligation within 24 hours — and that obligation applies from 11 September 2026, more than a year before the rest of the Regulation.

So triage has to answer the exploitation question before it finishes the severity analysis. Sequencing the process the other way round is the most common design flaw in a disclosure policy.

How coordinated vulnerability disclosure connects

Where to start

1. Publish a coordinated vulnerability disclosure policy and run it once against a simulated report, because “enforce” is the operative verb.
2. Give a contact route that is not automated only, with a genuine choice of channel.
3. Put the policy location in the user information, next to the single point of contact.
4. Route internal findings through the same process, as Article 13(8) requires.
5. Accept component reports, and connect them to your SBOM.
6. Put exploitation triage first, ahead of severity scoring, because of the 24-hour clock.
7. Consider a safe harbour statement, given what Recital 75 says about researcher liability.

This guide reflects Regulation (EU) 2024/2847 and Directive (EU) 2022/2555 as published on EUR-Lex, read at 16 August 2026. NIS2 is transposed nationally, so your CSIRT coordinator is designated by your Member State.

The EU CRA Toolkit provides 74 editable templates including the coordinated vulnerability disclosure policy, the advisory template, the component and third-party vulnerability procedure and the reporting records — and the NIS2 Toolkit covers the Article 21 side for entities in scope of both.