The Cyber Resilience Act's reporting duty is live. Most manufacturers' processes are still theatre.

Today, 11 September 2026, the Cyber Resilience Act’s reporting duty enters into force across the European Union. Not in December 2027, when the essential product requirements land and everyone has been told to expect the real reckoning. Today. If you manufacture a product with digital elements and sell it into the EU, the clock on your first notification starts running from this point, whether your organisation marked the date or not.

I wrote in July that the Cyber Resilience Act was the regulation nobody was watching closely enough, the one that can pull a product off the market rather than just fine the company behind it. That piece focused on the big compliance picture: scope, categorisation, the relationship with NIS2. This one is about the much narrower, much sharper obligation that just went live, and about the uncomfortable gap between how many manufacturers say they know about it and how many can actually act on it within the hours the law gives them.

The date nobody was watching

Most coverage of the CRA still orbits December 2027, and understandably so, since that is when the essential cybersecurity requirements and conformity assessment obligations apply in full. But Article 14 of the regulation carved out a separate, earlier date specifically for reporting: from 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting their products, and that duty applies to products already on the market, not just new launches.

The European Commission published its practical guidance on this on 27 July 2026, only weeks before the date took effect. That is a narrow window for an obligation with a 24-hour first deadline attached to it. The essential requirements in December 2027 give manufacturers roughly fifteen months of runway from this point. The reporting duty gave far less.

What exactly do you have to report?

This is the question that trips people up, and it is worth answering precisely rather than in general terms.

You report an actively exploited vulnerability, meaning there is credible evidence someone is using it against your product right now. You report a severe incident, meaning something that actually compromises your product’s security, not merely a theoretical weakness. What you do not report is every CVE that gets assigned to your codebase, every finding from your own penetration test, or every submission through your responsible disclosure programme or bug bounty, unless there is evidence it has actually been exploited. The webinar the Dutch Ministry of Economic Affairs and Climate Policy and the National Cyber Security Centre (NCSC) ran on 27 August was blunt about this distinction, and for good reason: without it, manufacturers would either drown their national CSIRT in noise or, worse, assume every vulnerability report needs the same 24-hour urgency and burn out the team that is supposed to handle the ones that matter.

You can still report the lower-severity cases voluntarily, and there are good reasons to build that habit. But the legal duty sits specifically on active exploitation and severe incidents, and knowing where that line falls is the first thing your incident response process needs to get right.

The clock does not pause for your incident response meeting

Once you know, the timeline is staged and unforgiving. An early warning goes out within 24 hours of becoming aware. A fuller notification follows within 72 hours, covering what you know by then about the nature, impact, and mitigating measures. A final report closes it out: fourteen days after a corrective measure becomes available for a vulnerability, or one month for a severe incident, according to the European Commission’s guidance.

Freshfields’ analysis of the new obligation makes a point worth sitting with: the reporting periods begin the moment you become aware, and the clock does not stop at weekends or on public holidays. There is no grace period for the fact that your security lead was at a conference, or that the incident happened on a Friday evening. If your organisation does not already have a defined process for who assesses a report, who decides it clears the threshold, and who submits it, you are building that process for the first time under a live 24-hour deadline, which is precisely the wrong moment to build anything.

Reporting itself runs through your national CSIRT, the NCSC in the Netherlands, and the EU-wide Single Reporting Platform operated by ENISA, so a manufacturer in Belgium, Germany, or anywhere else in the EU follows the same staged timeline through their own national point of contact. The mechanics differ slightly by member state; the obligation and the deadlines do not.

Why are the readiness numbers this bad?

Here is where the “most manufacturers’ processes are theatre” claim needs to earn its keep, and the survey data backs it up more starkly than I expected.

ENISA’s SME Cyber Resilience Maturity Assessment Model, published on 13 July 2026 and based on fieldwork with 194 organisations across 31 countries, found high awareness of the CRA but consistently weak practical readiness, with incident response and product lifecycle management scoring as the two weakest domains overall. Awareness that a law exists is not the same as having a process that can act inside a 24-hour window.

The Linux Foundation and OpenSSF’s 2026 CRA readiness research, drawn from 843 respondents, tells a similar story from a different angle. Sixty-six percent still did not know what they actually needed to do to comply, a figure that had barely moved from 62 percent the year before. Only 41 percent of manufacturers expected to reach full compliance by the December 2027 deadline, and only 34 percent correctly identified that date in the first place. Among respondents who were aware of the CRA at all, 54 percent still could not distinguish clearly between a manufacturer’s obligations and a steward’s.

None of that is a knock on any individual compliance team. It reflects a regulation that moved from abstract to operational faster than most organisational processes could follow. But it does mean that a meaningful share of manufacturers reading this crossed the 11 September line with no tested process behind them, which is exactly the scenario the reporting duty was designed to catch out.

Who actually has to report?

Under the CRA, the reporting obligation sits with the manufacturer, the entity that places a product with digital elements on the EU market under its own name or brand, and organisation size does not exempt you. An importer or distributor generally does not carry an independent reporting duty, unless it sells under its own brand or substantially modifies the product, in which case it effectively becomes the manufacturer for that product. Open source software stewards face a lighter version of the same duty, reflecting the different relationship they have with the products they maintain. Small and micro enterprises are fully in scope too; the only concession the Dutch NCSC has confirmed is that there is no penalty for missing the strict 24-hour window in that category, which is a mitigation, not an exemption.

One detail worth flagging because it causes real confusion: the CRA itself does not require any advance registration before you can report. You do not need an account or a login to submit a notification. That is a deliberate design choice, separate from the registration duty that exists under the Cyberbeveiligingswet (the Dutch NIS2 transposition) for organisations that also fall under that law. The two obligations run in parallel, not as one combined process, and conflating them is an easy mistake to make.

What does “prepared” actually look like?

Preparing for the CRA’s reporting duty is not complicated in principle. It is demanding in practice, which is a different problem.

Start with an honest inventory of what is actually in your products, ideally through a Software Bill of Materials, because you cannot assess whether a reported vulnerability affects you if you do not know what components you ship. Set your own internal thresholds in advance for what counts as active exploitation or a severe incident, so that judgement call is not being made for the first time under pressure. Build an escalation path with named roles: who signals, who decides, who submits. Draft templates for the early warning, the 72-hour notification, and the final report now, while nobody is under a deadline. And align this with whatever else you already report under, since a fair number of manufacturers reading this also sit under the Cyberbeveiligingswet or the AVG, and running three uncoordinated reporting processes is its own risk.

This is, not coincidentally, the same discipline I argued for in July when I wrote about the CRA’s broader compliance demands: know what you have, categorise it honestly, and build the paperwork before the regulator asks for it. The reporting duty has simply moved that argument from “eventually” to “now.”

If a customer told you this morning that someone was actively exploiting a vulnerability in your product, would your organisation know, within 24 hours, exactly who picks up that report? If the honest answer is “we’d figure it out,” the reporting duty did not go live today for nothing.

Sources

• European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
• Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
• Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
• Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.