CRA readiness for hardware teams: what to decide before layout

Most Cyber Resilience Act guidance is written for software teams: secure development lifecycle, vulnerability disclosure, SBOM tooling. Useful, and it misses where the money is.

The decisions that determine whether a product can comply are made in hardware, months before anyone writes the firmware — and several of them are irreversible once the board is laid out.

This is an engineer’s summary of what to decide and when. It is not legal advice, and the definitive scoping question for your product belongs with counsel.

The shape of it

Regulation (EU) 2024/2847 covers “products with digital elements” — effectively anything with software that connects directly or indirectly to a device or network — placed on the EU market. It came into force in December 2024, reporting obligations arrive in September 2026, and the full requirements apply from December 2027.

December 2027 sounds distant. It is not, if your product development cycle is eighteen months and your hardware stays in production for five years after that. Boards being designed now will still be shipping when the regulation applies in full.

The five hardware decisions

1. Root of trust — before you pick the SoC

The CRA’s essential requirements point toward products that protect the integrity of their own software. In practice that means secure boot: each stage verifies the next against a key the device cannot be talked out of.

That capability is in the silicon or it is not. It cannot be added later, and it varies enormously across parts you might otherwise consider equivalent.

If secure boot matters to your product, it belongs in the SoC trade study as a hard filter, not a nice-to-have. Discovering after layout that your chosen part has no usable key storage means a respin at best.

2. The update path — an architecture decision with a BOM cost

You must be able to ship security updates through the support period. That means:

Enough flash for two images. A/B partitioning is the standard approach: write the new image to the inactive slot, verify, switch, and keep the old one to roll back to. That is roughly double your firmware footprint, plus headroom for years of growth. Sizing flash to today’s image plus 20% is how a product becomes unpatchable in year three.

A delivery mechanism. Over the air, over the network, or via a technician — but a defined one. “The customer can send it back” is not an update path for a product with a five-year obligation.

Power-loss safety. An update interrupted by power loss must not brick the unit. That is hold-up capacitance and a bootloader that can always fall back — and hold-up energy is a component decision.

3. Support period — which is a silicon longevity decision

Security updates for the expected product lifetime, five years as the reference. So:

• Does your SoC vendor guarantee availability and security support that long? Renesas, NXP, TI and ST all run longevity programs with different terms. Consumer-grade parts frequently do not.
• Will your RTOS or Linux kernel still receive security patches, or will you be maintaining a fork nobody else is looking at?
• Is every third-party component still going to be supported, or will you own it by default?

A product with a five-year security obligation on silicon with a three-year support horizon is a commitment you cannot keep. That is a procurement decision disguised as a technical one.

4. SBOM — which starts in the BOM

You will need a software bill of materials. That is generated from the build, but its accuracy depends on knowing what is actually in your product — including the firmware inside modules you bought rather than wrote.

The radio module, the GNSS receiver, the fuel gauge, the sensor with an MCU inside it: each carries software you did not write and may not be able to update. At component selection, ask whether the vendor publishes an SBOM and how they ship security updates. Some do this well. Some will not answer the question, and that answer is itself information.

5. Attack surface — which is a schematic decision

Every interface is surface. Debug headers, unused UARTs, a test connector nobody removed for production, a bootloader that accepts unsigned images over USB because it was convenient during development.

Decide at schematic stage which interfaces exist in production, how they are disabled, and whether “disabled” means a depopulated resistor or something an attacker cannot reverse with a soldering iron.

A practical sequence

Now, for anything in early design: Add secure boot capability and vendor longevity commitment as hard filters in the SoC trade study. Size flash for A/B plus growth. Write down the update mechanism.

Before layout: Fix the production interface list. Decide debug closure. Confirm key provisioning works in your manufacturing flow — signing keys in a contract manufacturer’s hands is a process problem worth solving before it is urgent.

Before production: Vulnerability handling process. SBOM generation in the build. Coordinated disclosure contact. Documented support period.

Continuously: Monitor advisories for everything in the SBOM, including the firmware inside bought-in modules.

Why this is worth doing early rather than well

The cost curve is brutal. Choosing a different SoC during a trade study costs a few days. Discovering at pre-production that your chosen part cannot store a key securely costs a respin, a schedule slip, and possibly a market.

Every hardware manufacturer selling into the EU is on the same deadline, and most have not started. The ones that get this right will do it by treating a handful of CRA-driven requirements as ordinary design constraints in the next project — which is the cheapest way it will ever be done.

---

we fold these into the SoC trade study and the schematic review as standard, because retrofitting them is the expensive path. If you are choosing silicon for a product that will still be shipping in 2028, it is worth a conversation now.