Skip to content
folhas.io
secure by design for connected products· Articles

Articles

Coordinated vulnerability disclosure: the channel the CRA requires you to keep open

The reporting obligations towards the authorities are now applicable, but they are half of the circuit. Annex I, Part II demands the other half: a public channel for receiving vulnerability reports, with a policy, a point of contact and a process behind it. It costs little to set up, and there is a standard for almost everything.

Published
Updated

Update note (23 Oct 2026). We added the section “On the integrator’s side”, on reporting vulnerabilities to whoever maintains the components (Article 13(6)), with the example of the PHP fixes of October 2026.

Since 11 September 2026, a manufacturer that learns of an actively exploited vulnerability in its product has deadlines counted in hours to alert the authorities — the article on the 24h and 72h reports describes that circuit in detail. That circuit is the outbound one. The regulation also draws the inbound one: how information about a vulnerability reaches the manufacturer, from outside, by the shortest possible path.

What Annex I, Part II asks for

The vulnerability-handling requirements of the CRA become enforceable with full application, on 11 December 2027, for products with digital elements placed on the market from then on. The list is short and concrete:

  • Inventory the product’s components and vulnerabilities, with an SBOM in a machine-readable format (article 01 covers how to generate one honestly);
  • Address and remediate vulnerabilities without delay, with security updates distributed securely and at no cost to the user;
  • Test the product’s security regularly;
  • Publicly disclose fixed vulnerabilities, with information that serves the people operating the product;
  • Have a coordinated vulnerability disclosure policy, published and enforced in practice;
  • Make it easy for vulnerabilities to be reported from outside, with a public point of contact.

Whoever waits until December 2027 to open the channel will open it with the rest of the conformity work on the table, the worst possible time to write policy calmly.

The minimum that already works

The front door has a standard of its own and fits in a text file. The security.txt (RFC 9116) lives under /.well-known/, points to a contact, a PGP key for encrypted reports and an expiry date that forces you to revisit it. The contact should be a dedicated address, one that survives people leaving and personal mailboxes.

The published policy does not need to be long. Three things are enough: the scope (which products and versions), what the manufacturer promises (acknowledgement within a defined period, a public reference when the fix ships), and what it asks of the reporter (a reasonable window before public disclosure, no access to third-party data during the research). Coordinated disclosure is not a bounty programme: most serious reports come from researchers and customers who only want a competent reply.

For those who want to go beyond the minimum, the external interface is standardised in ISO/IEC 29147 and the internal process in ISO/IEC 30111. The two were written to fit together, and the read is shorter than it looks.

Coordinated disclosure flow: whoever discovers a vulnerability (researcher, customer or integrator, third-party scanner) comes in through a public channel made of security.txt, a PGP key, a published policy and triage with an owner; two destinations leave the channel: the fix and advisory for users, and, if there is active exploitation, the early warning notification to the authorities, within 24 hours, under Article 14.
One channel, two destinations. Triage is the piece that decides whether a report follows the normal fix circuit or starts the Article 14 clocks.

The process behind the address

An incoming report needs four things, in this order: acknowledgement of receipt, triage with an owner and a deadline, a decision on severity, and a record of all of it that outlives the memory of whoever picked it up.

Triage is where the two circuits touch. An external report can be exactly the signal that triggers Article 14: if it describes active exploitation, the company has just “become aware” and the 24-hour clock runs from the conclusion of that triage. Whoever answers the inbound channel has to recognise what carries outbound deadlines.

The rest of the process is what you would expect: fix, distribute the update through the secure channel, publish the advisory with the fixed vulnerability, and credit the reporter if they want it.

On the integrator’s side

The manufacturer that receives reports also has to send them. From full application, Article 13(6) obliges a manufacturer that identifies a vulnerability in a component integrated in its product, including an open-source one, to report it to whoever manufactures or maintains that component and to share the fix, if it develops one. The Commission guidance of 27 July 2026, C(2026) 5252, which is non-binding, asks for that report to follow the project’s own channels and disclosure policy, and takes the view that it is not required when the manufacturer can confirm that the maintainer already knows about the vulnerability.

The PHP case of October 2026, which article 09 covers, shows the other side of the same circuit. The project pre-announced the fixes the day before, Linux distributions and extended support vendors received them ahead of the release, and anyone integrating PHP without going through one of them only got them with the public release. For critical components, this calls for two things prepared in advance: following the security advisories of each upstream project, and knowing which distribution or vendor each component comes through. The advisory the manufacturer then publishes has to let users identify the affected product, and a VEX document (affected, not affected, fixed, under investigation) carries that information in machine-readable form.

Where to start

Our own starting point is in plain sight: this site’s security.txt, with a published PGP key, and the disclosure policy that goes with it are the embryo of the channel for our own product, and logbook entry 001 fixed that decision before there was a product on the market. For a manufacturer with a product on sale, the practical order is the same and fits in a quarter: a dedicated address and security.txt this week, a short published policy next, a triage process with an owner and a rehearsal booked before the quarter ends.

A channel opened before the first report is infrastructure. Opened after, it is crisis management.

Sources