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

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 CRA’s vulnerability-handling requirements 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 24-hour early warning to the authorities 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

The channel is worth the process that answers it. 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. None of this is exotic; all of it fails when improvised.

Where to start

Our own starting point is in plain sight: this site’s security.txt, with a published PGP key, is 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