The CRA clock is already running on devices you shipped years ago

Over the last few weeks I have read more articles about the Cyber Resilience Act than I would like to admit, and a surprising number of them contradict each other. One says the reporting platform is not live yet. Another says every known CVE in your firmware has to be reported within a day. A third says you only need to care from December 2027. Most of them were written before the Commission published its official guidance at the end of July, and some of them are simply wrong.

So I went back to the regulation itself, the Commission's guidance and ENISA's own documentation for the reporting platform, and tried to work out what actually applies today to a small company that makes connected hardware. This is what I found. I am an engineer and nothing here is legal advice, but everything below comes from the official texts and I have tried hard to keep my own opinions clearly separate from them.

The part that is already in force

The CRA has been law since December 2024, and most of it applies from 11 December 2027. That later date is the one most people remember, and it covers the big design obligations, the technical documentation and the CE marking.

The reporting duty in Article 14 is different. It has applied since 11 September 2026, and it covers every product with digital elements available on the EU market, including products that were placed on the market long before the CRA existed. If you sold a fleet of LTE trackers in 2021 and they are still out there, the reporting duty applies to them today. The Commission's guidance goes further and says it keeps applying after a product's support period has ended. The vulnerability handling requirements end with the support period, and the duty to report stays with the product for as long as it is in use.

This was the single most useful thing I learned, because it means every company with devices in the field needs to act now, including the ones that thought the CRA was a 2027 problem.

What actually has to be reported

There are exactly two triggers. The first is an actively exploited vulnerability, which the regulation defines as one where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. The second is a severe incident, meaning something that affects or could affect the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code running on the product or in the user's network. A stolen code signing key or a compromised update server would clearly count.

What does not have to be reported matters just as much. A CVE appearing in a database for a library you ship is not, by itself, an actively exploited vulnerability in your product. The guidance is explicit here. If a third-party component has a vulnerability that cannot be exploited in your product, for example because the vulnerable code is never reached, or that has not been exploited in your product, mandatory reporting does not apply. You still have to handle it, tell the maintainer of the component and fix it within your support period, but the 24-hour clock does not start.

The guidance also settles when the clock starts. You are considered aware when, after a prompt initial assessment, you have a reasonable degree of certainty that exploitation is happening. A vague email from a stranger does not start the clock. Sitting on that email for a week without looking at it is also exactly what the guidance warns against, since the emphasis is on assessing quickly. And there is no retroactive duty. Exploitation you already knew about before 11 September 2026 does not need to be reported now, although anything you learn about after that date does.

The clock itself

Once you are aware, the sequence is fixed. An early warning goes in within 24 hours, with little more than what happened and which EU countries the product is sold in. A fuller notification follows within 72 hours, with an initial assessment and any mitigations users can apply. The final report is due 14 days after a fix or mitigation is available for an exploited vulnerability, or one month after the 72-hour notification for a severe incident.

Alongside that, you have to inform the users who are affected. The guidance treats this in a sensible, risk-based way. It does not have to mean a public announcement with technical details, and for products used in sensitive environments it explicitly allows you to limit the information to the customers concerned until a fix is out. Once a security update exists, the vulnerability handling rules do expect you to publish information about the fixed vulnerability.

There is one detail in the penalties that I think will matter to many readers. Micro and small enterprises cannot be fined for missing the 24-hour early warning deadline. The other deadlines and the obligations themselves still apply in full, and for everyone else the fines for breaching Article 14 go up to fifteen million euros or two and a half percent of worldwide turnover, whichever is higher.

Where you report, and what that means in practice

Reports go through ENISA's Single Reporting Platform, which has been live since 11 September. You submit once, to the national CSIRT of the country where your company has its main establishment, and the platform shares it with ENISA and the other countries involved.

Two practical details from ENISA's documentation surprised me. Access requires a personal EU Login account with multi-factor authentication, held by someone the company designates, and registration has a verification step. There can be one primary representative and up to twenty secondary ones. My strong advice is to do this now, on a quiet afternoon, and not at two in the morning with the 24-hour clock already running.

The second detail is that the platform has no API at launch. Every notification is typed into a web form by a person. Any tool that promises to submit your CRA reports automatically is promising something the platform does not currently support. What software can do is everything around the form, which is exactly where most of the time goes.

Your backend is part of the product

This one matters a lot for IoT. The CRA defines a product to include its remote data processing, which the guidance explains as the server-side software the manufacturer designs, without which the product could not perform one of its functions. Its own worked example is a smart thermostat with an app and a cloud backend running on third-party infrastructure, and the conclusion is that the backend is part of the product for CRA purposes, reporting included.

For a typical connected device this means the Lambda functions, the MQTT rules, the provisioning service and the API behind the mobile app are all in scope. A managed service you only configure, such as a hosted MQTT broker, is treated more like a component you have to assess and choose carefully. In practice, if your provisioning service gets breached, that is a CRA incident for your device.

Two claims I keep seeing that are wrong

The first is that the support period is five years. The regulation sets five years as a minimum, unless the product is genuinely expected to be used for less, and the Commission's guidance says plainly that five years is not a default. A product expected to stay in use for longer needs a longer support period. Anyone shipping energy meters, industrial controllers or building sensors that stay on a wall for ten or fifteen years should read that sentence twice. The end date also has to be shown, at least as month and year, at the time of purchase.

The second is that you need a complete, perfect SBOM of everything down to the last transitive dependency. The text asks for a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Going deeper is good practice and makes the vulnerability work much easier, but the legal floor is lower than many articles suggest. For ESP-IDF projects, Espressif already ships tooling that generates an SPDX SBOM and checks it against known vulnerabilities, which covers a large part of this for free.

What a small team actually needs

When I put all of this together, the work for a typical hardware company with a few thousand devices in the field turns out to be mostly about being able to answer a few questions quickly. Which firmware versions are running where, and what is inside each of them. Which of the vulnerabilities published this week touch a component you ship, and whether the vulnerable code is reachable in your build. Who in the company owns the decision that something is being actively exploited, and who has the EU Login account to file the early warning. How you will tell affected customers, and how you will prove later that the fleet actually took the fix.

None of these needs a large compliance platform. They need an SBOM per firmware release, a list of device versions from your fleet backend, a daily check of new vulnerabilities against those SBOMs, a short written procedure for the 24-hour decision, and a template for each of the three reports with the fields ENISA asks for. Most teams already have half of the data in their build system and their IoT backend. It just has never been joined up.

That joining up is the part I find most interesting as an engineer, and it is what I am building tooling for right now. The first pieces are free on this site already, a reporting clock that works out your deadlines and lists the fields ENISA asks for at each stage, a scope check and a security.txt generator. If you make connected devices and are working through any of this, especially if you are a small team that suddenly has to own a 24-hour clock, I would be glad to talk.

A note on what is still moving

Some of this will keep changing. The harmonised standards that will make the 2027 obligations easier to demonstrate are still being written, ENISA updates its platform guidance regularly, and the Commission described its July guidance as a first set. The core of the reporting duty is in the regulation itself, though, and that part is settled. If your devices are on the EU market, the clock has been running since September.