The Cyber Resilience Act turns your product into a regulated object

Most security regulation applies to how you run your company. NIS2 asks about your risk management. GDPR asks about your handling of personal data. The Cyber Resilience Act is different in a way that catches product teams by surprise: it applies to the thing you sell.

It uses the machinery of EU product law, the same machinery behind CE marking on physical goods. That means conformity assessment, technical documentation, a declaration of conformity, and market surveillance authorities that can order a product withdrawn. For software companies with no history in product regulation, this is an unfamiliar shape.

What is in scope

Products with digital elements made available on the EU market: software, hardware with software in it, and their remote data processing solutions where those are integral to the product's function.

The definition is broad. A connected device, an operating system, a library sold commercially, a desktop application and a firmware image all qualify. The test is whether the product is placed on the market, which means supplied for distribution or use in the course of a commercial activity.

Carve-outs exist. Products already covered by equivalent sectoral rules, such as medical devices, motor vehicles and civil aviation, are handled under those regimes. Pure software as a service is largely outside, because it is a service rather than a product placed on the market, but the boundary is not as clean as teams hope: a service with a client application, an agent or a device attached pulls that component in.

Open source is treated carefully. Software supplied outside a commercial activity is generally out of scope, and the regulation introduces a lighter-touch role for stewards who support open source projects commercially. This matters if you maintain a project as well as selling a product, and the analysis of your own role is worth doing explicitly rather than assuming.

Products are also categorised by criticality, with more important and critical classes covering things like password managers, identity systems, hypervisors, firewalls and similar. The class determines how much of the conformity assessment you can do yourself and how much requires an external body.

The obligations, in engineering terms

Strip the regulatory language and there are four groups.

Secure by design. A product placed on the market must be delivered without known exploitable vulnerabilities, with a secure default configuration, with the ability to be updated, with data minimisation and protection for confidentiality and integrity, and with attack surface limited to what the product needs. The requirement to ship with a secure default rather than a convenient one is the one that changes existing products most often.

Vulnerability handling. A documented process for receiving, triaging and remediating vulnerabilities, including a coordinated disclosure policy and a contact point. Security updates must be distributed without delay and, where feasible, separately from feature updates, so a user can take a fix without taking a behavioural change.

The software bill of materials. You must identify and document the components in your product, including third-party and open source dependencies, in a machine-readable format, and keep it current. Most teams can generate one today; few can keep it accurate across releases and few can answer "which shipped versions contain this component" quickly, which is the question that actually matters. The tooling and the practice are covered in OSV-Scanner, SBOMs and the supply chain question.

Support period. You must declare how long you will provide security updates, based on how long the product is reasonably expected to be in use, with a minimum floor set by the regulation for most products. That declaration is a commercial commitment with a cost attached, and it constrains how you end-of-life versions.

The reporting clocks are the sharpest edge

This is the part that requires an operational change rather than a documentation exercise.

For an actively exploited vulnerability in your product, and for a severe incident affecting the security of the product, you must notify the relevant authority and the EU agency for cybersecurity through a single reporting platform, on a staged timeline: an early warning within a day of becoming aware, a fuller notification within a few days, and a final report later. Users of the product have to be informed too, and where appropriate told about corrective measures.

Two things follow. First, someone has to own the assessment of "are we aware of active exploitation", which means your vulnerability intake, your support channel and your threat intelligence have to reach one desk. Second, the timeline starts at awareness, so it can begin on a Friday evening from a report submitted through a form nobody monitors at weekends.

Wire it into the incident process with a named decision-maker, exactly as with the other notification regimes, as set out in the runbook you use at 3am.

Conformity assessment and the marking

For most products the manufacturer performs the assessment itself, documents it, draws up an EU declaration of conformity and affixes the CE marking. For the higher criticality classes, a third-party notified body is involved, or you apply a harmonised standard that permits self-assessment.

As with the AI Act, harmonised standards are the mechanism that turns broad essential requirements into something a team can implement against, and standardisation work is ongoing. Conformity with a harmonised standard gives a presumption of conformity, which is why everyone wants them. Until they are complete, you implement against the essential requirements in the text and keep your documentation structured so it can be re-cut.

You also need the technical documentation to be kept for a defined period after placing the product on the market and to be produced on request.

Timing, and the trap of the middle date

Application is phased. The obligations do not all start together: the vulnerability and incident reporting duties apply earlier than the main body of obligations, which is the opposite of what most teams assume when they plan.

The practical consequence is that the reporting capability is the thing to build first, even though it feels like the smallest item on the list. Check the current dates for each obligation rather than working from a single headline date, because the phasing is the detail that determines what you need this year.

Where it overlaps with what you already do

If you hold ISO 27001, your management system, supplier management and incident process transfer. The gaps are product-specific: the bill of materials discipline, the declared support period, secure default configuration, and the separation of security updates from feature releases.

If you are in scope for NIS2 as well, note that they answer different questions. NIS2 regulates your organisation's operational resilience; the Cyber Resilience Act regulates your product. A company can be in scope for both, and the evidence overlaps but the obligations do not substitute, which is the same modelling problem described in one control set across frameworks and worth handling the same way. The organisational side is in NIS2 scope and obligations.

The things people forget

• Importers and distributors carry duties too. If you resell someone else's product into the EU, you are not merely a channel.
• Substantial modification makes you the manufacturer. Rebranding or significantly altering a product pulls the full obligation set onto you.
• The bill of materials has to be maintained, not generated once. A snapshot from the release you shipped two years ago does not answer the question a disclosure creates.
• End-of-life is now regulated. Dropping support for a version before the declared period has a consequence beyond customer annoyance.
• Your own dependencies inherit the pressure. Expect your suppliers to be asked the same questions, and expect to be asked them by your customers.

What to do this week

Answer one question in writing: for your flagship product, how long do you commit to providing security updates, and can you currently list every third-party component in the version a customer installed last month? If the second answer requires a research project, that is the finding, and building the bill of materials pipeline is the first piece of work. We scope this in the product phase of a security engagement.