The EU CRA reporting deadline is Thursday and the portal opens the same morning

Thursday. Four days. That is when the EU Cyber Resilience Act’s mandatory vulnerability reporting requirements take effect under Article 14. If your organization qualifies as a manufacturer or an open source software steward under the CRA, you now have a legal obligation to file with ENISA when you become aware of an actively exploited vulnerability in a product covered by the regulation.

The ENISA Single Reporting Platform, the system you must file through, also goes live Thursday. Same day the obligation starts. That is not a coincidence, and it is not inspiring confidence.

What the law actually requires

The timeline under Article 14 is a cascade. Within 24 hours of becoming aware of an actively exploited vulnerability, you file an early warning. Within 72 hours, a complete notification with technical details. A final report no later than 14 days after a corrective measure is available.

For severe incidents that are not actively exploited, the final report window stretches to one month. The distinction between “actively exploited” and “severe incident not actively exploited” is a judgment call you are now legally obligated to make correctly and document within a day.

The 24-hour clock starts when you “become aware.” The regulation does not specify timezone. A FreeBSD Foundation maintainer in California reading a mailing list at 11:45pm is now on the clock for a Brussels filing deadline.

Open source stewards are in scope

The CRA introduces a legal concept that has never appeared in EU regulation before: the open source software steward. Article 24 defines this as an entity that systematically provides software intended for commercial use, without necessarily commercializing it directly. Foundations and non-profits with a formal governance role over an open source project are the obvious targets. The Linux Foundation, the Apache Software Foundation, the FreeBSD Foundation, the OpenSSL Foundation.

Individual developers who commit to a public repository are not stewards. A company that ships a product built on open source code is not a steward, they are a manufacturer with a different set of obligations entirely and no carve-out. The steward category is narrowly defined but not empty.

Stewards have a lighter burden than manufacturers. Article 64(10) shields them from administrative fines. But the actual obligations are real: publish a coordinated vulnerability disclosure policy, cooperate with ENISA and national CSIRTs, and file reports through the SRP when actively exploited vulnerabilities appear in software in their stewardship.

The question of whether a foundation “becomes aware” when a vulnerability report lands in their bug tracker, or when a researcher contacts them directly, or when a national CERT sends them a heads-up, is a question the guidance does not fully answer. You get to interpret that gap under time pressure.

The SRP opens Thursday

The European Commission confirmed in September that the ENISA Single Reporting Platform would go live on September 11, the same day the obligations begin. That means there is no period of parallel running, no dry run, no pilot. The first real filing and the first time anyone outside ENISA has used the system are the same event.

This is not unusual for EU regulatory infrastructure. The GDPR’s supervisory authority complaint portals were in a similar state on May 25, 2018. You already know how that went.

What to actually do before Thursday

If you run a foundation, non-profit, or formal open source governance body: confirm which projects in your portfolio are in scope. The CRA covers products “with digital elements” intended for commercial use. A library used only internally is different from one shipped inside enterprise software by third parties, but the line is not obvious and your legal team needs to have looked at it before Thursday, not after.

If you are a commercial vendor shipping a product built on upstream open source: your obligations are under the manufacturer track, not the steward track. The 24/72-hour clock runs for you too, and you cannot outsource that filing to an upstream foundation.

If you are an individual maintainer with no formal organizational backing, you are almost certainly not a steward. But if your project is used commercially by others, you may hear from manufacturers who are trying to understand their own supply chain obligations and asking you questions you do not have time to answer.

The OpenBSD-adjacent pledge/unveil coverage from August has nothing to do with this, but I wrote it the week I started thinking seriously about CRA scope, and Theo’s approach to reducing attack surface is the right baseline comparison for what “systematic” open source stewardship can look like. The package registry supply chain piece from July is the other half of the problem: the attack surface the CRA is trying to get upstream maintainers to report on expands when your dependency graph is twelve layers deep and half of those layers are owned by accounts that haven’t been active in three years.

The regulation ships Thursday whether anyone is ready or not. That is how deadlines work.