EU Cyber Resilience Act: What Changes on 11th September 2026

Ask most people in the hardware business when the EU’s Cyber Resilience Act starts to bite and you will hear December 2027. That is the date on all the slide decks. It is also the wrong date to be worried about right now.

The first binding obligation under the CRA switches on in a matter of days, on 11 September 2026. From that morning, any company that makes a connected product available in the European Union has to tell regulators when a flaw in that product is being actively exploited, and it has to do so within 24 hours of finding out. Not 24 working hours. Not 24 hours after the patch is written. Twenty-four hours from awareness.

What makes this more interesting than the average compliance deadline is that it does not only apply to products launched after that date. It reaches back into the installed base. And the tool everyone is supposed to use to file these reports was not open for business when I last checked.

What actually changes on 11 September

Two things have to be reported, and the distinction matters because they run on slightly different clocks.

The first is an actively exploited vulnerability. The regulation defines this narrowly: there has to be reliable evidence that a malicious actor has exploited the flaw in a system without the owner’s permission. A theoretical weakness does not qualify. A CVE sitting in a database does not qualify. Someone has to be using it.

The second is a severe incident affecting the security of the product — something that damages, or could damage, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions.

For either one, the sequence is the same three steps. An early warning within 24 hours. A fuller notification within 72 hours, with an initial assessment and whatever mitigations exist. Then a final report — no later than 14 days after a corrective measure becomes available for a vulnerability, or within one month of the 72-hour submission for an incident.

The 24-hour form is lighter than the panic around it suggests. ENISA’s published field list makes only a handful of items mandatory at that stage: what kind of notification it is, the manufacturer’s name, the product, a title, and — for incidents — whether malicious activity is suspected. The technical detail is expected at 72 hours. That is a sensible design. Nobody has a root cause analysis in the first day.

The platform is not open yet

Here is where it gets awkward.

The CRA does not let manufacturers report however they like. Article 16 requires ENISA to build a Single Reporting Platform, and Article 14 notifications go through it. One submission, routed automatically to the incident response team in the country where the manufacturer has its main establishment, and to ENISA simultaneously.

The Commission’s position is that the platform will be operational by 11 September, with functional and security testing under way. ENISA says the same, and adds that a testing period is expected beforehand.

But go and read ENISA’s own step-by-step registration guide and the very first instruction tells you to open the platform website — followed by a parenthesis.

That parenthesis has been sitting there for a month. ENISA has also not yet published the list of national incident response teams designated as coordinators, which is the drop-down menu a manufacturer has to pick from during registration. And there is no API. ENISA states plainly that organisations may want to automate their reporting workflows, but no application programming interfaces are provided at this stage.

For a company shipping one product line, that is a minor annoyance. For a vendor with a large catalogue and a busy disclosure calendar, it means a human being filling in a web form against a 24-hour clock, possibly at three in the morning, possibly several times in one week.

Why this reaches devices already in people’s homes

Most of the CRA has a clean transitional rule. Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified after that date. Ship it now, and the design requirements do not chase you retroactively.

The reporting duty is carved out of that. The Commission’s own summary of the legislation states that reporting obligations apply to all products with digital elements made available on the Union market, including those already placed on the market before 11 December 2027.

Think about what that covers. Routers sold in 2022. Cameras from 2023. Smart plugs, baby monitors, robot vacuums, network-attached storage, the firmware in a car’s infotainment head unit. If a manufacturer becomes aware that a flaw in any of it is being exploited in the wild, the clock starts.

There is one limit, and it is a fair one. The obligation bites when a manufacturer becomes aware of active exploitation. ENISA has confirmed it does not extend to vulnerabilities the manufacturer already knew were being exploited before the reporting obligation applied. Old known problems do not have to be retro-filed on 11 September. New knowledge triggers the duty.

Which is a reminder that the weak point in this system has always been the same one. Plenty of exploited home devices are running firmware that was abandoned years ago by a company that will never file anything. If you want a sense of what that looks like in practice, our guide to checking whether your router has been compromised by a botnet covers the symptoms worth watching for on hardware nobody is patching.

Who has to report, and who is off the hook

