Cyber Resilience Act firmware architecture

On September 11, 2026, the first hard deadline in the EU’s Cyber Resilience Act took effect: any manufacturer placing a “product with digital elements” on the EU market now has to report actively exploited vulnerabilities to ENISA within 24 hours of learning about them. Full compliance, including CE marking under the new rules, is not due until December 2027. But the reporting clock is already running, and it caught a lot of small hardware companies without an answer to the question a distributor, investor, or customer is now asking them: what’s in your firmware, and how do you patch it?

If you build a connected product and sell it in Europe, this is not a paperwork problem you can hand to a consultant after the fact. It’s a set of engineering decisions — bootloader architecture, update signing, dependency tracking — that are cheap to make while a board is still on a schematic and expensive to bolt on after it has shipped.

What actually changed, and when

The CRA’s obligations arrive in stages, and it’s easy to conflate them:

Date	What kicks in
September 11, 2026	Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours of becoming aware of them
December 11, 2027	Full compliance: CE marking under the CRA, technical documentation, conformity assessment, and the broader secure-by-design obligations

The gap between those two dates is where most of the current confusion sits. Companies are being told, correctly, that they have until late 2027 to be fully compliant — and concluding, incorrectly, that nothing is required of them yet. The reporting obligation is already live, and reporting a vulnerability you can’t actually patch (because there’s no signed update path, or no record of which library version is running in the field) turns a disclosure requirement into a much worse conversation with a regulator.

Who the law is actually talking to

The CRA’s obligations attach to the “manufacturer” — the entity that places the product on the EU market under its own name or trademark. If a startup designs a connected sensor, has the firmware written under contract, and sells it under its own brand, that startup is the manufacturer, full stop, regardless of who wrote the code. A design or contract manufacturing partner isn’t the legal manufacturer unless it’s also the one putting its name on the box and selling into the EU.

That distinction matters for how you read anything written about this, including this note. It also doesn’t change the engineering reality: whoever ends up legally responsible for a 24-hour disclosure and a five-plus-year update commitment needs the underlying capability — a bill of materials for the software, and a way to ship a signed fix — to exist. If that capability wasn’t designed into the product, it’s the manufacturer’s problem to solve, but it’s the firmware architecture that determines whether solving it is a weekend or a hardware respin.

Three things that are nearly impossible to retrofit

A software bill of materials. The CRA requires a machine-readable record of what’s in the product’s software — RTOS version, vendor HAL, any third-party library, even code generated by a tool like STM32CubeMX or MCUXpresso. Producing this after the fact means reconstructing, from memory and old commits, exactly which version of FreeRTOS, lwIP, or mbedTLS shipped in a board that went out eighteen months ago. Producing it as part of the build — a script that walks the dependency tree and emits a CycloneDX or SPDX file on every build — costs almost nothing when it’s there from the first commit.

A signed, fallback-safe update path. This is the one that actually requires a hardware decision, not just a firmware patch. Parts like the STM32L5/U5/H5 families with TrustZone-M, Nordic’s nRF5340 with its separate application and network cores, or NXP’s EdgeLock-equipped i.MX RT parts have a documented secure boot chain and are built to hold two firmware images so a failed update falls back to a known-good one. A board designed around a part without that support, with a single flash bank and a bootloader that trusts whatever shows up over the debug port, cannot get a signed dual-image update path added later without more flash, a different boot ROM, or in the worst case a new MCU. That’s a respin, not a firmware release.

A process for watching dependencies. An SBOM is only useful if someone is checking it against CVE feeds for the RTOS and libraries it lists, and there’s a repeatable way to build, sign, and publish a patched image when something turns up. A one-off “we’ll deal with it if it happens” plan is what turns a 24-hour reporting window into a missed one.

What a careful engineer checks, deadline or not

None of this requires being confident you’re in scope of the CRA today. It’s worth checking regardless, because the same habits reduce field failures that have nothing to do with regulation:

• Does the chosen MCU have a documented secure boot path in its reference manual, or does “secure” mean “we haven’t looked at the debug port yet”?
• Is the flash partitioned for at least two firmware images, with a bootloader that verifies a signature before it jumps to either one?
• Does the build produce a component list automatically, or does someone have to remember to update a spreadsheet?
• Who, specifically, is watching CVE feeds for the dependencies this product ships with, six months after it’s out the door?
• If a critical fix were needed tomorrow, how many boards in the field could actually receive it, and how would you know they did?

A “no” to any of these is a design decision made once, early, that gets more expensive every month the product ships without it.

How we approach it

When we design firmware for a connected product, we pick the MCU and partition the flash with a signed dual-image update path and an automated component list from the start, whether or not the CRA has come up in the conversation yet. If you have a board already in the field and want to know what it would take to add a real update path or generate an accurate SBOM without a hardware respin, send us the schematic and the firmware repository and we’ll tell you what’s missing.