Nine days from now, on 11 September, the reporting half of the EU Cyber Resilience Act switches on. Not the whole regulation — that's 11 December 2027, and that's the date everybody has pencilled in. This is the other one. The one nobody put in the calendar.

The split is the part people keep missing. Conformity assessment, secure-by-design, the essential cybersecurity requirements, CE marking your firmware: all 2027. Article 14, which says that when a vulnerability in your product is actively being exploited you have 24 hours to say so out loud: next Friday.

What the clock actually says

Awareness starts it. Early warning within 24 hours. Fuller notification within 72. Final report no later than 14 days after a corrective measure is available. Severe incidents get a month for the final report, same 24/72 opening.

The 24-hour submission itself is deliberately small — notification type and level, who you are, which product, a title, and for incidents whether you reckon somebody did it on purpose. That's it. Which is genuinely sane, and I'd rather say so than pretend otherwise: the alternative is a regulation that makes you write a postmortem while the building is still on fire. It's a flare, not an analysis.

The bit that catches people is scope. This isn't about products you ship after the CRA fully applies. Article 14 covers everything with digital elements sitting on the EU market on 11 September, including whatever you put there years ago. A product past the end of its support window is still in scope while it's still out there being used. So if you've been mentally filing this under "we'll handle it during the 2027 compliance push", the thing you're deferring has already started.

And the portal opens the same day

Here's the part I enjoyed more than I probably should have.

Reports go through the Single Reporting Platform, a central intake run by ENISA. One report, one place, fanned out to whoever needs it downstream. That's a good design — the alternative was filing separately with 27 national authorities, which would have been its own special kind of hell.

It goes live on 11 September. The same day the obligation does. No soak period, no dry run against a staging endpoint, no opening it in July so people can find the sharp edges while nothing's at stake.

And according to ENISA's own FAQ, there's no API at launch. Mandatory reports go through the web portal. By hand.

Sit with that one for a second. You have a 24-hour deadline that can start at three in the morning on a Sunday, and the submission mechanism is a human being, awake, with a browser, typing.

And look, I want to be angrier about this than I actually am, because I know exactly how it happened and it isn't villainy, it's scope cuts. Ship the portal, API in v2. Every team on earth has made that call. It's just an unusually funny place to land it, because a 24-hour clock is precisely the requirement you'd want out of human hands, and the regulation writing the clock and the tool serving the clock appear to disagree about that.

Read the text, too: nothing in Article 14 conditions the deadline on the tooling being pleasant. The obligation is not waiting for the API.

If you maintain open source, mostly relax

The CRA's first draft was genuinely ugly for open source, and the shouting that followed actually worked — not a sentence I get to write often.

Where it landed: not being monetised isn't commercial activity. A project on GitHub with no paid support, no commercial dual licence, no sponsored roadmap isn't in scope, and individual contributors to it carry no CRA duties. That's a deliberate carve-out, not a loophole somebody found.

Above that sits a category invented specifically for this mess: the open source steward. Roughly, a legal person — a foundation, that shape of thing — that sustainably supports development of FOSS which ends up used commercially. Stewards get Article 24, which is a far lighter deal than the manufacturer obligations: document a cybersecurity policy, cooperate with market surveillance authorities when they ask, report actively exploited vulnerabilities and severe incidents affecting your development infrastructure. No conformity assessment. Nobody is CE-marking a tarball.

That's about as good as the shape of the problem allows. The regulator wanted a named party for widely-used software, and rather than pretend every maintainer is a manufacturer, they built a tier for the entities that can actually carry a policy.

Where it goes fuzzy is the middle — you, with a side project, a sponsors page and one paying support customer. The Linux Foundation and OpenSSF readiness report has the number on this: 61% of non-commercial developers are unsure of their own status. That isn't ignorance. That's a definition needing a lawyer to apply, pointed at a population that doesn't have one. The ORC working group's steward FAQ is the least painful place I've found to work out which box you're in.

Nobody's ready, and it isn't close

Same report, and the headline numbers are rough. 66% of respondents were "not familiar at all" or "only slightly familiar" with the CRA — 72% in the US and Canada. Of the people who are aware of it, 41% still haven't worked out whether it applies to them. That's off 843 respondents, up 23% on last year, alongside a security analysis across more than 12,000 open source projects.

The North America number is the one I'd stare at. The CRA is about the EU market, not about where you're incorporated. If your thing is downloadable from Europe as part of a commercial offering, geography is not the escape hatch people are assuming it is.

What I'd actually do this week

Not much. But not nothing.

Work out whether you're a manufacturer, a steward, or out of scope. Ten minutes with the definitions, and most people land on out-of-scope and get to stop reading.

If you're in scope, someone has to own the clock — and the failure mode isn't refusing to report, it's not noticing that the thing you're staring at counts as actively exploited until Tuesday. So put the question in your incident template. One line: does this look exploited in the wild, and if so, when did we first know? That second timestamp is the whole ballgame, because the clock starts at awareness, and you want your own record of when awareness happened rather than reconstructing it three weeks later from Slack scrollback.

Then go and open the portal on the 11th, before you need it, while nobody is shouting at you.

So

I've got no real complaint about the regulation. The 24/72/14 shape is roughly what decent incident response looks like anyway, and the open source carve-outs came out more thoughtful than that first draft suggested we'd get.

What I keep turning over is the gap between a compliance calendar and an engineering one. On paper it's one date. In practice, on the 11th, somebody gets to discover — in production, at whatever hour their vulnerability picks — that the last mile of a continent-wide reporting regime is a form.

Anyway. Nine days. Go and find out whether it's your problem.