The Single Reporting Platform Forgot the Third Group

Since 11 September, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act. ENISA built the Single Reporting Platform to take them. Early warning within 24 hours, full notification within 72, final report within 14 days of a fix being available.

It’s a genuinely good piece of plumbing, and I want to give it credit before I complain about it.

For a vendor, it solves a real problem. You report once. The notification lands with the CSIRT where you have your main establishment, ENISA gets it at the same time, and that CSIRT passes it to the other member states where your product is sold. Before this you’d have been working out which national authorities needed telling and in what format, which is the sort of task that eats an afternoon during the exact window when nobody has an afternoon.

For a regulator it’s just as useful. Every manufacturer arrives in the same shape, through the same door, on the same clock. You can see patterns across vendors because the data is finally comparable.

Two of the three groups with a stake in this got something well designed. The third got a library.

The Third Group Is the One Running the Software

There are three parties to any vulnerability. The vendor who made the thing, the regulator who supervises it, and the organisation with the thing installed on four hundred servers.

The third group is the one that has to do something. The vendor ships a fix and the regulator takes a report, but neither action patches anything. Somebody in an IT department has to find out, work out whether they’re affected, and schedule the work. The whole apparatus exists so that step happens faster.

That step is the one nobody built a mechanism for.

Access to the Single Reporting Platform is limited to Assigned Representatives of manufacturers, each with an EU Login account and multi-factor authentication, verified by the designated CSIRT. That’s correct and I wouldn’t change it. What goes in at the 24 hour mark is an actively exploited flaw with no fix available, and publishing that to the world would be handing a target list to exactly the wrong people.

But the confidentiality argument has an expiry date, and it expires when the fix ships. The CRA already has a milestone there: the final report, due within 14 days of a corrective measure being available. At that point the thing is patched, the advisory is out, and the only people still in the dark are the ones with it installed.

Nothing in the architecture does anything with that moment.

What Actually Exists

To be fair to ENISA, they haven’t left the user with nothing, and anyone arguing this point needs to deal with that honestly.

The EU Vulnerability Database is public, has a web search and a documented API, and aggregates from EU CSIRTs, vendor advisories, the EU Known Exploited Vulnerabilities catalogue and CISA’s KEV. The SRP does feed into it. Manufacturer reports enrich the EU KEV catalogue, and the KEV exploitation data is synchronised with the EUVD.

So the pipe exists. It’s the shape of it that’s the problem.

It’s indirect, going from manufacturer to CSIRT to KEV catalogue to database rather than arriving anywhere near the person affected. It’s consent-gated, because ENISA adds publicly known fixed vulnerabilities to the EUVD only with the manufacturer’s agreement, which means the authoritative timely source feeds the public one at the vendor’s discretion. And it’s pull, not push. The database sits there and waits for you to come and ask it the right question.

Which assumes you know to ask, know what you’re running, and remember to check on a Tuesday when nothing is on fire.

The clearest evidence that this isn’t enough is what people have built on top of it. There’s a GitHub project called EUVD-Alert that does automated alerting off the ENISA database, and somebody runs a Mastodon account posting the feed. Both are decent bits of work and I’m glad they exist. They exist because the official thing publishes data and not notifications, and individuals went and filled the gap themselves, which is usually a sign the gap is real.

It’s also where the argument gets uncomfortable rather than academic. A volunteer project has no service level, no obligation to keep running, and nobody to answer to if it quietly stops matching something. Put it in the path between a disclosure and your patching decision and you’ve taken on its failures as your own. When a client asks why they weren’t told, “the community tool didn’t pick it up” is not an answer anybody wants to give, and it won’t read any better in an incident report or on a renewal questionnaire than it sounds out loud.

So the practical position for anyone running this professionally is that the official source gives you data you have to go and fetch, and the convenient alternatives are things you can’t be seen to depend on. Neither of those is a notification service, and the gap between them is filled with somebody’s manual process.

What It Could Have Been

Picture the version that was available.

You register the products you run. Not a free-text wishlist, but an actual inventory, which plenty of organisations already maintain and which the CRA is separately pushing vendors to support through software bills of materials. You get a notification when something on that list is reported as actively exploited and a fix exists. One source, one format, timed off the regulatory clock rather than a vendor’s marketing calendar.

The technology for this is not hypothetical. CSAF 2.0 is a machine-readable advisory format designed for exactly this job, with standardised version and product identifiers so an advisory can be matched automatically against an asset inventory. Red Hat and Cisco publish CSAF feeds. Germany’s BSI and CISA have both built sharing capability on it. Microsoft has extended machine-readable exploitability data across its CVEs.

So the format exists, the inventory standard exists, the data exists, and the authoritative timely source now exists too. Nobody joined them up, and the CRA was the moment when somebody could have been required to.

Why This Lands Harder on Service Providers

If you run IT for one organisation, you have a manageable number of vendors and you probably have their mailing lists.

Run IT for a few hundred clients and the arithmetic turns. Dozens of products, each with its own advisory channel, each in its own format, several of which only notify the registered contact who left two years ago. The work of knowing what’s been disclosed is real labour, it happens every week, and it’s almost entirely undifferentiated. Nobody wins business because they read advisories more diligently than the next crowd.

That’s precisely the kind of work that should be solved once, centrally, by the body that already receives the reports. Instead every provider in Europe is doing their own version of it, badly, at different speeds.

And there’s a regulatory angle that makes the absence stranger. NIS2 expects in-scope organisations to handle vulnerabilities as part of risk management, and plenty of those organisations are not large enough to have anyone whose job is watching advisory feeds. The same legislature that created the obligation to act had the chance to create the mechanism that tells you when to act, and built that half for the regulators instead.

What to Do About It Meanwhile

Pull the EUVD API into whatever you already use for alerting, and own that integration yourself. It’s documented, it’s the official source, and a few hours of work gets you something you can point at when somebody asks where your advisory intelligence comes from. Read the community projects by all means, they’ll save you time working out the shape of it, but build on the API rather than subscribing to somebody’s feed and treating it as covered. It won’t be filtered to your estate, and it’s still better than a database you have to remember to visit.

Ask your vendors whether they publish CSAF. The answer today is mostly no outside the large platform vendors, and the question is worth asking anyway, because enough people asking is how that changes. It’s a reasonable thing to put in a renewal conversation.

And keep an actual inventory of product versions across your clients, if you don’t already. Every version of this problem that gets better in the next few years assumes you have one. Without it, a filtered feed would have nothing to filter against.

TL;DR

The Single Reporting Platform is well built for the two groups it was designed for. Vendors report once instead of a dozen times, and regulators finally see the same data in the same shape from everyone.

The group that actually has to patch something got a searchable database and the assumption they’ll remember to look. That’s not a failure of the platform so much as a failure to notice there was a third party in the room, and it’s a strange thing to miss in a regulation whose entire purpose is getting fixes into the hands of the people running the software.

The pieces are all sitting there. Somebody just has to decide the user is a stakeholder rather than an audience.