Cyber Resilience Act: security does not end at the edge of your terminal 🌐

There is an old habit the tech industry spent decades reinforcing: security is an optional feature, you patch it later. The Cyber Resilience Act is the European Union’s flat “no” to that habit. Not because the rule is especially harsh — it is, but that is not the point. The point is that for the first time security is a legal property of the product, not an add-on.

Want the full picture? What a product with digital elements is, who is bound, the Annex I requirements, the reporting duties and the penalties are all in the practical guide: Cyber Resilience Act — A practical guide.

The co-author of every security bug 🐛

Regulation (EU) 2024/2847 starts from an obvious but uncomfortable observation: nearly every serious incident in recent years (a polite way of saying “the ones that end up on page one”) started from the same vulnerability: a known component, an available patch, and a product that nobody updated.

The CRA flips the viewpoint. It does not try to harden your Arduino, your modem or your microcontroller. It requires that the person who places a product on the market knows what it contains, guarantees vulnerability handling for the entire product lifetime, and says so clearly.

A common misreading of this regulation is to see it as the “successor” to NIS 2. It is not: the two laws run in parallel and must be read together. NIS 2 looks at the organisation — governance, measures, accountability of those who run the systems. The CRA looks at the product — what it contains, how it is updated, who owns its lifecycle. Software, a device, a component: if it is connected to something, it has a security lifecycle that someone is accountable for. Two sides of the same risk.

“Product with digital elements” is broader than you think 📦

The definition (Art. 3) is the part most companies underestimate. It is not only about the router or the IoT gadget. It covers any software or hardware product, including components placed on the market separately, whose foreseeable purpose includes a connection — logical or physical, direct or indirect — to a device or a network.

Translation: an SDK, a commercial library, an app, a firmware, an embedded device. If it “talks” to something, it concerns you. And the manufacturer is not only someone who makes hardware: it is whoever markets under its own name, even free of charge.

This is not a formality: it closes a gap. Until now, if your router was insecure, the blame went to the chip maker; if the chip, to the networking library; if the library, to open source. The CRA explains that the security chain has a starting point: the manufacturer, and every component counts.

The core: Annex I and the “double soul” 📋

The regulation rests on two very different parts:

• Part I — product security: design that minimises vulnerabilities, secure-by-default configuration (no default passwords!), updates, data minimisation, logging, resilience. In short: choose security first, not later.
• Part II — vulnerability handling: a single point of contact, a coordinated disclosure policy, periodic testing, public disclosure, free updates during the support period, and above all the SBOM — the software bill of materials, the machine-readable list of dependencies.

Part II is the real cultural leap. “Knowing what is inside your own product” sounds obvious, but almost no software producer can say it beyond the names of top-level libraries. The CRA turns this awareness into a persistent requirement: remember that a security update for an old version must stay available for 10 years? That is not a typo.

The three pillars that touch producers 🏗️

1. The support period. The manufacturer must set a support period of at least 5 years (or the expected product lifetime, whichever is shorter) during which vulnerability handling is guaranteed. If the product is meant to stay in the field for a long time — routers, operating systems, motherboards — the period must be longer than 5 years. That is not a generous commercial choice: it is a legal obligation with a direct impact on business models.

2. Vulnerability and incident reporting (Art. 14). From September 2026, if you discover an actively exploited vulnerability or a serious incident in your product, you have 24 hours for the early warning, 72 hours for the notification and 14 days (or 1 month) for the final report — to CSIRT and ENISA through a common platform. A team without an incident-response runbook will have to invent one under stress. Not the best moment.

3. Graded conformity. Self-assessment for general products and Class I (password managers, browsers, VPNs, operating systems, routers); notified-body assessment for Class II (firewalls, IDS/IPS, hypervisors, container runtimes); mandatory EUCC certification for critical ones (HSM modules, smart cards, meter gateways). If you make firewalls, you will find that the “simple” checklist is no longer enough.

The cost is not only the fine 💸

Penalties up to €15 million/2.5% are what makes the headlines, but not the most expensive bill.

The real cost is forward-looking: cataloguing products, writing the risk analysis, building the SBOM, defining the support period, putting the coordinated disclosure process in place. All before the auditor arrives. And there is the commercial side: people producing for regulated sectors or public administrations will see clients asking for the EU declaration of conformity and the CE mark as a purchasing requirement. Without them, you will not even get the first meeting.

There is one exemption worth mentioning for open source: penalties are excluded for the open-source software steward (the entity that commercially sustains its development). Not a general free pass — the due diligence required when you integrate third-party components, including open source, is explicit — but it is recognition of the role voluntary contribution plays in security.

Conclusion: security has become part of the delivery 🚚

The CRA does not ban anything. There is no list of prohibited practices or “bad things” to identify. It asks for something harder than banning: being able to explain, with documentation, what you built and how you keep it safe.

For people who write code, this is a step towards maturity: security stops being the chapter someone writes at the end of the manual and becomes part of the product, with a name, a surname and a deadline. As with the AI Act and NIS 2, the real question is not “what do we risk if we do not do it”, but “how much does it cost to find out too late”.

Want the operational details — who is covered, the Annex I requirements, how to report, when and the penalties? They are in the practical guide: Cyber Resilience Act — A practical guide.