Split your BSP from your libraries: the CRA's Article 13 makes a boring architecture decision mandatory

Most firmware images are one undifferentiated blob from an update-cost point of view: the bootloader, the RTOS, the vendor HAL, the TLS stack, and your own application logic all ship together, get versioned together, and get patched together. That's fine until the CRA puts a number on how long you're on the hook for it.

What Article 13 actually ties you to

The obligation isn't "support your product forever." It's narrower and, in a specific way, worse: manufacturers must provide security updates for the expected product lifetime, with a floor of five years unless the product's expected use is genuinely shorter — and manufacturers have to document, in the technical file, the reasoning behind whatever support period they picked. Whatever ships in the image on day one is what you're committing to carry for that whole window, for every component in it, regardless of whether that component is genuinely load-bearing or just came along for the ride because it lived in the same source tree.

That's the mechanism worth paying attention to: the scope of your five-plus-year obligation is set by an architecture decision you probably made without thinking about update cost at all.

Two very different rates of change, one build

Look at what's actually in a typical connected-device firmware image and ask "how often does this realistically need to change, and how risky is changing it":

• Slow, high-blast-radius: bootloader, secure boot chain, RTOS/kernel core, the vendor HAL. Changing these carries real risk — a bad bootloader update can brick hardware — and in practice they change rarely, mostly for security patches or major SDK jumps.
• Fast, low-blast-radius: application logic, the network/TLS stack, vendored third-party libraries, anything talking to your cloud backend. These are exactly the components that show up in CVE feeds most often, and updating them wrong is recoverable — worst case, roll back the app layer, not the whole image.

Shipping both categories as one monolithic image means every patch to the fast-moving layer inherits the risk profile and rollout caution of the slow-moving one. It also means your SBOM and your update evidence treat a one-line dependency bump in a TLS library the same way they treat a bootloader change — which is both more paperwork than the small change deserves and less scrutiny than the big one deserves.

The split, and what it buys you under Annex I / Article 14

None of this requires a rewrite. The pattern is: keep the bootchain, kernel, and HAL as the genuinely slow-changing base image, and give the frequently-touched layer (libraries, application code, comms stack) its own update channel — a separate partition, a container-like layer, or just a component that can be re-flashed independently of the base — with its own version, its own entry in the SBOM, and its own OTA path.

Two concrete payoffs, both tied to obligations you already have regardless of architecture:

1. Faster Article 14 response. From 11 September 2026, an actively-exploited vulnerability in a shipped product starts a 24-hour early-warning clock to ENISA, followed by a 72-hour notification and a 14-day final report. If the vulnerable component is an isolated, independently-updatable layer, "can we ship a fix" is a much shorter conversation than "can we safely re-flash the whole image" — and that difference matters when the clock is measured in hours.
2. A support-period commitment that matches reality. If your fast-moving layer can be updated independently, you can plausibly commit to patching it for as long as the product is sold and supported. The slow-moving base, by contrast, is where a shorter, explicitly-justified support period is easiest to defend in the technical file — you're not promising five-plus years of bootloader churn, you're promising a stable base plus a genuinely maintained application layer on top of it.

What this doesn't solve

This is an architecture pattern, not a compliance shortcut. It doesn't reduce your SBOM obligations — if anything, a layered image needs two well-maintained SBOMs (or one that clearly separates the layers) instead of one flat list. It doesn't remove the need for a documented vulnerability handling process, a real CVD contact, or a written justification for your support period — those are still separate line items in Annex VII, done or not done regardless of how your image is partitioned. What it does is make the recurring cost of carrying that obligation smaller, because the thing you're promising to keep patched for years is no longer bundled with the thing that changes every sprint.

Want to see where your current SBOM already draws that line — or doesn't? Upload it (or try the built-in ESP32 sample — we never store it) and get your open CVEs, exploitation flags, and a checklist of what's still missing for the CRA / EN 18031 technical file: run the free check.

This article is an engineering-oriented overview, not legal advice. Primary sources: Regulation (EU) 2024/2847 (CRA), Articles 13 and 14.