The Cyber Resilience Act explained: security in digital products

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first European law to impose horizontal cybersecurity requirements on products with digital elements placed on the Union market. Adopted in 2024, it applies from 2027, with some obligations (notably reporting) coming into force earlier. As a regulation, it is directly applicable in all Member States without national transposition.

The logic is the product-safety approach Europe already knows — like CE marking — extended to software and connected hardware. In practice: if you place on the market a product that can connect to a network or another device, you must be able to demonstrate that it is designed and maintained securely throughout its life cycle.

Who it applies to

The scope is broad: it covers products with digital elements, meaning any software or hardware product whose intended use includes a logical or physical connection to a device or a network. That captures routers and IP cameras, but also operating systems, libraries and applications. Obligations fall mainly on the manufacturer, with proportionate responsibilities also for importers and distributors.

There are meaningful exclusions: products already governed by equivalent sector-specific law (for example medical devices, aviation, vehicles) and — a point often misread — free and open-source software developed outside a commercial activity. The CRA also introduces the figure of the open-source software steward, with lighter obligations.

Security-by-design as a legal requirement

The core of the regulation is Annex I, which lists the essential cybersecurity requirements. A product must be placed on the market with no known exploitable vulnerabilities, with a secure default configuration, with the ability to reset to factory state, with data protection and a minimised attack surface, and with the capacity to log relevant security events. This is not a statement of good intentions: it is a list of verifiable properties the manufacturer must guarantee and document.

This changes how work is done upstream. Security can no longer be bolted on afterwards: it must be designed in, and it must be demonstrated through a conformity assessment whose stringency depends on the criticality of the product (with categories of important and critical products subject to stricter requirements).

Vulnerability handling across the life cycle

The second pillar is vulnerability handling throughout the support period, which is normally at least five years unless the product has a shorter useful life. The manufacturer must identify and document vulnerabilities and components — including through a software bill of materials, the SBOM — distribute timely and free security updates, and adopt a coordinated vulnerability disclosure policy.

This is where many companies discover a hidden debt: they do not know precisely what their products contain. The SBOM stops being good practice and becomes the precondition for being able to comply with the law.

There is also an organisational consequence that tends to be underestimated: a multi-year support obligation falls on a product that may only sell for a few years, yet must be kept secure well beyond that. It means planning maintenance resources during design, working out how updates will reach even ageing installations, and deciding what happens when a third-party component stops being maintained upstream. These are product decisions, not just security ones.

Reporting obligations to ENISA

The CRA introduces strict reporting duties. The manufacturer must notify actively exploited vulnerabilities and severe incidents affecting the security of the product through a single reporting platform coordinated by ENISA, which routes them to the competent national authorities (the CSIRTs). The timelines are tight: an initial early warning within 24 hours, followed by fuller notifications over the following days. The rationale is to give the European ecosystem real-time visibility into threats propagating through widely deployed products.

What to do now

2027 feels distant, but a product development cycle is not. It pays to start with three actions: map your product portfolio against the scope and criticality categories; build or consolidate an SBOM and a vulnerability-handling process with disclosure channels; and define realistic support and update policies from the outset, because the support period is a contractual and regulatory commitment, not a marketing slogan.

The takeaway

The CRA brings to software the same discipline Europe has applied to physical product safety for decades. It does not reward those who document best, but those who design and maintain best. For makers, the question is no longer whether to make products secure, but how to prove it — and the answer is built now, in the way you develop and keep alive what you sell.