Cyber Resilience Act: What It Asks of Hardware

Two dates, and the near one gets missed

Regulation (EU) 2024/2847, the Cyber Resilience Act, covers “products with digital elements” placed on the EU market. In practice that means anything with firmware in it, which for consumer and health hardware means almost everything shipping today.

Most planning decks show one date: 11 December 2027, when full compliance is required and a non-conforming product can no longer legally be placed on the market. That is the date people are building roadmaps against.

The date that arrives first is 11 September 2026, when the reporting obligations under Article 14 begin. It gets missed because it is not a product-design deadline, so it does not appear on a hardware schedule.

It should. Here is why.

The reporting clock reaches backwards

From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting the product’s security, reports on a staged clock:

Stage	Deadline from becoming aware
Early warning	24 hours
Technical notification	72 hours
Final report	14 days (exploited vulnerability) / 1 month (severe incident)

Reports go to ENISA and the relevant national CSIRT.

The part worth reading twice: the reporting duty applies to products already made available on the EU market, including units placed there before the deadline. The design requirements in Annex I attach to products placed on the market from December 2027 onward, and to earlier products only if they undergo a substantial modification. The reporting duty has no such cutoff.

So the practical question for a brand in September 2026 is not “is my next product compliant.” It is:

A device we shipped in 2023 has a vulnerability under active exploitation. Do we know within 24 hours, and do we know what is inside it well enough to describe the problem?

For most hardware brands the honest answer to the second half is no. That is a manufacturing records problem before it is a security problem.

→ Another EU deadline that turns into a housing decision: EU Battery Regulation 2027: Removable Batteries

The support period is a bill-of-materials decision

Annex I requires a declared support period of at least five years, or the product’s expected lifetime if that is shorter, with an end date the buyer knows at the point of purchase. Across that period the manufacturer handles vulnerabilities and supplies security patches free of charge.

Read that as a sourcing constraint, because that is what it is.

If the wireless module in your design runs a vendor SDK that stops receiving security patches in its third year, you cannot patch what sits on top of it. You will have declared a five-year support period at point of sale and lost the ability to honor it in year three, through a decision made during component selection.

This turns two questions into part of module qualification, alongside price, lead time and second-source availability:

• How long will this vendor issue security patches for this part, in writing, and what happens at end of life?
• Is there a second source that runs a stack we could migrate to without redesigning the board?

Neither question is normally on a BOM review. Both belong to the same conversation as supply risk, because they are the same kind of risk: a part that becomes unavailable, in one case commercially and in the other legally.

→ How parts get graded and what a red grade means: Component Supply Risk Matrix for OEM Projects

The SBOM has to describe what is actually in there

Annex I Part II requires a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies of the product.

For a web application that is a build-tool output. For a physical product it is an assembly question, because the firmware is rarely all yours. A typical connected consumer device carries:

• the application firmware written for this product
• a vendor SDK that arrived with the wireless module
• a protocol stack (Bluetooth, Wi-Fi, Thread) shipped as a binary blob
• an RTOS
• open-source libraries pulled in by any of the above

The brand normally owns the first item and has visibility into none of the rest, because those arrived through the manufacturer and its module suppliers. Assembling a real SBOM means asking the factory, and asking its suppliers in turn.

That request is far cheaper during development than after an incident. It is also the point at which you find out whether your module vendor will tell you what is in their blob, which is itself worth knowing before you design them in.

Secure by default and the ability to be updated

Two more Annex I requirements land on decisions made early in hardware.

Secure by default means the product ships with a secure configuration: no shared default passwords, no unnecessary services or ports open, a minimized attack surface. These are firmware defaults, and firmware defaults are usually written by whoever writes the firmware. If that is your manufacturer, the requirement is theirs to implement and yours to specify.

Free security updates across the support period presume the product can actually receive an update. Whether it can is not a software decision:

• Flash budget. A dual-partition scheme for safe over-the-air updates roughly doubles the space firmware needs. Discovering this after the BOM is frozen means either a memory change or no OTA.
• Radio and connectivity. A device with no path to the internet can only be updated in the field or through a companion app, both of which have completion rates far below what a five-year obligation assumes.
• Power. An update that runs on a low battery and bricks the unit is worse than no update, so update logic needs a power floor, which needs a fuel gauge.

None of these can be retrofitted cheaply. All of them are decided during the engineering review, before tooling.

→ The review stage where constraints like these surface: DFX Risk Review Before Cutting Tooling

What this looks like on a project

For a product entering development now and shipping into the EU, three things change:

1. Module qualification gains a patch-lifetime question. Ask for the vendor’s security support commitment in writing, and treat “we don’t publish that” as the answer it is.
2. The SBOM becomes a deliverable, not an afterthought. Name it in the development agreement alongside drawings and test reports, so it arrives with the product rather than being reconstructed under a 24-hour clock.
3. Updatability gets specified before tooling. Flash headroom, partition scheme and update path are cheap to decide at concept stage and expensive to add once the enclosure exists.

For products already on the market, the near-term question is narrower and more urgent: can you find out what is inside them, and how fast?

A note on scope

This is a reading of published regulation, not legal advice, and the CRA’s implementation detail is still being filled in through standards and guidance. Confirm how it applies to your specific product class and market with qualified counsel before building a plan on it. What is settled enough to design against is the direction: security support has become a declared, dated commitment, and the decisions that make it possible or impossible are made in hardware, early.

→ The board-level side of this, from schematic to SMT line: Consumer Electronics Contract Manufacturing