The EU Cyber Resilience Act: What It Demands, and Why It's an Architecture Problem

What this is. Opinion + Experience + Fact (20% opinion · 10% experience · 70% fact). Written in collaboration with AI — I discuss, I do not outsource.

Europe has put a date on device security. Here is what the Cyber Resilience Act actually asks for — and why the teams who treat it as an architecture decision, not a paperwork task, will clear it without breaking stride.

For twenty years, security on a connected device was a virtue. You could ship without it, and the market let you. That era has an end date now, and it is written into European law.

The Cyber Resilience Act — Regulation (EU) 2024/2847 — makes cybersecurity a condition of selling a product with digital elements in the EU. Not a guideline, not a best practice. A condition of market access, enforced with CE marking and fines. It entered into force in December 2024, and the clock is now running toward two hard dates.

I want to walk through what it actually demands, strip away the compliance-theatre framing, and show you why almost all of it is a decision you make in the architecture — long before any auditor is in the room.

---

1. What the CRA is — and the two dates that matter

The scope is broad on purpose. Any product with digital elements placed on the EU market is in scope — hardware or software, from a smart thermostat to a firmware library to an industrial gateway. If it connects, or can connect, it counts.

Two dates anchor the whole thing. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to the authorities — an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days, routed through the reporting platform ENISA is building. From 11 December 2027, the full regime applies: secure-by-design obligations, conformity assessment, technical documentation, and CE marking. Sell without meeting them after that date, and you are not on the market.

▸ First principle. The deadline that matters is not 2027 — it is the architecture decision you make now, because you cannot retrofit any of this the week before an audit.

2. What it actually demands

Underneath the legal language, the essential requirements are a fairly concrete engineering checklist. A product with digital elements has to be secure by design and by default. It has to ship with a machine-readable software bill of materials — an SBOM that lists every component, open-source dependencies included. It needs a real vulnerability-handling process: a way to track, triage, fix, and disclose, and to deliver security updates for a defined support period. It needs a secure update mechanism — updates that are signed, verifiable, and deliverable in the field. And it needs the ability to report the incidents above when they happen.

The teeth are real: penalties for breaching the essential requirements run up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

▸ First principle. Every item on that list is a capability the device must already have — an SBOM, security logging, a signed update path — not a form you fill in at the end.

3. Why this is an architecture problem, not paperwork

Read the checklist again and notice what it is really asking. You cannot bolt on an SBOM the week before assessment — a truthful one has to be generated from how you actually build, every build. You cannot report a vulnerability being exploited in the field if the device cannot see or record what happened to it. You cannot push a security fix to a device that has no safe, signed way to receive one. And a support period is a promise you can only keep if the product was built to be updated for years, not months.

This is the quiet truth of the CRA: it looks like a legal problem and it behaves like an architecture one. The manufacturers who struggle will be the ones who try to paper over a design that was never built to produce this evidence. The ones who clear it easily will be the ones whose architecture already emits it as a matter of course.

▸ First principle. Compliance is cheapest when it falls out of the architecture as a by-product — and most expensive when it is retrofitted at the end.

4. We saw this coming — so we built it in

Here is where I will be direct, because it is the honest reason I can write this calmly. Over twenty-plus years of taking products from bench to factory floor, one pattern repeats: the audit trail, the bill of materials, the safe update path — they always get demanded eventually. By a customer's security team. By a safety standard. By a certification body. And now, by law. The only thing that changes is who asks and how expensive it is by the time they do.

Twenty years of that taught us the lesson plainly: we used to add these at the end, every time. So we stopped — and built them into the architecture from the first line instead. That thinking is baked into the open-source framework we built, EmbedIQ. It generates a CycloneDX SBOM by default — the same machine-readable format the CRA calls for, open-source components included. It captures a tamper-evident, hash-chained record of what the device actually did, and logs security events as first-class events, not afterthoughts. Signed, verifiable updates are part of the plumbing, not a feature someone remembered to add. The evidence is a by-product of the device running correctly.

Let me be honest about the boundary, because precision matters here: EmbedIQ does not make you CRA-compliant. No framework can do that for you — certifying your product is your responsibility, and no body has assessed the framework itself. What it does is put the evidence the regulation asks for on your side of the line by default, so you begin most of the way there instead of scrambling backwards from a design that never produced it. If you want to see how that is wired, it is public — the detail lives on my profile.

▸ First principle. The best time to design for a regulation is before it exists. The second best is now.

5. What to do now

You do not need to solve 2027 this quarter. You need to start the capabilities that everything else hangs off. Generate an SBOM from your real build today, open-source included, and keep it current. Stand up a vulnerability-handling process — and, just as important, a way to actually see an exploited vulnerability in the field, because you cannot report what you cannot detect. Make sure every device has a signed, safe, remote update path, and decide the support period you are willing to promise. And treat September 2026, not December 2027, as the near date — the reporting duty comes first.

▸ First principle. Start with the capabilities — SBOM, security logging, safe updates — and the paperwork writes itself.

---

The CRA will not be the last regulation to ask this of a connected device; it is the first big one to make it the price of the market. The teams that clear it easily will not be the ones with the best lawyers. They will be the ones who built the evidence in from the first device instead of the ten-thousandth. Security stopped being optional — and the architecture is where you answer for it.

FAQ

What is the EU Cyber Resilience Act?
It is Regulation (EU) 2024/2847, a law that makes cybersecurity a condition of placing products with digital elements — hardware or software that connects — on the EU market. It entered into force in December 2024 and shifts product security from a voluntary practice to a market-access requirement enforced with CE marking and fines.

When do the CRA deadlines take effect?
Two dates matter most. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents (a 24-hour early warning, a 72-hour notification, and a 14-day final report). From 11 December 2027, the full regime applies: secure-by-design obligations, conformity assessment, technical documentation, and CE marking.

Does the CRA require an SBOM?
Yes. Manufacturers must produce a machine-readable software bill of materials covering the product's components, including open-source dependencies, as part of vulnerability handling and technical documentation. CycloneDX and SPDX are the common formats used to satisfy it.

Does the CRA apply to open-source software?
It targets products with digital elements made available on the market in the course of a commercial activity. Non-commercial open-source development, and dedicated open-source stewards, fall under a lighter regime — but a commercial product that includes open-source components still has to account for them, for example in its SBOM and vulnerability handling.

What are the penalties for non-compliance?
Breaching the essential cybersecurity requirements can bring fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, alongside the risk of being removed from the EU market.

The short version of this is on my LinkedIn. The framework is open source — it's called EmbedIQ — and the architecture, the code, and the links live on my profile.