The duty sits with manufacturers — the party that puts the product on the market under its own name or trademark. Not importers, not distributors, not retailers. They have separate obligations under the CRA, but Article 14 reporting is not one of them.

The interesting addition is open-source software stewards. This is a category the CRA invented for legal entities that systematically support the development of open-source software intended for commercial use, and that keep those projects viable — foundations, essentially, rather than individual maintainers. Article 24 gives them a reporting duty too, though a narrower one, limited to products they are actually involved in developing and to incidents affecting the systems they provide for that development.

On penalties: Article 64 puts breaches of Article 14 in the highest band, alongside failures of the essential cybersecurity requirements. That is up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Two lower bands sit beneath it at €10 million or 2%, and €5 million or 1% for supplying incorrect or misleading information to authorities.

Fines are set nationally, by each member state’s market surveillance authority, and Article 64 requires them to take the size of the business into account. So the headline number is a ceiling, not a forecast. It is also worth being clear that no enforcement action has happened yet, because the obligation has not started.

The full timeline, in one place

Date	What applies
10 Dec 2024	Regulation (EU) 2024/2847 enters into force. No obligations yet.
11 Jun 2026	Chapter IV applies. Member states designate notifying authorities; conformity assessment bodies can be notified. Already passed.
11 Sep 2026	Article 14 reporting obligations apply. Single Reporting Platform due to be operational.
11 Dec 2027	Full application. Essential requirements, CE marking, technical documentation, declared support periods, SBOMs.
11 Jun 2028	Existing EU type-examination certificates and approval decisions on cybersecurity requirements cease to be valid, unless they expired earlier.

What is not changing yet

It would be easy to read the September date as the moment the CRA arrives in full. It is not, and conflating the two is how compliance projects get mistimed.

None of the following applies until 11 December 2027: the essential cybersecurity requirements in Annex I, the CE marking obligation, the EU declaration of conformity, the technical documentation package, the requirement to draw up a software bill of materials in a machine-readable format, and the duty to state a product’s support period end date — month and year — at the point of purchase.

That last one is the change consumers will actually notice on a shelf. From December 2027, a connected device sold in the EU has to tell you the date its security updates stop. Not a vague promise of ongoing support. A date.

What happens to the reports

They do not become public. This is the part that tends to surprise people who assume a mandatory disclosure regime means disclosure to them.

A report goes to the coordinating CSIRT and to ENISA. That CSIRT then disseminates it to other national teams in countries where the product is available, and to market surveillance authorities as needed. ENISA’s submission guidance states that concerned CSIRTs receive the final report only after manual full dissemination by the coordinating team, which puts a human step inside a process otherwise built around hard deadlines.

In exceptional circumstances, on justified security grounds, that dissemination can be delayed. A Commission delegated regulation adopted on 11 December 2025 sets out the conditions. Where a manufacturer flags those circumstances at the 72-hour stage, ENISA itself receives only partial information until the coordinating team releases the rest.

Public visibility comes later and indirectly. ENISA is tasked with disclosing fixed vulnerabilities to the European Vulnerability Database, and with producing biennial trend reports, the first of which is due within 24 months of the reporting obligations starting. So the aggregate picture will eventually be public. Individual reports mostly will not be.

If you just own the gadgets

Nothing you have to do. No action, no registration, no setting to change. This is a regulation aimed at companies.

What it changes for you is slower and more structural. Over the next couple of years, the manufacturers selling into Europe have to build vulnerability handling processes that can actually respond inside a day, because the alternative is a fine calculated against global turnover. Firms that currently sit on a disclosure for six weeks while legal reviews the wording will find that option removed.

Whether that produces faster patches or just faster paperwork is the open question, and I would not want to guess. Reporting a flaw to a CSIRT and fixing it for customers are different activities, and the CRA mandates the first far more precisely than the second.

One practical note for anyone outside the EU reading this: the regulation follows the product, not the company. A manufacturer in Taiwan, California or Shenzhen that makes a connected device available on the EU market carries the same Article 14 duty as one in Dublin or Dortmund. Where there is no EU establishment, the reporting route runs through an authorised representative established in the Union.

Frequently asked questions