The CRA Begins: Embedded Software's Center of Gravity Shifts

Five months left.

On September 11, 2026, the first obligation of the EU Cyber Resilience Act (CRA) takes effect. From that day, every manufacturer shipping digital products into the EU market must file an early warning to ENISA and national CSIRTs within 24 hours of learning about an actively exploited vulnerability (followed by a full notification within 72 hours and a final report within 14 days, in a three-stage obligation). On December 11, 2027, the CRA itself comes into full force. Products that don’t meet the essential cybersecurity requirements in Annex I cannot be sold in the EU market. Violations carry fines of up to €15M or 2.5% of global annual revenue, whichever is greater.

It looks like another regulation. And it’s being treated like one. That’s the most expensive misreading. The CRA is the legal codification of an answer engineers have known and deferred for the past decade: how embedded software should actually be built.

What Actually Changed

The core of the CRA, compressed into one sentence:

Security responsibility has shifted from “the moment of product launch” to “the product’s entire lifetime.”

In the old model, security was a checkpoint. Get certified, ship, push the occasional patch. The moment of certification was the peak of security work. After the CRA, that moment becomes the starting line. Every device in the wild, for every day it’s alive, sits under a cybersecurity obligation.

What exactly does it force? CRA Annex I, Part I defines 11 “Essential Cybersecurity Requirements.” One of them is short: “Products shall be designed and manufactured to reduce the attack surface.” You’d want this to be a recommendation. It’s a mandatory requirement. If you can’t answer the market surveillance authority’s question “why is this package in here,” you’re in violation. “Debugging convenience” doesn’t cut it as an excuse.

Annex I, Part II requires SBOMs in machine-readable format (SPDX, CycloneDX, etc.) as part of the product’s technical documentation. Every single package becomes a permanent legal record item. Every library we add to a BSP is treated, from that moment on, like an asset on a public registry.

Article 13 forces the support period to match the product’s expected use period. The minimum is five years, but a product whose catalog says “15-year operation” carries a legal 15-year support obligation. A number a PM wrote as marketing copy now decides the BSP team’s obligation horizon. And throughout that period, security updates must be free.

Article 14 defines the reporting obligation: 24-hour early warning, 72-hour detailed report, 14-day final report. The countdown starts the moment you find out.

When these four provisions combine, a new equation appears.

One package in our BSP = one tracking, patching, and reporting obligation for the next N years.

A thousand packages, a thousand obligations. Free of charge. Within 24 hours. In an environment where 131 new CVEs land every day.

The Numbers Are 10x

Why now? The numbers explain it.

48,174 new CVEs were filed in the 2025 NVD. That’s 131 a day on average. The Linux kernel alone accounts for 5,530, or 8 to 9 new kernel CVEs every day. The median time from exploit disclosure to actual exploitation has dropped below five days. Industry data shows that more than half of breaches happen against known vulnerabilities that already had a patch.

The assumptions that made the old model work are gone.

Ten years ago, annual CVEs ran 5,000 to 7,000. A small security team could triage by hand, and you could cram 1,000 packages into a BSP without seeing the operating cost. Yocto’s default images inherited desktop-Linux assumptions and bloated accordingly, and nobody charged that bloat as a cost.

The volume is now 10x. There is no way to manually match, evaluate, and triage 100+ new vulnerabilities a day. For automation to keep up, the number of components you have to track has to fit inside the limits of what automation can handle.

This is the core of the landscape CRA created. The 24-hour report is directly tied to BSP size. Fewer things to track makes it possible; more makes it impossible. “Keep the attack surface small” sounds like an aesthetic recommendation, but it’s really the precondition that makes the legal obligation executable at all.

The Cloud World Already Answered This

There’s a thread embedded engineers tend to miss. The cloud and container world hit this same problem 5 to 7 years earlier, and they answered it. Only embedded is late.

That answer is called distroless.

A company called Chainguard built Wolfi, a “non-distribution,” that packages container images with only the application and its runtime dependencies. No shell, no package manager, no debugging utilities. The result is measurable: Chainguard images cut CVEs by an average of 97.6% versus their OSS equivalents. Not because they patch better, but because there’s less in there to begin with.

And the more important principle: don’t update, replace. Chainguard never runs apk update inside a container. When a new version is needed, they build a new image and swap the whole thing. Every base image is rebuilt automatically every night. This is Google’s internal “build horizon” thinking: even microservices whose code hasn’t changed get rebuilt on a fresh base on a regular cadence.

