CRA day one: the portal is up, the clock is running

The ENISA Single Reporting Platform went live this morning, exactly as promised. The Cyber Resilience Act’s Article 14 obligations are now in force. Somewhere in the EU, a legal team is staring at a 24-hour countdown and a web form they have never used.

Four days ago I wrote that they picked September 11 for the deadline and that the portal launches the same morning it becomes mandatory. The prediction was that this would inspire confidence in exactly nobody. The prediction was correct.

The portal is working, mostly

To ENISA’s credit: the SRP loaded this morning. There were slowdowns around 09:00 CET, which is when several large software foundations apparently sent their “go file” email to their member lists simultaneously. It was not down; it was slow. By noon CET it was running at normal speed, according to people who were actually trying to use it.

The form itself is what you would expect from a compliance portal built by committee. Twelve fields before you get to the actual vulnerability description. Drop-downs for product categories that predate the CRA’s own in-scope definitions, so the categories and the regulation do not map cleanly. A PDF upload option that currently rejects anything over 10 MB, which is a problem if your advisory includes a proof-of-concept or a detailed technical analysis.

The Eclipse Foundation published a same-day guidance document walking members through the form fields. That document exists because the form is not self-explanatory, and “not self-explanatory” is a charitable description.

The 24-hour clock is already a problem

What I expected to be the first real argument is already happening: two open source projects published security advisories in the past 48 hours. Both are arguably CRA-in-scope. Neither has a designated EU representative. Both project leads are in North America.

The clock starts when you “become aware” of an actively exploited vulnerability. The regulation does not define “become aware” with any useful precision. It does not define timezone. A FreeBSD-adjacent project maintainer in Vancouver reading a vuln disclosure on a mailing list at 23:45 PST is, technically, now running on a Brussels-business-hours deadline that expires before he wakes up.

This was going to be the first major friction point, and here it is, day one, happening exactly as predicted. The one-maintainer problem that the open source funding conversation has been circling for years now has a new face: you cannot have a designated EU legal representative if the project has one person and that person lives in a timezone that is not Brussels.

What “in scope” still does not mean

The second argument running in parallel: the CRA’s product scope is still genuinely ambiguous for a wide class of open source software. The “open source software steward” carve-out under Article 24 is narrower than most people read it. Software provided “in the course of a commercial activity” is in scope even if the project is nominally open source and the maintainer is not making money from it. If your software appears in a commercial product, the question of whether the commercial vendor or the open source project holds the CRA obligation is not answered cleanly by the regulation text.

Several foundations published their interpretation of this today. The interpretations do not all agree.

ENISA is supposed to publish clarifying guidance. It has not appeared yet as of this writing. The 24-hour clock does not pause while clarifying guidance is being drafted.

The part that is not theater

I have been sarcastic about the compliance machinery here, and the compliance machinery deserves it. Forms with 10 MB limits and drop-downs that predate the regulation are not serious infrastructure.

But the underlying objective is not wrong. Coordinated vulnerability disclosure practices are inconsistent across the industry, and “nobody had a legal obligation to tell anyone” has historically been an acceptable answer to “why did you sit on this for three months.” The CRA tries to change that. A 24-hour early-warning requirement on actively exploited vulnerabilities is aggressive, but the baseline it is replacing was often “never, or whenever we felt like it.”

If the portal stabilizes, if ENISA publishes the clarifying guidance it owes, and if the in-scope definitions get litigated into something that distinguishes between a hobbyist GitHub project and a product that ships inside enterprise software, this could end up being useful. That is a lot of ifs. The first twelve hours are not evidence that any of them are going to land cleanly.

Come back Thursday. There will be a test case by then.