The Cyber Resilience Act for connected products: what manufacturers need to do now

If you build a product with a chip, a radio or a software update mechanism and you sell it in the European Union, the Cyber Resilience Act is no longer a future problem.

Regulation (EU) 2024/2847 entered into force in December 2024. Since 11 September 2026, manufacturers have to report actively exploited vulnerabilities and severe incidents. From 11 December 2027, most of the remaining obligations apply, including the security requirements a product must meet before it can carry the CE marking.

I’m not a lawyer, and this is not legal advice. But I’ve spent years working on embedded security products, and I see the same pattern in many teams: the regulation is read as a compliance document, when most of what it asks for is an engineering capability.

What changed in September 2026

The first obligation that became enforceable is reporting. When a manufacturer becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting its security, it has to send an early warning within 24 hours, through the single reporting platform run by ENISA.

Two details matter.

• The duty applies to products already on the market, not only to new ones.
• Twenty-four hours is not enough time to start looking for information. It is only enough time to use information you already have.

So the real question is not “do we know the rule?”. It’s “can we answer, in a few hours, which of our products contain the affected component, which versions are in the field, and who is responsible for the fix?”.

What applies from December 2027

From December 2027 the CRA’s essential requirements apply in full. In practical terms, products with digital elements must be designed and maintained with security in mind for their whole support period. Among other things, that means:

• no known exploitable vulnerabilities when the product is placed on the market;
• secure default configurations;
• the ability to deliver security updates, separately from feature updates where possible;
• protection of the confidentiality and integrity of data, including through state-of-the-art cryptography;
• a vulnerability handling process and a software bill of materials (SBOM);
• a defined support period, communicated to users.

Breaches can be expensive: for the essential requirements, fines can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.

The part people underestimate: knowing what is inside your product

Every obligation above depends on one thing: an accurate, current picture of what your product is made of.

Not just a list of software components. A picture of how they relate to each other.

• Which firmware image runs on which hardware revision?
• Which keys sign which updates?
• Which certificates establish the identity of a device?
• Which third-party libraries handle cryptography, and in which versions?

Many organisations have this information. It’s simply spread across engineering teams, manufacturing systems, suppliers and old documentation. That works until the day you have 24 hours to act.

Cryptography is part of “state of the art”

The CRA does not name specific algorithms. It asks for protection that reflects the state of the art.

That phrase has a timeline attached to it. NIST published its first post-quantum cryptography standards in August 2024. The European Union’s coordinated roadmap asks Member States to start the transition by the end of 2026 and to protect high-risk use cases by 2030. A connected product placed on the market in 2028 with a ten- or fifteen-year support period will live well inside that transition.

This doesn’t mean every product has to ship with post-quantum algorithms tomorrow. It means you need to know where your cryptography is, and how you would change it. I wrote more about this in Why I’m building Shorium.

Where I would start

If I were responsible for a portfolio of connected products today, I would do four things, in this order.

1. Map the products in scope. Which products have digital elements, which are on the market, and what support period you can realistically commit to.
2. Build the inventory you will need in a crisis. Components, versions, keys, certificates and suppliers, linked to the products and versions in the field. An SBOM is the start, not the end.
3. Rehearse the 24-hour report. Pick a real vulnerability from last year and time how long it takes to answer: affected products, affected versions, owner, mitigation.
4. Check the update chain. Can you deliver a signed security update to every product you still support? What happens if a signing key or an algorithm has to change?

None of these steps requires a new tool on day one. They require someone to own the question.

The opportunity inside the obligation

It’s easy to read the CRA as cost. I think it is also a forcing function.

Teams that can see their products clearly, and change them safely, ship better products. The regulation simply sets a date by which that capability stops being optional.

If you want to compare notes on how your organisation is approaching it, get in touch.