Coordinated vulnerability disclosure

Coordinated vulnerability disclosure is a defined process in which an outsider reports a vulnerability to the manufacturer, the manufacturer remedies it, and both sides agree on when the details become public. The Cyber Resilience Act (CRA) turns that practice into an obligation. Annex I, Part II, point (5) requires manufacturers to “put in place and enforce a policy on coordinated vulnerability disclosure”.

The requirement attaches to the manufacturer’s processes, not to the product. It is therefore examined as part of the conformity assessment, because under Article 13(12) the EU declaration of conformity may only be drawn up once the manufacturer’s processes also meet the requirements in Annex I, Part II.

What the CRA requires and what it leaves open

The text is short. It names three pieces that belong together:

• the policy itself, put in place and actually enforced (Annex I, Part II, point (5))
• a contact address for reporting discovered vulnerabilities, plus measures that make it easier to share information about potential vulnerabilities in the product and in the third-party components it contains (point (6))
• procedures for processing and remediating vulnerabilities reported from internal or external sources (Article 13(8))

What the CRA does not prescribe is just as notable. There is no deadline for publication, no required form for the policy, and no obligation to pay for reports. Recital 76 describes only the goal: a structured process that lets the manufacturer diagnose and remedy a vulnerability before detailed information reaches third parties or the public.

The requirement is sharply enforced all the same. A missing policy is non-compliance with Annex I, and Article 64(2) provides for administrative fines of up to EUR 15 000 000 or, where the offender is an undertaking, up to 2,5 % of total worldwide annual turnover for the preceding financial year, whichever is higher.

Where the policy has to be findable

Annex II, point 2 requires the information supplied to users to name the single point of contact where vulnerabilities can be reported and where the coordinated vulnerability disclosure policy can be found. Article 13(17) adds two requirements for that contact point: users must be able to identify it easily, and they must be allowed to choose their preferred means of communication. A single automated channel falls short, because those means may expressly not be limited to automated tools. Recital 63 gives the chat box as the example: a manufacturer who offers one should also offer a phone number or another digital means of contact, such as an email address or a contact form.

The policy also belongs in the Technical documentation. Annex VII, point 2(b) lists it next to the software bill of materials and the evidence that a contact address has been provided. Recital 76 further encourages manufacturers to publish their security policies in machine-readable format. That part is a suggestion, not a duty.

When the report comes through a CSIRT

Not every report reaches you directly. Article 12(1) of the NIS2 Directive obliges every Member State to designate one of its CSIRTs as coordinator for coordinated vulnerability disclosure. That CSIRT designated as coordinator acts as a trusted intermediary. Its tasks include identifying and contacting the entities concerned, assisting the person reporting, and negotiating disclosure timelines, including for vulnerabilities that affect several entities at once.

Reporters may stay anonymous there. For a manufacturer that means a report can arrive through a CSIRT without you ever learning who sent it. Where someone other than the manufacturer reports an actively exploited vulnerability or a severe incident, the CSIRT must inform the manufacturer without undue delay under Article 15(4).

How it relates to mandatory reporting

An ongoing disclosure process does not suspend the Reporting obligations. Once a vulnerability is actively exploited, the 24-hour deadline in Article 14 runs regardless of any embargo agreed with a reporter.

The CRA accommodates the ongoing process elsewhere, under narrow conditions. Where a CSIRT designated as coordinator has been made aware of an actively exploited vulnerability as part of a coordinated disclosure procedure under Article 12(1) of the NIS2 Directive, the CSIRT that first received the notification may delay disseminating it via the single reporting platform under Article 16(6) on justified cybersecurity grounds, for no longer than is strictly necessary and at most until the parties involved in the disclosure have consented. That does not stop the manufacturer from notifying the vulnerability voluntarily. The accommodation sits with the authority, not with the manufacturer.

Alongside this stands voluntary reporting under Article 15. It is open to any vulnerability and to any natural or legal person, and under paragraph 5 it must not impose additional obligations on whoever reports. Article 17(4) adds that the act of notifying does not by itself increase liability.

Vulnerabilities in components you did not write

Where a report concerns a Component sourced elsewhere, the matter does not end with your own patch. Article 13(6) requires you to report the vulnerability to the person or entity manufacturing or maintaining that component. If you have developed a software or hardware modification to address it, you must share the relevant code or documentation, in a machine-readable format where appropriate.

This applies expressly to open source components as well. A workable policy therefore records who takes that step and through which channel.

After the fix

Annex I, Part II, point (4) requires manufacturers to share and publicly disclose information about fixed vulnerabilities once a Security update has been made available. That includes a description, information allowing users to identify the affected product, the impact and severity, and accessible guidance helping users to remediate.

Delay is possible but narrow. It requires a duly justified case in which the manufacturer considers the security risks of publication to outweigh the security benefits, and it lasts only until users have been given the possibility to apply the relevant patch.

Where a vulnerability notified under Article 14(1) or Article 15(1) is publicly known, ENISA adds it to the European vulnerability database in agreement with the manufacturer once a corrective or mitigating measure is available (Article 17(5)).

A different duty for open-source software stewards

An Open-source software steward does not need a policy under Annex I, Part II, point (5). Article 24(1) instead requires a cybersecurity policy, documented in a verifiable manner, that fosters effective vulnerability handling, supports voluntary reporting under Article 15, and promotes the sharing of information about discovered vulnerabilities within the open-source community. For a manufacturer integrating such a component, nothing changes: it still needs a policy of its own.