These two principles (minimize and replace) are how the cloud survives the CVE flood.

You can’t port it to embedded as-is. There’s no way to make a BSP wholesale distroless. The boot chain, the kernel, the HAL all have to stay where they are. But the idea transfers.

Physically separate the slow-changing layer from the fast-changing one. BSP gets the boot chain, the kernel, and a minimal OS. Anything that needs frequent updates (security libraries, communication stacks, applications) goes into containers or a separately statically-linked channel. Then the BSP itself does one big upgrade every five years, and the CVEs erupting weekly get handled in the fast layer. As long as two regions on different rebuild cadences live inside the same image, the CRA’s 24-hour reporting is impossible.

LLMs Widen the Asymmetry

At the same moment the CRA takes effect, another shift is underway. LLMs reached attackers first.

On April 22, 2026, a week before this post, Deutsche Telekom’s Red Team disclosed a 12-year-old TOCTOU bug in PackageKit (CVE-2026-41651, “Pack2TheRoot”). PackageKit is a daemon shipped on nearly every major Linux distribution. The discovery method: AI-assisted research with Claude Opus. They steered the model in a specific direction and surfaced an exploitable vulnerability.

The cost of mining new CVEs is dropping. Fast.

For defenders, this is asymmetric. Attackers turn “LLM × time” into vulnerabilities. We have to track and respond to those discoveries across every single component inside our BSP. The attacker’s cost falls with time. Ours scales with BSP size. The gap widens as time passes.

The defensive side of that trade is worse than it looks. When I benchmarked LLMs on 233 embedded firmware cases, the best model cleared 68.0%, and the categories it failed hardest on were DMA, ISR, and threading. Those are the same categories where a defect becomes a CVE rather than a bug report.

Assume that gap keeps widening over a 15-year support window. Surviving on that assumption leaves no answer except shrinking our own surface. Patching faster has limits. 24 hours is already the limit. The next move is having less to patch.

Three Mindset Shifts

Within the next five years, teams that treat the CRA as compliance work will diverge from teams that treat it as a change to the game itself. Becoming the second kind of team takes three mindset shifts.

First, see packages as contracts, not assets.

Adding a line to IMAGE_INSTALL is signing a contract for that package’s CVE tracking, backporting, verification, and reporting for the next N years. Once this view sticks, decisions change automatically. The default question stops being “why remove it?” and becomes “why add it?” Debugging tools accidentally surviving into production (which happens more often than you’d think) drops too, because anything that goes in is hard to take out.

Operationally, every package addition should carry a name. Who added it, and why. Who’s going to justify it at the next LTS migration. Packages without a name don’t go in.

Second, translate BSP size into compliance opex.

Suppose your BSP currently has N packages. SBOM entries for the next 15 years: N. Daily new CVE matches: proportional to N. Some of them will be in scope for 24-hour reporting. For each one, you’ll need to produce a patch, backport, or mitigation for free. At conformity assessment, a Notified Body audits N items.

When N is large, everything is large. No other single decision affects 15-year operating cost as much as BSP size does. That makes BSP slimming a compliance opex reduction line item, not a security R&D line item. The message that goes up to leadership has to change to match.

Third, adopt “rebuild speed” as a security KPI.

In the CRA era, the single most important security metric is how long it takes to rebuild the entire firmware from scratch. When a CVE drops on one critical dependency, the lead time from “build a new image from zero” to “OTA deployed.” When this is short, 24-hour reporting is possible, 15-year support is possible, and swapping Yocto LTS releases is possible. When it’s long, none of it is.

And this time is roughly linear in BSP size. Build time, regression test time, QA time, OTA verification time. All of them grow with the package count. A small BSP produces a fast rebuild, and a fast rebuild produces compliance.

Closing

The CRA isn’t compliance work. It’s engineering that’s been correct for the past decade finally acquiring a punishment mechanism.

Build small, replace fast, own it forever. The cloud world figured out, five years earlier, that this is the only way embedded software survives the CVE flood, and they proved the answer. The CRA just legally extends that answer to every EU-targeted device maker.

Seen that way, the five-month countdown reads less like a burden and more like a direction signal. Everything CRA forces (smaller attack surface, SBOMs, 24-hour reports, free patches) is what good embedded software was supposed to have anyway. The only reason to defer was that the cost was invisible. Now the cost is visible. The penalty is set, and the operating cost is computable.

You can’t change everything in five months. But where to go is clear: small, modular, fast rebuild. In the game that starts September 11, those three things are the survival skill itself.